Differences Between Architecture Roles
Apparently there are a lot of confusion over the differences between various architecture roles. I’m repeatedly asked about them in diverse contexts and I’ve found that I keep reiterating the same arguments and replying to the same set of objections. Therefore, I decided to capture my understanding of the matter to refer interested parties to, and there’s no better place to do it.
I’ve put together a simple sense-making framework to illustrate the difference between these three roles. It is definitely not the universal truth, but the framework is sort of working in the context of enterprise IT in all industries I’ve worked for so far: e-commerce, finance, telco, and public transport. My exposure to IT consultancy it too limited to be confident here, but I suspect that there are matching points as well.
The following diagram illustrates the framework and captures the essence of three well-known architecture roles: Technical Architect, Solutions Architect, and Enterprise Architect.
I use three dimensions, or axes, to ‘factorize‘ what constitutes the scope of an architecture role:
- Life-cycle disciplines — coherent sets of activities performed in a particular stage of a project or programme. The sequence is irrelevant here, but, in general, those on the left are performed before those on the right. The list of disciplines is incomplete, but adding every existing discipline neither adds any value, nor is possible at all.
- Level of detail — amount of specific information required to fulfil objectives of the role. Low means superficial generalized view, high means complete end-to-end understanding.
- Focus — a particular work stream in an enterprise that everything of above is relevant to. What is important is that there are more than one work stream, so I’ve assumed that few programmes are in place.
Now, a role is defined as a box that occupies a particular region. Projections to the axes together provide a characteristic for each role, which are elaborated a bit further in the following. The volume of all boxes is the same as human being can only do so much. Well, I’ve never met superheroes. In architecture roles, anyway.
Technical Architect (TA) predominantly focuses on a particular implementation technology. The technology is most likely employed across many projects or programmes in an enterprise and hence TA gets involved all over the places. However, it is not normally expected of Technical Architect to pay close attention to complete solution life-cycle.
Technical Architects usually have some hands-on involvement in the delivery, providing technical leadership for development teams, and defining standards and practices to stick to. Being hands-on requires quite high level of detail to be taken into account by person in this capacity. Because of it, you can rarely find a TA doing more than one technology at once. This specialization is reflected in the name of the role, e.g. Java Architect, .Net Architect, Infrastructure Architect, etc. These variations are shown on the diagram with dashed lines.
Solutions Architect (SA) is assigned to a particular project or programme in an enterprise to ensure technical integrity and consistency of the solution on every stage of its life-cycle. Solutions Architects are not normally hands-on as coordination of ongoing technical activities takes most of his time. Instead, they get involved with all aspects and activities of an initiative: from concept definition, through requirements analysis and implementation, ending up with handover to IT ops and business-as-usual ongoing maintenance. Consequently, SA have to be a sort of generalist in order to be able to contribute sensibly to all these activities.
Of course, having a Solutions Architect for every single project is an overkill. If the initiative is confined to a single implementation technology that is proven in a similar context, it is usually sufficient to assign a Technical Architect. However, when technology-related risks are perceived as being significant, having a Solutions Architect in a project is advisable. Such situations are characterized by uncertain requirements that are likely to change, unproven implementation technology or multiple implementation technologies at once, outsourcing of development to an offshore team, etc. Good Solutions Architect looks after technical soundness and integrity of the solution the same way as good Project Manager looks after schedule and budget constraints.
Here, I’d like to digress and point that, as I see it, the role of Solutions Architecture in the enterprise IT context is the closest match to what is called Systems Engineering in the context of industries such as aerospace and defence. The scale of endeavours that enterprises undertake both in public and private sectors has grown significantly over the last decades, but apparently the level of engineering practice is lagging behind. I’m absolutely convinced that the major point of growth for Solutions Architecture for the upcoming decade is going to be re-examination and adoption of practices that are widely developed under the umbrella of Systems Engineering discipline.
Enterprise Architect (EA) looks after the whole enterprise, as name suggests. She is interested in rigorous description of the enterprise in terms of its business entities, their properties, and relationships between them and external environment. EA is concerned with the whole set of life-cycle disciplines, and every employed or prospective implementation technology. Similarly she is looking across programmes to ensure that the enterprise as a whole has integrity and consistency. However, the level of detail EA can possibly take into account is quite low and superficial, so she have to delegate all but policy-level decisions to specialists allocated to a particular work stream.
A special case of EA is Enterprise IT Architect (EITA), who is concerned with the holistic view of the information and technology within the enterprise; however, everything that was said above about the EA role applies to EITA role as well. Note that the framework fails to make a sensible distinction between EA and EITA. Adding fourth dimension would have helped, but the diagram would become messy.
That’s just about it. Important thing that one shouldn’t expect a ‘natural’ career progression through these architectural roles. A programmer with excellent skills can assume the role of Technical Architect in a project, but in order to become Solutions Architect he have to give up some of his control over implementation decisions. Similarly Enterprise Architect’s control over implementation decisions is even more indirect and takes the form of policymaking and governance. Of course transitions between these roles happen quite often, but they are far from easy and natural.
As a summary, a compact form of what has been said above looks as follows. Technical Architect works within a solution, Solutions Architect translates a problem to a solution, and finally Enterprise Architect defines which problem need a solution.