What is an Architect anyway?

An interesting MSDN Developer Center blog entry gives us some insight into the definition of an Architect within (at least part of) the Microsoft culture by taking us through some of the history of the software architect role, including the driving forces that made architects a necessity, starting from the time when software architects were less necessary:

Not so long ago, programming platforms were more self-contained. From robust and complex environments like mainframe COBOL to light and easy-to-understand xBase languages, the most important technical decisions were already taken. For software projects, that meant both benefits and drawbacks. A benefit, because where a decision exists, no time needs to be spent in discussions about the best way to do anything.

Dagum, the author, then talks us through the relatively new diversity in the foundational stack architectures that we used today, and how the flexibility that those new strategies provide comes at a cost: complexity that needs to be effectively managed.

So, thanks to component-oriented software we could choose the platform which best fit a specific problem. Despite that, the paradigm shift of new platforms was difficult to learn for many developers. Thus, one of the first objectives of a good architecture was  to gently hide  the complexity of new platforms and APIs behind simpler ones, more focused in the context of the problem being solved (typically a business problem), and, most of all, easily understandable by regular programmers.
That way software architecture became a highway to develop business solutions in a timely, secure, accurate manner. Under the pavement of that highway is nothing but technological decisions, the critical ones. Decisions the architect had to take to make the developers’ tasks easier.
The difference with past platforms is that now, rather than buying general purpose software from a vendor, an organization’s members make the decisions regarding the function of the business solution to be developed.

Dagum explains that this precipitated a transition in the role and definition of architects, from application centric to more enterprise or even infrastructure centric roles, and even details the primary drivers behind the latest buzzword-driven architecture trend, SOA. In outlining how software architects were defined early on in the discipline, he walks through four major best practices:

• Design Patterns, which of course started with the Gang of Four Design Patterns book
• Architecture Patterns, in which Dagum exemplifies with the MVC Pattern started in Smalltalk
• Anti-Patterns, which is, of course, exactly what it sounds like
• Frameworks, which he exemplifies with ORM mappers and MVC support frameworks

He then explains how as the role has been formalized the roles and responsibilities have transitioned somewhat to a higher level of abstraction and have consolidated around three categories:

• Infrastructure Architect, who focuses on the hardware/network/OS platform infrastructure architecture
• Solutions Architect, who often ranges across software/database/hardware boundaries to identify and define a full stack architecture for a particular solution
• Enterprise Architect, who is often more of a governance entity whose scope and influence is broadly applied across and organization

Finally, Dagum closes by looking forward, specifically referencing SOA, MDA, Software Factories, Software as a Service, and Web 2.0. The article provides an insightful overview of the development and formalization of the role of the architect and the driving forces behind it.