The essence of architectural work - Part 5

In the previous post, we concluded the discussion of the Why, the purpose of architectural work, by looking at the cognitive and the humane facets of architectural work. We also briefly discussed that AI agents are not able to satisfy these traits of architectural work unless you solve solved problems time and again.

In this post, we will move on to the next dimension of architectural work, the What, and discuss the different activities that make up architectural work.

The laws of architectural work

Before we discuss the activities that make up architectural work, let us first briefly revisit the two “laws of architerctural work”. As stated in the referenced blog post, they are not so much actual laws but rather “hard-won findings”. The first law is:

Every decision has its price. No decision is for free.

This means that there is no free lunch in architectural work. Every decision has some up- and some downsides. There is no “right” or “wrong” in architectural work. There are only more or less suitable decisions ¹. Thus, no matter what some people try to make you believe (usually to buy their products or services), rest assured that their “perfect” architectures are not perfect. They just decided to hide the downsides of the decisions they made.

Asking how to determine the up- and downsides brings us to the second law:

A decision can only be evaluated with respect to its context.

The ups and downs of architectural decisions are determined by the context in which they are made. While a decision may be perfectly fine in one place, it may be nonsense in another. In short: context matters – as so often.

The 4E framework

With these two “laws”, let us move on to the activities that define architectural work. I developed a small framework to organize them. Rest assured: I will not unpack a TOGAF-weight framework. While such frameworks may also have their value in certain contexts, I am not a big fan of them. I prefer minimal frameworks instead of maximal frameworks. Frameworks that support you in organizing and directing thoughts and work instead of trying to capture every possible detail and forcing you to “tailor” them to your context.

The 4E framework is no difference. I designed it with Simon Brown’s C4 model in mind: something simple, yet useful, that you can memorize without effort. In its core, it is 4 words ². As with the C4 model, you may argue that it misses a detail here or there, and it is true. The intention of the 4E framework is not to capture every possible detail. Its intention is to capture the essence of architectural work, and I think it does the job well.

Let me explain the 4 parts of the framework in anecdotal form (as it simplifies the memorization even further).

I discussed architectural work with many people, often, but not always, being developers. When I asked them what the core activities of architectural work are, quick as a shot they came up with Explore.

Explore - Find solution options

Explore is about designing solution options: designing structures and behavior, combining frameworks, tools, technologies, and more – everything needed to design an architecture. Note that most people talked about designing the solution, i.e., they used the singular form and not the plural form as I did. I will explain in the next post (link will follow) why this distinction is important.

The design of an architecture is an essential activity. It also cannot be omitted, as every solution has an architecture, i.e., we always design an architecture. We can only decide if we design the architecture explicitly or implicitly, i.e., accidentally as a byproduct of writing code. While I know there were some proponents of implicit design of an architecture at the peak of the Agile hype, calling it “emergent architecture”, I strongly recommend the explicit variant. ³

Oftentimes, architectural work is reduced to the Explore activities. The problem with only designing a solution is that you don’t know if and how the solution delivers to the Why of architecture, as we discussed it in the previous posts. Maybe it creates a working solution. At least we hope so. But does it minimize the cumulative costs of a system over its lifetime without compromising the correctness of behavior at runtime? Does it condense and structure the problem domain and provide guidance and orientation in the solution domain? Does it improve the lives of the people affected?

Maybe. Maybe not. We do not know. We only designed this solution based on our beliefs in a vacuum (which is another reason why architecture often is a subject of heated, yet groundless discussions).

Therefore, I told my peers that Explore is good and needed, yet not sufficient. I asked them for more. Usually, this made them think for a moment. Then someone mentioned that architects tend to communicate a lot, and thus, this has to be another activity. I.e., they touched Execute.

Execute - Help stakeholders make the best possible decisions

Execute is what I call helping the stakeholders involved make the best possible decisions in their contexts. I do not talk about making decisions as an architect but about supporting other people in making decisions because most of the time, we as architects do not make the decisions. The decisions are made by other stakeholders. Even if we think we make the decisions, more often than not it is an illusion.

E.g., many architects think they decide what architecture gets implemented. But in reality, the developers decide which architecture they implement. If they are convinced that the architecture we designed is good, they will implement it. Otherwise, they will use their significant brainpower to avoid implementing it. Even if we try to force them into implementing “our” architecture by adding reviews and other controls to the process, they will find ways around it. Additionally, it is a futile battle. Energy is wasted that could be used in much better ways.

Therefore, I prefer to say that as architects, we support other stakeholders in making good decisions. This requires a lot of communication, collaboration, convincing, and so on. The point is that people usually do not make bad decisions because they are ignorant or malevolent. More often than not, they make bad decisions because they lack relevant information. As an architect, we talk to multiple stakeholder groups, which often gives us information that other stakeholder groups are missing. Organizing this information and sharing it, thereby supporting the different stakeholder groups to base their decisions on a more comprehensive basis, leads to better decisions overall.

Therefore, this is another essential activity.

Neglecting relevant stakeholder groups

A typical project has a dozen or more stakeholder groups. Each of them has very different needs, a very different view on the project, speaks a different language, and so on. Therefore, it is important to learn to understand them as an architect if you really want to support them in making the best decisions possible in their contexts.

This is a place where I often experience shortcomings. Most people who call themselves architects fall into one of two categories:

• “Developer architects”
• “Non-developer architects”

The first ones are typically senior developers who started to take on more responsibility and thus started to call themselves “architects”, often reinforced by enterprise career paths that put “architect” above “developer”. However, those people are usually still developers, yet experienced ones. It is important for them to continue coding, which leaves them little time to explore areas outside software development. Therefore, their sight is often limited to the needs and demands of developers. While they tend to go to great lengths to optimize quality goals related to development time, they often neglect all other stakeholder groups and their needs.

This is not surprising because they never find the time to leave their developer realm and explore the domains of other stakeholders, let alone understand their needs, demands, and pain points. However, their limited point of view keeps them from identifying the best possible solutions (not regarding developers only but all stakeholder groups). It also keeps them from having the discussions needed with other stakeholder groups to make the best decisions possible, as they never understood the other stakeholder groups and were never able to build the empathy needed for such discussions.

The second category is people who never (or only rarely) wrote code. Often, they come from different domains but are good at structured thinking, problem solving and communication – all needed to be a good architect. Often, they are really good at understanding the stakeholder groups outside of IT. However, they are usually also bad at understanding developers and their needs and demands. They are often convinced they do not require a close understanding of developer work to do architectural work.

While it is true that developer work and architectural work are distinct activities, they are still connected in several ways. First of all, without understanding the needs, demands, and pain points of developers, we omit a vital stakeholder group. It also reduces the likelihood that we will come up with a solution that will minimize the overall costs of the solution over its lifetime with a high likelihood. We cannot understand the cost of change without understanding developer needs.

Last but not least, developers are the people who implement the architecture. If they are not convinced of the architecture, they will not implement it. To convince them, you need to get close to them and show empathy. In this respect, developers are not different from any other stakeholder group. Thus, better do not neglect developers. They are stakeholders, too – and they are important stakeholders.

Finally, both types of architects tend to neglect the operations department as they are neither developers nor non-IT stakeholders. However, if we care about systems that run reliably in production, we better also care about them.

Hence, no matter what kind of architect you are, better make sure you address all relevant stakeholder groups.

If you are more of a “developer architect”, this means less coding and more learning to understand people from other domains. But this is what it means to be an architect. It does not mean that you stop coding altogether. But an architect is not a lead developer. These are two different roles for a good reason.

If you are more of a “non-developer architect”, this means learning to understand IT people, developers as well as operations people. You should also try to understand the technology a bit and maybe even do a bit of coding. You will not write production code. But the ability to read code (which requires that you did a bit of coding yourself) and pair with developers can be extremely helpful in discussions with developers.

Moving on

Even if we have discovered the second essential activity, we still have not solved our problem of the missing Why alignment. We can still only tell all the other stakeholder groups about the solution we designed. But we cannot explain to them why it is a sensible solution and only hope they will like it and not question it.

Therefore, I told my discussion peers that Execute is also essential, but that this is still not sufficient and asked them for more. Then, the silence usually lasted a bit longer. Eventually, someone raised their hand and said something like: “Architects always talk about ’trade-offs’. Thus, I think this has something to do with it.” The person just mentioned Evaluate.

Interlude

Let us take a quick break here before moving on to the third “E” of the 4E framework. Otherwise, this post would become quite long again, and I wanted to avoid these very long posts for a change (even if I am not always successful).

In this post, we discussed the two “laws of architectural work” and introduced the idea of the 4E framework. We discussed two of the “E” and named the third one.

In the next post (link will follow), we will discuss the remaining two “E” and complete the framework. Stay tuned …