There is some form of hierarchy in every organization. It is almost a necessity. And while many organizations try to make the distance between the layers of the organizational hierarchy as transparent and as small as possible, few really succeed. Nevertheless, hierarchy is simply necessary for good business. The same is true in the field of Architecture. Architecture hierarchy is just as necessary. The big difference, as far as I am concerned, is that this hierarchy is not so much about who is boss over who else, but more about interpreting who is responsible for what part of the Architecture.

To make my point, let’s take a step back and look at the differences between roles and functions within Architecture.

Roles and functions

The difference between a role and a function can be described as follows. Roles are linked to the work processes that are performed, unlike functions, which are much more linked to the hierarchical structure of the organization. Staying in the context of architecture, an architect may be assigned the role of Domain Architect, where in practice the person performs the function of a Technical Architect (based on a more general job description) within the hierarchy of the organization.

To further clarify, the person assigned the role of Domain Architect is responsible for all work processes related to a specific domain. The function assigned to this person, that of a Technical Architect, allows the organization to hierarchically position this person with the IT department. If the function assigned to the person were that of a Business Architect, the hierarchical position would not be with an IT department, but rather with another business unit. In both situations, the role assigned to the person would still be that of a Domain Architect.

The Domain Architect

When we look at an organization from an architectural point of view, we can divide the organization into a number of domains. Now, the number of domains and how they are named depends heavily on the framework being used. In this example, I will use the TOGAF Standard, supplemented by what I consider to be an essential domain, the Information Domain. In short, this brings me to four domains.

• Business Domain
• Information Domain
• Application (and data) Domain
• Technology Domain

If someone specializes in or is active in one of the aforementioned domains, for example by dealing with business processes, business functions, roles, etc., then that person can be said to be active in the Business Domain. If someone deals with information concepts and information flows, then that person is active in the Information Domain, and so on and so forth.

Both of the above examples of work in different domains are performed by someone in the role of Domain Architect. So there are several variations within the role of Domain Architect. The same is true for the roles of Enterprise Architect and Solution Architect.

I am often confronted with people who think that a Lead Architect is either a role or a function. This is not the case. A Lead Architect is nothing more than an architect who has been designated to lead a project or program. This title is neither a role nor a function because it does not describe the work processes associated with the position, nor does it say anything about the hierarchical position of the architect within the organization.

Generic architecture roles

The roles described above differ in a number of ways. On the one hand, there is the scope of the system or environment to which the architecture applies (architecture breadth), and on the other hand we have the level of detail of the architecture (architecture depth) [1]. The field of Architecture distinguished four generic roles.

• Enterprise Architect. This role is responsible for the entire and enterprise-wide ecosystem. In practice, however, the Enterprise Architect may specialize in a particular part of the enterprise. When an organization has several Enterprise Architects at its disposal, an Enterprise Architect may specialize in a particular part of the enterprise. Enterprise Architects are part of the architecture capability, which focuses on all aspects relevant to Enterprise Architecture.
• Domain Architect. Domain Architects carry a responsibility for a specific area (called a domain) below the enterprise level. For example, in a large organization, it is common for a Domain Architect to be responsible for everything related to a specific domain, such as the business domain (which includes business functions, processes, objects, etc.).
• Solution Architect. The Solution Architect focuses specifically on a complex application or infrastructure element. For example, consider flagship applications such as a CRM application. Often, such an application has evolved over the years into a mix of legacy and modern components. As a result, in many cases it has become a complex environment. It is the Solution Architect’s job to maintain the reliability of such a flagship application.
• Systems or Software Engineer. Not being an architecture role, these Engineers play a very important role, which is why they are mentioned here. One should not overlook this role. From an architect’s perspective, these engineers are critical in enabling the realization of the system. They are tasked with specifying, implementing, and testing the functionality needed for a business application or infrastructure system. Valued for their expertise, they can provide feedback on architectural decisions.

What about functions?

As we already saw in the image Roles and functions, one or more architecture functions can exist within the context of a role. For example, the role of Enterprise Architect includes the functions of Chief Enterprise Architect and Enterprise Architect.

The role of Domain Architect, as we saw earlier, includes the functions of Business Architect, Information Architect, Application Architect, or Technical Architect (sometimes called IT Architect).

Enterprise Architects are not the Technical Architects of the Enterprise

Origin unknown

The Solution Architect role also has several functions, such as Software Architect, Cloud Architect, or Network Architect, to name a few. These last three functions can be classified under the Solution Architect role because they cover a specific area of focus within a domain. I should note that the Cloud Architect is the exception to the rule, as this role covers not only the Technology Domain, but also the Application Domain.

Back to the hierarchy

When we look at the hierarchy of an organization, the roles of Director, Manager and Employee often exist. The roles of Enterprise Architect, Domain Architect and Solution Architect can be mapped one-to-one. Not because of the management hierarchy, but because of the focus of the roles; the Architecture hierarchy.

The figure above shows the similarities between the relationships of Director, Manager, Employee and Enterprise Architect, Domain Architect, Solution Architect. Directors and Enterprise Architects deal with strategic issues and are concerned with answering the why-question. Managers and Domain Architects deal with tactical issues and answer the what-question. Employees and Solution Architects answer the how-question because they are at the operational level.

Stuck in a loop

Many organizations do not recognize the above classification and have no knowledge that an architecture hierarchy exists. This has everything to do with a lack of knowledge about the field and the inexplicable need of executives to control everything. It leaves the field of Architecture stuck in a loop. Organizations cling to the idea that an Architect is nothing more than a function within an IT department.

As far as I am concerned, the need to continue to spread the message that there is a whole big world outside of IT that also needs architecture attention and support has never been greater. Only by continuing to spread this message together will things begin to change over time (and very slowly at that).

Do you agree with my view? Do you have significantly different ideas? Let me know in the comments section below.

[1] E. Jager, Getting Started with Enterprise Architecture. Apress, 2023.