“What architects do I require in my organization?”, “What architect could I be?”. Two different questions. One from a customer, the other from a colleague or job applicant. Both questions are related: They both assume (in a way) a clear distinct separation of the architecture domain into roles. Based on job titles, advertisements and function-descriptions there are dozens of architecture-roles used in the field: information architects, enterprise architects, solution architects, software architects… and so on, and so on. You most likely have a feeling about their supposed meaning and responsibilities, just like I do. 

Though trying to answer the (very legitimate) questions from my customer and colleague I ran into some issues.

First I noticed ambiguousness. For instance, “Domain Architect” has multiple meanings in literature: one refers to architectural domains (e.g. infrastructure), and the other to business domains (e.g. insurance).

A second issue was that multiple titles referred to the same role: for instance, “project architect” often actually refers to the role of solution architect.

A third issue was the lack of a clear formal meaning and scoping of specific roles that are presumably overlapping. For instance: What is the exact difference between an application architect and a software architect? Or between an information and a data architect.

In order to be able to provide suitable answers I needed a clear set of architecture-roles. And as I was not able to find a usable one in literature I choose to create one. Each role in the list should contain a description and scoping in terms of a focus area for each particular role.

I realized I best adhered as much as possible to commonly used terms in the field: These are easier to comprehend for most of the audience, and hence increase the likeliness of adoption.

What is an architect?

I am well aware this exercise requires for a general definition of “architect”. That is a tricky one. Obviously I don’t refer to traditional architects as in the construction industry. But how to define architect without these kind of negations? It is tempting to use the term “IT related architecture”, but that is a too narrow definition, as it does not comprise enterprise- and business architecture. The best I can come up with for this moment is to call it “business and IT-related” architecture.

All architecture-roles address a specific focus area. Although this is the case I think it is fair to state that -in the context of this this focus area- all architecture-roles have similar generic responsibilities:

– Describe the focus area in a structured way on the required abstraction level(s)

– Determine stakeholders and their concerns and involve/inform them when required

– Design and guide changes and improvements in an educated way

– Stay informed about and act upon developments that may impact the focus area

– Define best practices and guidelines

Scoping

For scoping the architecture-roles I chose to use two dimensions that make up the focus area of the role. The first is an abstraction level, which is inspired by phases in Togaf’s ADM. It consists of a strategy, business, application, technology and a project focus.

The second dimension is based on Archimate and consists of data (based on Archimate passive structures), behavior and structure (based on Archimate active structures). These are completed with items interface, governance and context. (The first five mainly focus on the internal enterprise, where context has an external focus).

This approach makes it possible to make a visual representation of the focus areas. Prime focus areas I fill with “1” (green), and the secondary with “2” (yellow)

Results

Analysis resulted in a set of role-categories that are all (direct or indirectly) connected:

Notes:

• This model results from a pragmatic approach to be able to distinguish and explain the several architecture roles. It does not aim to be scientific proof.
• Abbreviations are explained at the end of this blog.
• Categories Enterprise architects and Solution Architects only contain a single role.
• The context for Enterprise-, Solution- and Domain architects is the Enterprise.
• Subject Matter experts have a global context within their subject matter. They are independent from any enterprise, though they may be consulted by an enterprise.
• Any domain may defined within the context of the enterprise. E.g. An IT concept like Business Intelligence (BI) may have a separate “BI Domain architect”.

The categories are discussed in a little more detail:

Enterprise Architect (EA)

Enterprise Architect (EA) is a single role-category. Within the enterprise the EA is responsible to align architecture with business strategy.

According to literature an EA is “responsible to translate business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution”.

The EA defines and organizes the architecture competence, with all due aspects like goals, method, repository, and governance. Usually domain architects are responsible for execution of specific parts of the Enterprise Architecture.

Domain architect (DA)

The Domain architect is an abstract category of architects that are responsible for a for a specific (part of an) architecture domain within an enterprise. Domains are commonly defined by the EA practice as architectural focus areas that require the attention of a separate architecture authority.

Common architecture domains may be based upon an EA architecture framework. For instance, Togaf ADM defines the domains business-, application-, data- and technology architecture).

Domains may be based on a specific concept or technology as well if they have great significance to the organization (see also subject matter architect).

Common domain architects (DA) are:

Domain architects generally report to the Enterprise Architect while their mandate originates from the EA governance model.

Solution architect

A Solution Architect (SA) is a single role category. A SA (sometimes referred to as Project Architect or IT Architect) defines solutions for (sets of) specific business objectives. Common deliverables are Project Start Architecture and Solution Architecture Design.

In an organization with a high architecture maturity the SA has only a limited role: Solutions may already be defined as work packages resulting from gap-analysis between baseline and transition architectures (like Togaf suggest). In that case most (or even all) of the architecture decisions have been made before the project is even initiated. This in contrast to an organization with a less mature architecture practice, where the projects drive a great deal of the architecture. In that latter case solution architects usually interact with the domain architects where it comes to defining the architectural decisions on specific matters.

Solution architects usually report both to their project manager and to an Architecture board.

Concept Architect

The Concept architect is a category of architects that are specialized in a specific (most technical) concept or method. They are not bound to a specific organization and generally perform consultancy services on demand as independent authority. Think of presales, advise on applicability of the concept or assistance with design choices.

The concept architect needs to be able to know the latest developments in the field, solution patterns regarding the concept and the product solutions offered by multiple vendors.

Examples:

Internet of things (IoT) Architect, Business Process Management (BPM) Architect, Business Intelligence (BI) Architect, Service Oriented Architecture (SOA) Architect, Big Data Architect and Enterprise Application Integration (EAI) Architect

In certain cases, when a certain concept is vital for an organization it may be turned into a domain, with a domain architect with the same title.

Platform architect

A platform architect is like the concept Architect globally oriented and independent to a single enterprise. This role is specialized in a specific product-suite (tool-stack, platform), generally from a single vendor. A platform architect usually provides consultancy services. Think of designing specific platform environments for one or a set of solutions, provide coaching or guidance in the setup or application of the product-suite. He or she may be involved as well in tuning the product or solving complex technical issues.

Therefor the platform architect needs to be very well informed about the latest developments of the product-suite.

Examples:

Oracle SOA Suite Architect, Tibco Architect, WSO2-Architect, Pega-Architect

Market architect

A Market architect (also business domain architect -not to be confused with a domain architect) is a category of architect-roles that concern a thorough knowledge of specific markets. He/she knows the characteristics, developments, players and regulations. Main responsibilities are (assist in) developing strategies for specific business goals for a specific business market, mostly together with a business architect.

Examples:

Insurance architect, utilities architect, retail architect

Remarks

One of the conclusions is that roles overlap. This is easy to understand when for instance considering a solution architect. An SA has involvement in almost all areas. Some overlap with (architecture) domain architects is inevitable, even undesired as they are stakeholder and ought to approve the solution.

Another conclusion is that the line between two categories may be very thin and it may be even crossed. For instance, I consider a Internet-of-Things (IoT) architect a matter architect. However, if IoT is an important concept in the organization the EA may decide to define a similar domain architecture-role.

Conclusion

The structure has proved to provide a more distinct idea about the broad architecture practice, and its roles. It facilitates in formulating advise and answers to customer’s and colleague’s questions. I hope it may contribute to your needs as well.

Annex: Abbreviations

ADM: Architecture Development Method
BI: Business Intelligence
BPM: Business Process Management
CA: Concept Architect
DA: Domain Architect
EA: Enterprise Architect
EAI: Enterprise Application Integration
IoT: Internet of Things
IT: Information Technology
MA: Market Architect
PA: Platform Architect
SA: Solution Architect
SOA: Service Oriented Architecture
In a next blog we will discuss the specific personal qualities that are required for each role.