The changing role of architects

Even though the discipline of architecture is decades old (and if you look at the discipline of process management, even hundreds of years), there is no consensus of what an architect actually defines. And the practitioners have not been helpful as well in their self-positioning.

“Back in the day” a lot of architecture groups held one type of architect – the people defining the methods, tools, and standards. The folks who created “the committee of no” (aka the Architecture Review Board), who were excited about frameworks, notations and all those other things that don’t have an immediate impact on what was seen as important for business people. That led to many occasions where architects have been excluded from projects and meaningful conversations/decision making, even though they should be the people at the table who understand how things are “wired up” and give good input when defining the right solution for a business problem.

Today, however, there is a change of the role required: for once, the old role description has not worked out, and the architecture content has become more complex (think about the aspect of co-opetition with your former competitors is requiring to share forces at times, while competing in other situations – that has not happened before). Or on a technical level, solutions have become smaller, and smaller down to a “function as a service” approach in the cloud, which is vastly different from the “in-house, we standardize everything on our ERP system” approach from 10-20 years ago.

This leads to changes in the roles of architects that not only cover the skills of the individual (for example, you did not need to be an outsourcing/cloud contract specialist a few years ago), but also the positioning of what it means to be an architect.

Archetypes of architects

But how do you define the various archetypes of architects then? A good approach is to look at it from two perspectives:

• The scope of contribution (from “low” as in defining the standards but not actively contributing to the solution solving), and
• The degree of specialization from generalist to specialist.

The graphic below shows the four archetypes in a 2×2 matrix, and will give some insight in why you hear different answers if someone asks for an architect to help with implementing a solution.

• In the low/generic corner you find the Methodology Owner, the traditional role of EAs described above. This is a comfortable place where you can define the core methodology (while not being asked to develop the artifacts) and manage the architectural process.
  This could be one reason for the popularity of this position – you are “important” without having skin in the game – no wonder why this does not resonate well. However, even in the future, defining the governance and “rules of engagement” are still important when setting up your architecture implementation and running your architecture program.
• In the low/specialized corner you find the Domain Expert. These are the people who will describe themselves as “Business Architect” or “Data Architect”, or sometimes even more specialized as “Salesforce Architect” or “Security Architect” if they bring some very specialized knowledge to the table.
  This role provides deep technical or domain expertise and creates artifacts or provides detailed analysis for their area of expertise. Unfortunately, the term “architect” is not well specified, and sometimes people call themselves architects just because it sounds nice, but have no clue about architecture concepts, frameworks, practices, etc.
• The high/generic quadrant holds the prestigious role of Strategic Advisor. This is the “seat at the table” role that some architects think they should hold where they can help define the “what” by identifying and framing strategic issues, as well as providing problem-solving expertise.
• The last quadrant holds the Transformation Agent (high/specialized), who is focused on the “how” to implement the “what”. This typically includes defining and implementing transformational initiatives, and supporting the management of change in general.

As one can see the two high contribution roles of Strategic Advisor and Transformation Agent build the bridge between strategy and PMO, which lead to the analyst’s prediction that the Strategy, Architecture, and PMO groups would merge together into one group. Unfortunately, I have not seen this anywhere yet.

The graphic below shows the mapping of activities (and the amount/volume of work shown as bubble size) for one client as an example. It becomes clear that this group has successfully extended their sphere of influence to the strategic quadrant, but is short on the “how” of implementing changes.

When I look into my personal “magic globe” I see the role of Methodology Owner being further reduced (thanks, Agile) to a minimum level, and the role of Domain Expert will further splinter into smaller and smaller specialties before a readjustment to the main domains (strategy, business, data, apps, technology) will take place and roles like “app xyz architect” will become less prominent.

On the strategic/transformation side, I see some progress, but maybe not in the way that the analysts see it (the elevation of the EA group to the table). This would require that the discipline further matures and an agreement on how to measure EA activities would be defined as an industry consensus.
Until then, it will be individuals, some of them former architects, who will get into the driver’s seat regarding defining the “what” and “how”.

Roles in an architecture program

So, how do these changed architecture roles now apply to a program? My recommendation is to look at the various levels of a program:

• Solution level: this is the project that delivers an implementation – a reorganization, a process improvement, or similar. The architecture roles on this level are the Domain Architect or Specialist – people that are mentioned above and hold fancy titles like “xyz architect”. These folks are the ones creating the artifacts and designs, performing the analysis, and coming up with recommendations in their field of expertise.
  However, when implementing a complex solution you need to have someone who brings these individual results together and makes sure that the product of the project is complete, usable, doesn’t have gaps, and does not overemphasize on one area of expertise while lacking quality in the others. The Solution Architect also coordinates with the project/program level and has a semi-role of project manager for the architecture development.
  Also, please note that this role is not included in Scaled Agile, which I think is a big gap in that framework.
• Solution Portfolio level (aka “large solution” in Scaled Agile): here you find the role of Solution Portfolio Manager, who is responsible for coordinating the various workstreams and defining the runways that need to be built before a development can be done.
• On the Enterprise level you find the Enterprise Architect, who’s main task is to start and maintain the system in which architecture development happens. This includes the governance areas, as well as the tool, support, and knowledge management topics.
  This role typically will be supported in the day-to-day work by a Center of Excellence, which is comprised of various supporting roles, such as Developers (in the EA platform, creating scripts and dashboards), Administrators of the central EA platform, and Power Users who will help the teams with methodological support regarding specialized analysis situations – think Simulation, Cost Analysis, or Process Mining as applicable use cases. They also can be the 1st level of support for end users.

Obviously these roles need to be embedded into org structures that are defined as part of the EA implementation. The graphic below shows the application of the roles in a federated governance model:

• First, you see the individual projects (small circles) within the Enterprise, that develop the architectural artifacts by domain experts and put together into a consistent deliverable by the Solution Architect.
• You also see how the Solution Portfolio Manager is coordinating the various developments in his/her architecture segment (larger circles). For now, business as usual as described above.
• What you also see is that each project interacts with the Architecture Review Board; that is one of the governance levels (the judicial branch of government) that we discussed in an episode of our podcast.
• Lastly, you see the EA Center of Excellence (CoE – the “executive branch”) as the service organization that provides its services to all participants in that system, and ensures that things run smoothly.

If your organization currently follows a more hierarchical governance model, you can still use the role definitions above, but your approval and governance organizations will be different, obviously.