What is an Architect anyway?

Posted by Mark Figley on Aug 14, 2007

Sections

Enterprise Architecture

Topics

Enterprise Architecture ,

Architecture

Tags

Infrastructure Architect ,

Solution Architect

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.

1. Back to top

   An answer for the question "What is an Architect anyway?"

   by Alexei Guevara

   I think that reading Christopher Alexander's Keynote Address at OOPSLA 96 might provide an answer to the question "What is an Architect anyway?", at least it did for me.

   Reply

2. Back to top

   Re: An answer for the question

   by Rob de Boer

   I agree. Although Dagum's article has some interesting points, it is focused on Software Architecture and not so much what it means to be an Architect.

   Reply

3. Back to top

   it is

   by Vic C

   usually someone who can't code, but claims they used to.

   Reply

4. Back to top

   Hardly Insightful or New

   by Eoin Woods

   Mark wrote:
   > The article provides an insightful overview of
   > the development and formalization of the role
   > of the architect
   I'd disagree. In fact, the authors of the article appear to be almost totally ignorant of the history of software architecture. It certainly didn't grow out of patterns and frameworks (although both are of course relevant to it). It's been studied as an academic discipline since the early 90s so practitioners were doing it well before people started to study it in academia.
   
   They also appear to miss some of the really important aspects of software architecture including understanding the breadth of stakeholder needs and focusing on system qualities, not just functions.

   Reply

5. Back to top

   Re: Hardly Insightful or New

   by Stefan Tilkov

   I'm also quite puzzled by the idea that MDA is supposed to be based on SOA ...

   Reply

6. Back to top

   The Architect

   by Benjamin Carlyle

   The role of the architect is to produce valuable architecture specification. Architecture is best described through a set of views, each specifically designed for particular stakeholders. Each view provides the knobs its stakeholder wants to tweak, and hides architectural information that isn't relevant to that stakeholder.
   
   The role of the architect is a sociotechnical one: To get the right information to the stakeholders, so that when they come around the same table they can have the right discussions and come to the right conclusions. It is to make sure that confusion and misinterpretation is arrested and addressed promptly and adequately. It helps if some of the more mechanical level of the architecture can be validated for consistency automatically.
   
   It helps to have an architect who is a jack of all trades, and ideally master of a few also.
   
   As Dagum says, the most important view at the moment in software is likely to be the SOA/REST view. It shows how services and their clients interact in a detailed way, and ensures that expectations and provisions of data are compatible with each other and allow each to meet their requirements.
   
   Views outlined in the 4+1 model include the logical (reuquirements) view, process (services) view, development (source code) view, and physical (deployment) view. In addition we see views relating to API structure, and other views. These will continue to evolve over time.
   
   Benjamin.

   Reply

• Older >