The essence of architectural work - Part 6

In the previous post, we introduced the idea of the 4E framework and discussed the first two of the “E”. In this post, we will discuss the remaining two “E” and complete the ideas of the framework.

Evaluate - Identify the trade-offs

We already saw the name of the third pillar of the 4E framework: Evaluate is about identifying the trade-offs of a solution idea. We look at the upsides and downsides of our different solution options. This is where the plural “options” becomes essential. I mentioned in the previous post that people very often only consider a single solution in their architectural work.

However, there is never just one possible architecture ¹. There are always several solutions possible, and it makes sense to explore more than one option long enough until we are able to understand their pros and cons clearly:

• Which one offers the best balance with respect to the required quality properties?
• Which one has the biggest probability to minimize the overall costs over the lifetime of the system?
• Which one minimizes cognitive load and offers the best guidance?
• Which one improves the lives of the people affected most?

Note that it is not about being the best in everything, but about the most suitable solution overall.

This is an essential activity as it directly delivers to the Why and the first law of architectural work. It is also a required prerequisite for making sensible decisions. Otherwise, decision-making is usually reduced to gut feeling, personal preferences, and IT folklore.

If evaluating the trade-offs, we need to make sure to keep all perspectives of all stakeholder groups in mind. What is important for one stakeholder may be unwanted by a second one and irrelevant for a third one. We also need to balance this additional dimension. ²

Based on my experience, especially “developer architects”, i.e., senior developers who call themselves “architects”, tend to limit their evaluation scope to developer needs like maintainability or evolvability. While those properties have a significant value (especially if pondering the cost of change), they are just a fraction of the overall picture. And sometimes other properties can be even more important – like it or not.

Evaluate also gives us relevant input for Execute. Without knowing the pros and cons of different solution options, we have little useful input to support other stakeholders in making good decisions. Knowing the trade-offs of several options gives you a solid basis for such conversations.

Nevertheless, the most important activity is still missing based on my experience. That is why I tell my peers that even if they have named a third essential activity, I still miss the probably most important activity of all. This is the point where I usually get a long silence first, followed by a “We give up. Please tell us.”

I already mentioned it implicitly, but it is essential to make it explicit. Also, the second law points to it. I talk about Examine: Understanding the problem.

Examine - Understand the problem

Examine is about understanding the problem space holistically:

• What is the task?
• Which functionality is required?
• Which quality attributes are relevant?
• How much time is available?
• How much budget is available?
• Which organizational constraints need to be taken into account?
• Which technological constraints need to be taken into account?
• Which business constraints need to be taken into account?
• What are the short-term risks?
• What are the long-term risks?
• Are there relevant lifecycle considerations to be taken into account?
• And so on …

From my perspective, this is the most important (and most often neglected) activity, as it is the basis for all other activities. Without this information, we act without focus and context. We cannot know if we are on the right path if we act inside or outside of the given constraints. Figuratively, we would be shooting in the dark with our architectural work as we have discussed it so far:

• Explore – We cannot design sensible solution options without Examine.
• Evaluate & First law – We cannot evaluate the options without Examine.
• Execute – We cannot have meaningful discussion with other stakeholders without Examine.
• Purpose – We cannot satisfy the Why, the purpose of architectural work without Examine.
• Second law – We cannot satisfy the second law of architectural work without Examine.

It should be clear that this activity is absolutely essential. Nevertheless, I have seen solutions based just on personal opinions way too often. I cannot count the number of times when people proudly presented their – usually conference-driven – architecture before any of the requirements were defined. It felt like: “We have no clue what we are meant to do, but this did not prevent us from defining an architecture.” I think this is a very bad idea in terms of sensible architectural work in particular, and as well as in terms of professional work in general.

Thus, make sure you have done enough Explore that you are able to come up with sensible architecture options and know enough to assess them in a good enough way (depending on the given context). Note that this is not a vote for BDUF (Big Design Up Front). I described a causal dependency, not a process. There are many ways to resolve these causal dependencies. We will discuss them in more detail in the next posts of this series.

Understanding the problem does not come for free. It is sort of a hunter and gatherer activity. I know a lot of architects who think that it is not their job to collect the information needed. And depending on your setting, there might be other roles that are officially responsible for gathering this information. However, if you want to be able to do a good job as an architect, you had better not expect them to deliver the information you need for getting your job done on a silver platter.

At least, I never found the information ready I needed to do reasonable architectural work. Sometimes, there was a better or worse collection of business requirements available. Rarely, a few quality demands. But never enough to start reasonable architectural work. Therefore, be prepared to collect the information you need on your own. Be prepared for running your own workshops, conducting your own interviews, working through the available documents, working through existing code, etc. on your own. It is essential for good architectural work that you build an encompassing picture of the problem space.

Again, this is not about BDUF, but you need to collect the required information before you make architectural decisions – and usually it is you who needs to collect it.

Putting it all together

This is the point where I stop annoying my peers by asking for more activities. We have the four activities in place that make up the 4E framework:

• Examine – Understand the problem holistically
• Explore – Find possible solution options
• Evaluate – Identify their trade-offs
• Execute – Support stakeholder making the best possible decisions in their contexts

This is essentially what architectural work is about. Basically, it is about general problem-solving and maximizing impact in a specific domain. We have seen that there are some causal dependencies between the 4 activities:

• Examine is needed to kick off everything else
• Explore is needed for evaluation and execution
• Evaluate is needed for execution

Additionally, there are feedback loops:

• Explore may point out gaps in the examination
• Evaluate may point out gaps in the examination and point towards not yet considered solution options
• Execute may point out gaps and new ideas regarding all other activities

It should already be clear that a strict “from first to last” will probably not lead to a good architecture. We need some feedback loops to arrive at a good solution. This leaves the question of when to do what, and how much to do when. These two questions will accompany us through the next posts in this series.

AI and the 4E Framework

Before we move on to the next part, let us briefly look at AI and the 4E framework. As always, the question is whether AI can take over architectural work. Let us go through the four activities:

• Examine – It is unlikely that AI can take over this phase (unless we are reinventing the wheel, see the discussion in the fourth post of this series). Getting people to provide the needed answers is often hard work, and getting multiple stakeholders to agree about something is even harder work. This has a lot to do with reading humans and their emotions, and often it has to do with reading between the lines. This is something AI simply cannot do. Still, AI can support us in understanding the problem, and we definitely should leverage this support. It can also document and organize the knowledge we collect. AI agents are good at that, and often they are more careful and thorough than humans doing it.
• Explore – This is the creative part. We still lack a good body of knowledge on how to map the needs and demands of a problem domain to appropriate architectures. Therefore, AI solutions also lack the knowledge of how to do it. This is a task that cannot be mastered simply with knowledge but also needs a certain level of expertise. Therefore, AI cannot take over this part either (again, unless we are reinventing the wheel). However, it can support us in showing potential solution options that we might have missed. It can also act as Advocatus Diaboli to sort out obviously inappropriate options when we try to reduce the number of options. It can also document the solution ideas we gathered, including the reasoning why we sorted out some of them upfront.
• Evaluate – Here, AI solutions can be very useful sparring partners. They are good at pointing out potential advantages and disadvantages of solutions, and the more context we provide about the task to solve, the better their input. In not too complex scenarios, they may take over the whole evaluation work (we still need to validate their findings). Again, they are especially useful to document findings in a concise and structured way, and they can help us identify areas we may have overlooked.
• Execute – Did I mention documentation? Of course, documentation is not everything, especially when it comes to convincing people. But good documentation, especially good illustrations, can be very useful for the discussions we need to have. Still, supporting humans in making the best decisions possible in their domain is still a very human activity. Again, it involves reading humans and their emotions, understanding their needs and pains – which AI cannot do.

This leads to the same conclusion as the discussion of AI and the purpose of architectural work: Good architectural work still needs humans (again, unless we reinvent the wheel – see above). Nevertheless, AI can significantly support our work, and the work of an architect will change with AI. We can focus more on delivering actual value according to the purpose of architectural work instead of spending significant amounts of our time on routine work. Also, in many situations we get a powerful sparring partner, we should make use of.

But as much as AI can support us with architectural work, the What of architectural work reminds us of its third purpose:

Ultimately, we create software for humans.

Interlude

This concludes the discussion of the What, the essential activities of architectural work using the 4E framework as guidance.

It became clear that AI agents cannot take over these activities (one last time: unless you are re-solving a solved problem). Still, they can support us in our architectural work, and we should leverage their possibilities.

In the next post (link will follow), we will move on to the When and How much of architectural work. Stay tuned …