The Flavor of an Architect
20th of November 2016Having had vivid and animated discussions with colleagues this week about what type of architect roams the consultancy landscape, it occurred to me that at least in my immediate vicinity the understanding of what each of type of architect does which tasks, or even what types of architects really exist and are not just a synonym of each other. But one could argue, does it even matter? I can agree that in smaller businesses one or two architects might cover the entire spectrum of architectural tasks, but once an enterprise becomes bigger, and encompasses a team of architects, maybe even a few Centres of Excellence, it would be nice to have an understanding between these esteemed individuals (almost certainly each with its proper opinions on the matter) of who performs which tasks. If only to draw up an appropriate RACI.
For me there are several of these flavors that seem to claim similar tasks: The Enterprise Architect, the Business Architect, and the Solution Architect. One might even argument that the Application Architect could be thrown into the mix here. But before mulling over what distinguishes them, let’s look at that one word that unites them: Architect. What is it to be an architect (in a consultancy context, not in the construction world)? Simply put: This is someone whose job it is to link various things together in a consistent, integrated, maintainable and sustainable way dixit Tom Graves). For me the architect is defined by what he does: He guides thought, both of himself and others. His job is to translate the requirements into an architectural model, and to keep the noses of the different stakeholders pointed in the same direction. In this way, he indeed links the different forces active on his focus level (organizational or project) into a unified approach, the glue that holds it all together.
To determine what separates these types of architects, I would consider 3 simple criteria in which to formalize their roles: The scope at which they operate (enterprise-wide or project-centric), how their knowledge type can be described (generalist or specialist) and how close they stand to the technological aspects of their influence sphere. This gives us the following table:
| Scope | Knowledge | Technology | |
|---|---|---|---|
| Business Architect | Enterprise | Specialist | Notions |
| Enterprise Architect | Enterprise | Generalist | Conceptual Knowledge |
| Solution Architect | Project | Generalist | Detailed Knowledge |
| Application Architect | Project | Specialist | Expert Knowledge |
Looking at just these three criteria, one could already surmise that the skillsets needed to perform each of these architect roles adequately are not that alike, and that being good in one type of architect doesn’t automatically make you good in the others. As I said earlier, small companies see these roles merged into a single person or a limited group of people, but this is where necessity forces your hand. Once the resources are there to set up a proper architectural team for your company that can differentiate between these types, you will have a significant increase in quality of work that these people will perform.
This should also matter for those young people out there that are pondering on taking the architect’s career on too themselves. Some (or even a lot of) conscious thought should go into what kind of architect they wish to become. And there will be voices crying out that this is just academic and one should take a more pragmatic take on things, and I do agree that pragmatism is needed in an architect’s day-to-day work. However, these cries for me are too often a covert attempt to hide the fact that the academic part of the knowledge just isn’t sufficiently known, and pragmatism without academic structure is just another word for ad hoc architecture, landing you squarely in the cult of heroes’ section. To diminish academics and let pragmatism rule high might get you good result, but with very little hope for the reproduction of this feat by others.
As for myself, I have always considered myself a solution architect. As any good architect, I have notions of the knowledge and skillsets of the other types, but working out the solution is where my heart lies. It combines the breadth of my knowledge with the gratification of seeing a solution hit the deadline mark and added to the needs and hopefully delight of the users that will start their new way of working. The next step for me would be the enterprise architect flavor. The detachment needed in formulating a roadmap is daunting, but at some point in my career a natural progression would be to no longer work out the different projects needed to bring such a roadmap into fruition, but rather take a step back and oversee the total breath of the roadmap. This is something I can already feel myself moving towards, forged through schooling and the proper mentors, and tempered with personal experiences.
As you could deduce from this article, my thoughts on the matter are: To each his own, and let the strengths of each flavor add to the quality of the architectures on every level of the company.
| Thought | EA | Business Architecture |