The Many Species of Architects

One of the reasons why there is so much disagreement over the definition of the word Architect is that those engaged in the debate seem to be reaching for one comprehensive definition for this professional label. The reality is that there are many species or types of architects, each with different concerns and responsibilities.

A Model for Classification

Many people in our community have posited the idea that the role of an architect unfolds as a continuum that starts somewhere around the time you become a more senior developer, and transforms in its nature up through positions such as CTO. This description suggests the wide variance in concerns that different types of architects might have, but is still quite vague. If you’re not a senior developer or an executive, where do you fit on this continuum, how does that translate into what you really do, and might there be a way to better classify the different types of architects?

One way that we might begin to organize this broad continuum into more meaningful classifications is by examining the person’s concerns and responsibilities with respect to scope and time. Architects are usually constrained by certain boundaries or a scope they are to focus upon. Some architects are focused upon one product or project, while others must be cognizant of many products or projects within their company. Architects also typically have a responsibility to focus on either short-term/tactical concerns or longer-term/strategic issues. This “time focus” usually influences how involved they become with such details as how object models are designed, what patterns are used, and so forth. Generally, if you are more tactically focused, then you are more likely to be involved in the implementation details, and you might even do some of the coding. On the other hand, if you are more focused on strategy (e.g. how to use technology to solve business problems, looking at trends, etc.), then you will probably not get caught up in the implementation details. The graph below provides one way we might conceptualize three basic types of architects ...

As you can see, there are overlapping concerns; it’s impossible to set hard and fast lines around these evolving roles. Regardless, the names suggest that Solution Architects tend to be more tactical and responsible for fewer products, while Enterprise Architects are generally concerned with a larger set of products and gravitate towards how technology might serve a strategic business need. This still may not provide that clear definition for you, so allow me to offer yet another set of characteristics by which we might recognize the type of architect we have before us ...

Solution Architect

• Typically a senior member of a project or product team

• Leads and oftentimes owns the design of the product; might have authority to approve or reject designs, and participates in or leads code reviews

• Might do some coding (i.e. the Developer/Architect), usually of the more complex areas of the system

• Oftentimes, but not always, owns the product requirements and negotiates scope of product features with the users

Enterprise Architect

• Typically reports to Executive Management

• Drives for consistent approaches across products or projects. These concerns may apply to the use of common design approaches, application frameworks, development tools, coding standards, and methodologies, to name a few.

• Probably doesn’t code, but might have a team that develops common “libraries of functions” (e.g. security, data access, exception management and logging, interprocess communications, etc.)

• Oftentimes provides oversight to help teams identify risks such as duplicate efforts or competing solutions across product or project teams; facilitates the “right balance” between the needs of a specific product or project team and the needs of the enterprise as a whole

• Tracks technology trends and looks for ways in which emerging technologies might be adopted to facilitate the business strategy

• Might not have the authority to alter the requirements or designs for products

• Oftentimes manages vendor relationships and assists in contract negotiations

Chief Technology Officer

• A member of Executive Management

• Provides highest level of oversight for all products or projects

• Typically manages budget for all products or projects

• Accountable for Service Level Agreements with customers

• Manages vendor contracts

• Tracks technology trends and looks for ways in which emerging technologies might be adopted to facilitate the business strategy

• Never codes

• Has authority to approve or reject scope of product features and designs approaches

These descriptions are only meant to capture the highlights of what each type of architect is typically concerned with; There may, of course, be a few responsibilities that I missed, and there will always be those who feel they fall into a particular category, but actually do more or less than what is described above.

A special "breed" of Enterprise Architect is the Integration Architect. This type of architect identifies and designs the processes required that allow disparate applications to collaborate in order to achieve some common business goal. For example, this type of architect might design the processes that provide the means for an E-Commerce site developed in .Net to push customer and order information from the site on to a "Customer Relationship Management" system and an Accounting system.

Other notable architect species that were not mentioned above include ...

Database Architect

• May be assigned to one or many projects

• Usually owns the design of the database schemas

• When there are multiple projects, usually drives for consistency in database-object naming and coding standards

• When disparate systems exist, might work with Integration Architect to drive to a common data model

• Might code SQL and stored procedures, but usually delegates this work to others

• Oftentimes tracks database trends and plots a strategic roadmap for the use of database-oriented tools and technologies

• Does NOT perform duties commonly attributed to Database Administrators

Infrastructure Architect

• Designs network topologies and server deployment approaches

• Designs means to achieve high availability (e.g. clustering, load-balancing techniques, etc.)

• Creates guidelines and approaches to ensure network security, performance, fail-over, and disaster-recovery

• Develops practices for monitoring production environments

I won't bother getting into the role of "Business Process Architect" since there seems to be even less consensus about what that means than there is for the technically oriented species of architects.

Conclusion

There is no single definition of architect that is suitable to all who are involved in this emerging profession. Just as there are many types or species of mammals, there are many types and classifications of architects. If we recognize this, then perhaps we can avoid a few arguments and see that many of us do indeed have certain architectural responsibilities.