The essence of architectural work - Part 1

This blog series is a long-overdue write-up of my presentation “Essential architectural work”. Of course, this is the 2026 version of the contents, i.e., it will also discuss the impact of AI on several aspects of architectural work. However, it is interesting to see that quite a bit of the stuff I discussed 7 years ago and learned over many years did not change. It is as valid now as it was back then. For me, this is a hint that these parts are actually “essentials”, i.e., fundamental aspects of architectural work.

The presentation discussed the Why, the What, the How, the When and the How much of architectural work:

• Why - The purpose of architectural work
• What - The building blocks of architectural work
• How - The tools and techniques of architectural work
• When - The timing of architectural work
• How much - The volume of architectural work

The problem with the How

In this blog series, I will leave out the How. This has several reasons. Most importantly, the How is a huge topic. Many competing and complementing techniques exist, all with their own pros and cons, working better or worse depending on the given context. Therefore, I think it is very hard – if not impossible – to distill a set of “essential” techniques. To be frank, I also did not attempt to distill essential techniques in the presentation. Instead, I discussed a few tools and options that are often forgotten based on my experience. This way, the How part of the presentation was rather about complementing techniques than essential techniques.

Additionally, a quite large body of knowledge regarding the How of architectural work already exists. This body of knowledge may be scattered and not well-organized, but it is out there. I do not intend to create another collection of techniques. I also do not intend to act as a librarian who collects and organizes all the fragmented information – at least not at the moment. Maybe I will discuss some techniques in future posts, but here I want to focus on the essentials, the timeless parts.

The How, the preferable techniques, also tend to change over time. E.g., it was known for a long time that good architecture documentation had great value. Many more or less useful competing documentation techniques existed for capturing the decisions being made. Eventually, Michael Nygard came up with the concept of an “Architecture Decision Record” (ADR) in 2011. Even if it took a few years for the concept to spread, today ADRs can be considered a widely accepted tool for documenting architecture decisions. While this technique became a de facto standard, many prior techniques slowly drifted into oblivion, i.e., the common understanding of How to document architecture has changed.

Finally, the rise of agentic AI in software development will probably have a significant impact on the How, the techniques and tooling regarding architectural work. It has already started to have an impact, with some people using AI more extensively in their architectural work than others. And it is to be expected that it will not stop at the current state of understanding.

This is why I will not discuss the How in this blog series about essential architectural work. If you are a bit disappointed now because you are looking for good architectural work practices, I can recommend the book “Design It!” by Michael Keeling. For me, this is still one of the best books I know about How to design an architecture, as it distills a lot of essential tools and techniques regarding how to design an architecture.

The big brain reset

Regarding the influence of AI, the essentials of architectural work will persist, no matter if the code is written by an AI agent or a human, and no matter if the architecture is designed by a human or an AI agent. Especially these days it is more relevant than ever to discuss the fundamentals as most people seem to suffer from a full brain reset due to agentic AI, meaning that decade-old best practices are re-“invented” for agentic AI and then sold as groundbreaking new ideas. E.g.:

• The importance of non-ambiguous requirements has been well known for decades, even if people tended to ignore it for the wrong reasons, impairing software development. Now, the relevance of non-ambiguous requirements for AI agents is advertised as if it were a groundbreaking new discovery.
• The importance of a sound architecture has been well known for decades, even if people tended to ignore it for the wrong reasons, impairing software development. Now, the relevance of a sound architecture for AI agents is advertised as if it were a groundbreaking new discovery.
• The importance of augmenting context information has been well known for decades, even if people tended to ignore it for the wrong reasons, impairing software development. Now, the relevance of some augmenting context information for AI agents is advertised as if it were a groundbreaking new discovery.
• The importance that implementers and testers should be different persons has been well known for decades, even if people tended to ignore it for the wrong reasons, impairing software development. Now, the relevance that implementers and testers should be different agents is advertised as if it were a groundbreaking new discovery.
• Etcetera.

It feels a lot as if everything we have known for decades was erased from most people’s brains with the rise of AI, especially from the brains of the AI barkers who flood the Internet and the conferences with their “groundbreaking new discoveries how we need to approach software engineering in the age of agentic AI”. In light of these developments, it feels even more important to revisit the fundamentals.

Losing our collective memory time and again

I already discussed parts of the Why in a former blog post. However, this post is more than 5 years ago, and as I pointed out at several occasions (see, e.g., this old presentation from 2017), we lose our collective memory every 5 years as a community. Additionally, with the rise of AI in software development and the related brain reset (as described before), it feels like we have forgotten everything we learned the hard way in the last 50 years.

Thus, about time for revisiting the essentials of architectural work.

Contents of the series

This blog series consists of the following parts:

1. Introduction and a lack of purpose (this post)
2. Architectural anti-patterns due to a missing purpose (link will follow)
3. The economic purpose of architecture (link will follow)
4. The humane purpose of architecture (link will follow)
5. The four activities of architectural work (link will follow)
6. The impact of uncertainty on architectural work (link will follow)
7. Re-evaluating architectural work in the age of agentic AI (link will follow)

In search of the Why

We see time and again that some people question the relevance of architectural work. This questioning was very pronounced during the Agile hype years when the whole notion of an architect was dismissed with contempt. While we moved past the times when the pendulum swung too far into this extreme, we still face such discussions. Based on my perception, the probably biggest driven of these discussions is that we have forgotten over the years Why we do architectural work.

We find a lot of information about What architecture is and How to get it designed (see, e.g., the landing page for software architecture of the renowned Software Engineering Institute). But we see very little discussion about the Why of architecture, its purpose and – based on it – its relevance. If we do a web search looking for the purpose of software architecture, we typically find something along the lines “Software architecture is <some description of the What> and therefore it is important.”

In other words: “Software architecture is important because of what it is.”

Well … ugh, seriously?

I admit I would also question the relevance of architectural work if this is all the explanation I get as to why we should do the work. Such an explanation does not only lack a clear purpose. While sometimes misused as a rhetorical device, justifying the relevance of something with its mere existence does not make much sense. It also sounds a bit arrogant or deceiving, depending on the point of view. It feels a bit as if software architects try to tell other people a message like “I also have no idea Why I am doing all this. But would you kindly refrain from questioning my work because I am sure it is very important (and thus I am more important than you are).”

Again, I would also question the relevance of architectural work if this is the kind of explanation I get.

To be fair: Probably, architectural work suffered the same fate as many activities we see in companies, not only in software development. (Almost) everything that happens in companies starts with a valid purpose. Over time, it becomes part of the company’s processes, and people forget why they were doing it in the first place. Eventually, the activities become ends in themselves, done without anyone knowing why they are done. Nevertheless, everyone insists they need to be done, especially the people doing them (which is understandable because otherwise they would say that they might not be needed, which is an existential risk in companies).

Driving blind and the rise of architectural anti-patterns

Overall, it often feels like we are driving blind when it comes to architectural work. We are driving and driving without any idea where we are going because we forgot why we started driving in the first place. Sometimes, we also lose track of the road because we have no idea where our destination is. We just drive because everyone says we need to drive.

This turns architectural work into one of those activities where most people have forgotten why they are doing it but still fight viciously to continue doing it. There are many situations where we could shrug off such a behavior with a smile or a frown, depending on our current mood. However, with software architecture, the implications are more severe. Without a clear purpose, architectural work is aimless. We do not know why something should be done, what should be done, when it should be done, and how much should be done. There is no goal, and without a goal, there is no alignment. Such a lack of purpose leads to many problems in software development:

• “Agile” architecture a.k.a. emergent architecture
• BDUF architecture
• Hype-driven architecture
• Tunnel-vision architecture
• One-size-fits-all architecture
• Blast-from-the-past architecture
• AI-driven architecture, f.k.a. Stack-Overflow architecture
• PowerPoint architecture
• Trifle architecture
• Stifling architecture
• Disorienting architecture
• Architect as a step on the corporate career ladder
• Etcetera

All these are architectural anti-patterns that almost always lead to bad architectures, making the affected solutions worse. Still, they are quite widespread due to a lack of understanding of the purpose of architecture.

Summing up

With this post, I started a blog series where I will discuss some essentials of architectural work regarding the Why, the What, the When and How much. I discussed why I will leave out the How. I laid out why I think discussing the fundamentals has become increasingly important in the age of agentic AI. We started discussing that most of us of forgotten why we are doing architectural work at all, what purpose it serves, and that this lack of purpose leads to a lot of widespread architectural anti-patterns we can observe.

In the next post (link will follow), we will dive deeper into the anti-patterns because understanding them is essential for good architectural work. Stay tuned … ¹