In terms of career progression into architecture, people typically start off from one of several common “starting positions”. For example, a solution architect or application architect this is likely to come from a software development background.
Here a map of some of the more common paths:
There are more types of architect and pathways than what’s depicted here, but based on conversations with architects I have met (or interviewed) this is a fairly accurate summary of some of the more common paths.
The Architectural Role Meta-Model
For simplicity, I define it in three parts (outlined below). In broad terms, Enterprise and Solution architecture disciplines cover the full range of domains but operate within a specific level of abstraction; whereas Domain architects cover all levels of abstraction but within a specific domain. An in-depth write up on this can be found here, but in summary:
- Enterprise Architects – who typically operate at the highest level of architectural abstraction and across a broad range of domains.
- Solution Architects – who typically operate at a project or programme level. Although solution architecture covers the full breadth of domains, an individual solution architect will typically be relatively narrow in their focus – either providing general technical leadership within the scope of a specific project, technology or domain.
- Domain Architects – typically operate simultaneously across the spectrum of enterprise and solution architecture, but within a single specific domain. They will support both enterprise and solution/delivery specific needs.
We typically see common paths into and through architecture, such as the software developer into the application or solution architecture space; business analysis into the business architecture space, and so on. Once in the architecture space it is possible to side-step into related roles – this might be done as a conscious and fundamental career choice, or may simply represent shorter-term variety driven by the work available.
The progression from solution architecture to domain architect to enterprise architect is common but by no means the only career path.
To a certain extent there’s a drift upwards in terms of abstraction (developer to solution architect; solution architect to domain or enterprise architect), but this isn’t always strictly the case. It’s fair to say that each role has a set of skills and a temperament that suit it – some people will mature from one role into the next, others will take an alternate path.
The Product Specialist
One of the assumptions behind the solution, domain and enterprise architect roles is that these people often have a breadth of experience that goes beyond a single product or technology stack. In other words, their careers are not defined along narrow vendor specific lines. This is largely borne out by what I have seen in the market in terms of the experience people have and the career paths they have taken.
Such specialists will be genuinely skilled at what they do but lacking breadth of vision and depth of understanding that someone with a more diverse background is likely to have.
Is this good or bad? Well I think that depends on what you need for the problem at hand; sometimes you need a very specialized tool for a very special problem, whilst other-times a more flexible tool is best.
One thing to be sure of though, as the technology market grows in breadth and diversity, areas of specialization will deepen. As anyone familiar with web development in the early 2000’s can tell you, the number of stacks and architectures available has grown considerably; as that range increases so does the potential for individuals to specialize; so does the possible combinations of skills a specific job description might call for.
This specialization is reflected in the vendor space where larger vendors have their own subset of roles (think marketecture) that mirror the role hierarchies found in the general market. We therefore have product specialist roles starting to emerge, with people operating at the level of a solution architect but with a background that cannot assumed to be as broad as those from a more general background.
One of the things you’ll notice about this post is that it’s looking at the “structure” of these paths – not so much the “human” stories behind them – people motivations and so on. I may look at that in the future.