Would you like architects with your architecture?

Updated: June 23, 2021 Updated: Architecture

There has been a lot of talk recently about whether organizations need architects. On one hand you have organizations that did away with architects altogether (at least per title) whereas others heavily rely on architects as change agents and are bolstering their architecture teams.

Perhaps there is a healthy middle ground somewhere, or at least a better way to understand your options for organizing your architects, if you choose to have some. My previous thoughts on this rather important topic was hidden inside a past blog post but it’s surely worthy of its own post. So, it’s time for an upgrade and a stand-alone post on a decision-based approach for architecture teams!

Three Architectures: System, Task, Organization

Let’s start with vocabulary. Naming things properly is as difficult as it is important. It’s just very hard for folks to understand each other when words mean different things to them. As with so many IT terms, “architecture” is one of those words. In past workshops we identified three very different things that could be called “architecture”:

Systems Architecture

Each system has an architecture. It has an inherent structure and will exhibit trade-offs in behavior that go along with that structure. This is the architecture that’s commonly defined as the structure and relationships between a system’s components (the Software Engineering Institute maintains a document with common software architecture definitions).

The Task of Doing Architecture

In most cases, you do want to consciously choose what architecture your system should have. That’s doing architecture and a topic that’s much written about. In fact, I have recommended a whole bookshelf on doing architecture. Some of the most popular definitions of “software architecture” also include the “discipline of creating structures and systems”.

Organizing Architecture

Last but not least, architecture is done by people. They’re typically called architects and when we mention “architecture” we might refer to the team that they are working in. So, when an enterprise wants to “strengthen architecture”, they are likely using this definition.

Choosing an Architecture or Taking the Default

All systems having an inherent architecture implies that statements like “we don’t have time for architecture” aren’t terribly meaningful because you’ll be getting an architecture anyhow, although perhaps not one of your choosing (or liking). Since you cannot choose not to have an architecture, you’ll be assigned a default one in this case, which is the oft-cited and much-feared Big Ball of Mud.

However, you can choose whether to have architects or not. If you’re inclined to do the latter, Erik Doernenburg gives a nice talk about architecture without architects. But, as architects we are bound to see shades of gray instead of black and white, so there quite a few more choices.

Organizing for Architecture

Architects like to make decisions based on models, so it seems apt to start with a model for organizing architects. I like the following model:

Going from left to right, we see:

1) Benevolent dictator: An architect or architect team telling developers what to do or how to do things. An important nuance is to what extent the line is unidirectional or bi-directional.

2) Primus inter pares: Architects are embedded into teams where they are just-another-team-member but one who focuses on the system structure and trade-offs, perhaps taking a longer-term view compared to other team members (and using a fancy Latin name).

3) Architecture without architects: Architecture is done within teams, however the task is a shared responsibility across multiple (or all) team members. This can work quite well and is often the preferred model.

4) Inmates running the asylum: This one looks deceivingly like #3, but the difference is that no one is consciously performing the task of architecture. The result is often excessive complexity and reduced velocity, meaning the teams come to a grinding halt.

I can’t take credit for the model - I discovered it in material by Michael Plöd who adapted it from Stefan Toth’s book on software architecture.

How to choose

Decision models are there to help us make decisions. So, how do the options compare? The exclamation, check and cross-out markers give us some hints, but there’s more to it.

#1: Benevolent dictator

Although this model raises some eyebrows (and reminds many of us of The Matrix), it’s often a necessary starting point in large organizations, for example when architecture as a function has been neglected for a good while, there’s excessive technical complexity, lack of decision discipline, no clear strategy, and only a vague notion of the current system estate. If you feel like I called your organization out, don’t fret: such a state is a widespread ailment in large and especially federated enterprises.

When developers and IT managers aren’t able to agree on anything or make disciplined decisions (a well-known source of excessive complexity) and instead engage in endless debates and finger pointing, you might need someone (or a small team) to put an end to the madness and define a strategy along with the role of architecture.

However, as the exclamation mark hints, this model should be used with caution:

• If you bring in a new architect, be careful to not fall for the hit(wo)man—things might end in mayhem just like in the movies.
• Because the architect might be lacking feedback from the actual implementation, this setup is prone to an Architect’s Dream, Developer’s Nightmare scenario (the Matrix references in this presentation from 2007 were surely a sign of things to come in my later books).
• The chances of of receiving feedback increase when your architect(s) ride the elevator to check high-level guidance against reality.

#2: Primus inter pares

This model corrects the primary weaknesses of #1. It introduces shorter feedback loops by placing architects directly into project teams, as a “first among equals”. This brings several advantages:

• The teams gain higher decision autonomy and such can course-correct more quickly.
• Architecture trade-offs can be discussed directly with the development team without the overhead of steering committees and reviews.

This model won’t work for all teams, though. There are several important preconditions:

• To avoid blatant duplication, these teams usually stand on a common foundation to enable the higher degree of autonomy.
• Teams should keep Architecture Decision Records. Autonomy shouldn’t translate into intransparency.

#3: Architecture without architects

This is the model promoted by ThoughtWorks’ Erik Doernenburg. It follows the trend of integrating functions directly into teams, which has notable advantages:

• Architecture is not something that “someone else does it”. Rather, it’s clear that everyone is responsible for a sustainable architecture.
• You’ll have as many architects as you need at any point in time. Perhaps, a major decision has to be made and everyone becomes an architect for a brief time. Other times it’s “hands on keyboard” and everyone is coding away.

They key for this model to work is that architecture is taken seriously, although no one carries the title “architect”. This model works well for mature software delivery organizations, in which development teams have an architectural mindset and decision discipline.

The biggest risk perhaps is mistaking this model for #4.

#4: Inmates running the asylum

This model purports that architecture just happens somehow within the team, even though no one is entirely sure how. The most common excuse is teams claiming to be “Agile” and hence not needing architecture, which we know not to be valid. Another common fallacy is for a team to believe they are mature enough to adopt model #3 but an reality aren’t. Model #3 has to be earned and in most cases can’t be the default.

It’s not a single decision

Now that we understand the trade-offs, how to choose? Architects know that a decision is rarely a single one, so we also find combinations and sequences.

There isn’t a single architecture organizational model for large organizations. The best model depends on many factors, including the state of the IT environment, organizational structures, internal politics, business strategy, and much more. I have two pieces of general advice for large organizations:

Your architecture team’s job is to solve your biggest problems. The best setup is the one that allows it to accomplish that.

Your organization has to earn its way to an effective architecture function. You can’t just plug some architects into the current mess and expect it to solve all your problems.

The gentle dictator

A common combination is across #1 and #2. There is a central architecture team but architects are also embedded into the project teams. Three variants of this combination are common:

• The project architects might form a “guild” in the Spotify sense.
• The architects might belong to the central architecture team but are seconded into the project teams.
• Architects might “graduate” from a central architecture team into the project teams, carrying the central team’s strategy into the teams.

Shift Right

A meaningful progression for most large organizations is from left to right on the spectrum:

If architecture has been neglected or never taken seriously, you likely need a chief architect and a central team to define what architecture means, to recruit people, to take inventory, and to define a strategy. From there you can slowly work your way to the right, depending on how much architectural maturity you can build inside the project teams and how much alignment you can create.

Bounce Back

Alas, we know that strategic paths are rarely linear. The same is true here. A common maneuver is the “bounce back”: you are pushing architectural decision making into the teams but if things get finicky, you might temporarily re-engage the chief architect or the central team. It’s a variant of “if the kids can’t play nicely, the parents have to come in”. Autonomy is earned.

You see this model quite a bit in open source projects that have a benevolent dictator who is keen to have the community drive the evolution of the project. However, they may step in when they feel strongly about a particular issue or when discussions keep going in circles. Python comes to mind.

No Architects? Really?

The next time someone proclaims that they don’t have architects, I invite you to have a closer look. A large Silicon Valley company notable for not having architects introduced the notion of an “area tech lead” after some time, essentially a synonym for “architect”.

Instead of locking into a particular solution, it’s better to understand your options along with the implied trade-offs and constraints. It’ll lead to better decisions and is applying architectural thinking to organizing architecture teams!

Make More Impact as an Architect

The Software Architect Elevator helps architects and IT professionals to take their role to the next level. By sharing the real-life journey of a chief architect, it shows how to influence organizations at the intersection of business and technology. Buy it on Amazon US, Amazon UK, Amazon Europe