The Layman’s Guide to IT Architecture Roles

Most roles within information technology are fairly well understood and defined but this can’t always be said of architects.  This can be a problem for anyone considering a career progression into architecture – exactly what are the options and how do you get there?

Here’s my view on what the architecture roles are that you’ll typically see in today’s market, and how you might progress to them.

How to define architecture roles

There’s two ways we can define architecture roles…

The first concept I want to clarify is that of the domain.  An architectural domain is simply a conceptual area within the wider IT / architecture landscape, for example: infrastructure, applications, data, security and so on.  These domains are essentially areas within IT and architecture just as disciplines such as cardiology and neurology are areas within medical science.

A simple way of understanding architecture roles is to consider them against these domains, specifically in terms of breath and depth:

• Breadth – how many domains the role covers.
• Depth – at what level of detail does the role typically operate.

Please note this is not a definitive list of all architecture domains.

The second way we can classify architecture roles is by placing them on a marketecture-tarchitecture spectrum.   In the simplest possible sense:

• Tarchitecture (technical architecture) – deals with the actual components a solution is made up of, how it will actually work and how that technology is managed.

• Marketecture – (a portmanteau of the words marketing and architecture) typically deals with views of the solution that are more readily understood by laypeople, and tend to focus on non-technical aspects. There are 2 or 3 different definitions of marketecture but the exact differences are not critical for an introductory understanding to architecture roles; see the end of the article for more information.

It would be correct to assume that there’s often tension between these two perspectives, however, it would be wrong to blindly assume that all marketecture is inherently evil and adds no value.

Architecture roles and how to classify them

In my world view, there are three broad types of architecture work:

1. Enterprise Architecture
2. Domain Architecture
3. Solution Architecture

I want to call out these three because they account for the majority of architecture work out in the market, even if the person doing the work has a job title that sounds different.  In addition to these there’s a few outliers that are organically linked to these but which aren’t your classic architect role, or which defy the classifications I’m using here.  Let’s ignore those for now.

Note, the basis of this diagram isn’t necessarily new and it might be something you’ve seen before.

What about the whitespace between enterprise and solution architecture?  Diagrammatically the whitespace exists to make the diagram easier to interpret, however, in the real world the exact point at which one ends and the other begins will vary from one organisation to another, partially based on what work needs to be done and the people available to do it.   In simple terms though, solution architects tend to focus on project specific work, enterprise architects do not.

We’re now at the point of fundamentally understanding the difference between architecture roles (please forgive the role descriptions which aim to give an idea of what the role is about in less than 30 words).

Role	Description	Relative Breadth and Depth	Marketecture – Tarchitecture
Enterprise Architect	Strategic, high level analysis and architecture across the entire organisation.	Broad, high level	90/10
Application Architect	Strategic, high level analysis and architecture within the given domain, plus supporting delivery / project work.	Narrow, all levels	50/50
Business Architect		Narrow, all levels	50/50
Data Architect		Narrow, all levels	50/50
Infrastructure Architect		Narrow, all levels	50/50
Integration Architect		Narrow, all levels	50/50
Network Architect		Narrow, all levels	50/50
Security Architect		Narrow, all levels	50/50
Solution Architect	Analysis, architecture and design for a specific project.	Broad, low level	10/90

Please note that the roles listed above is not definitive, you’ll frequently come across variations to these.  How I suggest you understand those variations is to start by understanding the concepts described above, and then figure out where those variations sit in that context.

A further word on Solution Architecture

It’s important to remember that for solution architecture, although in definition the scope of the role is broad, the practical scope of the role in terms of a specific project is relatively constrained.  This is why the term solution architect has such broad usage, and why many people struggle to accurately define it.

Consider this hypothetical example:

For this hypothetical project, the “scope” of the domains that the solution architect is dealing with is heavily focused on the application domain, with a notable amount of security work and a bit of data and infrastructure thrown in.  The point is that whilst the level of “depth” they will be working at will usually be relatively consistent, the pieces of the “breadth” they focus on will vary greatly.

The exact mix of domains that the solution architect will cover on a given project will depend entirely on several factors, such as the what the project is trying to achieve and what other skills are available to support the project.  Consider the example above; if the organisation has dedicated infrastructure and data architects then the relative effort the solution architect is likely to spend on those domains is much less than if the organisation does not have infrastructure and data architects.

Appendix: The Mysteries of Marketecture

There are a number of definitions of what marketecture is, the three below being the most relevant; you might find that in a given your specific context what marketecture means is a hazy combination of these:

1. The Hohmann / Fowler view: the business perspective of a systems architecture, including concepts such as licensing, the business model, technical details relevant to the customer (i.e. not necessarily ‘real’ ones). Brand elements, and so on.
2. The Ian Gorton view: an informal depiction of the systems structure, interactions and relationships, possibly augmented by labels that espouse the philosophy behind the architecture.
3. The Urban Dictionary view: a fairly cynical view in which the architecture is dreamed up by the marketing department and has little to do with reality.

Done properly, marketecture should fall into definitions 1 & 2, and serve as an excellent support to stakeholder discussions throughout the life-cycle of solution development.

Further reading on Marketecture:

• http://martinfowler.com/ieeeSoftware/marketecture.pdf
• http://www.urbandictionary.com/define.php?term=Marketecture
• In print: see Luke Hohmann’s excellent book “Beyond Software Architecture: Creating and Sustaining Winning Solutions”.

Advertisement