The essence of architectural work - Part 2

In the previous post, we started discussing that not understanding why we do architectural work leads to many detrimental anti-patterns in software development. We can observe these patterns time and again:

• “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 architectural anti-patterns lead to inferior architectures, making the affected solutions worse. But as they are so widespread, let us discuss them first before discussing the purpose of architectural work. This way, we can make sure you are able to identify these anti-patterns whenever you see them and can take countermeasures. It also reduces the likelihood that you accidentally fall into such an anti-pattern.

Let us go through them one by one.

“Agile” architecture a.k.a. emergent architecture

We have seen this a lot during the agile hype. Fortunately, we do not see it that often anymore. The idea behind emergent architecture is that architecture is not designed but “emerges” as a byproduct of the implementation. The reasoning was that the refactoring step in a TDD loop would eventually result in a minimal viable architecture.

The problem with this approach is that it only works for very small systems where you require very little architectural work or none at all. For bigger systems, it simply does not work – or if it should work, it would only work by accident. Additionally, this approach usually requires a lot of detours, i.e., unneeded additional effort, to arrive eventually at a sensible architecture. Finally, and importantly, this approach typically only covers functional correctness and code maintainability while neglecting all relevant runtime quality attributes.

Hoping to create a viable architecture using a TDD loop only is a bit like hoping to create a great 20m by 20m picture while touching the canvas with the nose all the time. It is almost impossible to create the desired picture if you only see an area of 10cm at a time. You need to step back to grasp the “bigger picture” and decide about the overall structure, style, and appeal of the picture. The level of detail in a TDD loop is way too fine-grained to make any sensible architectural decisions at this level, and the likelihood that the required decisions will emerge from that loop is close to zero. You will end up with an accidental architecture because nobody explicitly considered the high-level design and how to implement the required runtime properties, and everybody hoped it would magically emerge.

This does not mean that TDD is a bad idea. TDD is an excellent practice most of the time ¹. But it is not a replacement for architectural work.

BDUF architecture

The opposite of emergent architecture is BDUF architecture: Big Design Up Front. The idea behind BDUF is that no line of code must be written unless the architecture is fully designed. The underlying reasoning is that if developers start coding before the architecture is fixed, they would need to rewrite their code according to future changes in the architecture. And as architecture is “about the parts of the system that are expensive to change”, any such changes would be very expensive. Grady Booch probably involuntarily fueled this fear with his famous quote:

“Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.”

Therefore, no code before the architecture is fixed.

The problem with this approach is that it usually results in an overly complex, ivory-tower architecture that ultimately does not fit the needs of the system to be built. Often, it impedes the implementation more than it supports it. There is a powerful saying that the first day of your project is the day you know the least about your project. This also applies to architecture.

If you try to design an architecture completely upfront, you will face a lot of issues that still need clarification. Very often, clarification requires a feedback loop. Sometimes, you need to implement a spike or the like to get the feedback you need. Sometimes, you need more than just a spike to get the feedback you need. You will learn that things that seemed important are not of lesser importance, while other things that seemed to be of lesser importance turn out to be very important. And so on.

Without feedback loops, you attempt to build an architecture that can cover all potential outcomes of the missing feedback loops, resulting in an overly complex architecture. Additionally, there is a high likelihood that the early architectural design will miss some essential requirements that will become apparent only later in the process.

The BDUF approach is a leftover from the architecture-centric software development approach of the 1990s. Its idea was to design a more or less perfect architecture that is fit for all types of future requirements and then let the business experts specify requirements that the developers implement within the architecture. Sounds like a very bad idea? Yes, I tend to agree. While in theory a reasonable approach, we all know from practice that it is not. But that is how architects usually tended to think about software development back then.

Again, the first day of a project is the day you know the least about your project. Thus, we need to balance two opposing forces:

• The longer we wait to make an architectural decision, the more informed and thus better the decision usually is.
• The earlier we make an architectural decision, the lower the required cost of change usually is.

Delaying decisions too long is a bad idea, as it drives up the cost of change. But BDUF is also a bad idea, as it leads to overly complex designs that additionally tend to miss relevant design aspects that are discovered only later in the project, thereby also driving the cost of change too. The sweet spot – as so often – lies between the two extremes. Part of an experienced architect’s expertise is knowing when to make architectural decisions best.

Hype-driven architecture

Hype-driven architecture is if your architects always go for the “latest and greatest”, the stuff the “cool kids” go for. The problem is that such architects tend to jump from hype to hype, building only shallow knowledge regarding the different approaches and technologies.

Because hype-driven architects always “know” about the latest trends and often know all the “arguments” why their latest suggestion must be used, they are often confused with experts while rather being fashion riders. Their technology choices are usually not aligned with the needs of a given project but rather with perceived gaps on their CVs. This way, hype-driven architects often cause more harm than benefit to a project. But at the time when it becomes apparent that their architectural choices do not fit the needs of the project, they are long gone for the next project, talking them into the next architectural fashion.

Hype-driven architects are harmful because their solution designs are almost never aligned with the needs of the system to be built. Quite the contrary, the system usually suffers from the bleeding-edge instabilities of the new technology. Additionally, hype-driven architecture increases the overall complexity of the system landscape by introducing new technologies all the time.

Hype-driven architects are usually more occupied with increasing their own fame (and CV) than with supporting their projects. The problem is that many developers as well as decision makers fall for them – the developers because most of them are attracted by new technology like moths by the light, and decision makers because most of them fall for the promises that the hyped technology would magically solve all their problems (which it never does). This means you may fight an uphill battle if you try to fight a hype-driven architect. However, the trouble you will run into if you let them have their way is usually worse.

Tunnel-vision architecture

Tunnel-vision architecture is what you get if your architect specializes too much in a certain technology. Such a specialization may result in yet another version of the hammer and nail problem. Due to their deep knowledge of a certain technology, it becomes predominant in the architects’ decision-making process, and they start suggesting it as a solution for every problem they see. As a consequence, the solutions they see are all based on their area of specialization, which reinforces the bias.

The fact that software is invisible and very malleable disguises the fact that the architectural choices are often a bad match for the given problem.

The effects are similar to hype-driven architecture. The only difference is that tunnel-vision architects do not introduce new technologies all the time, and that you often do not fight uphill battles against them. However, based on their reputation within their company and their stubbornness (they tend to be very stubborn if you try to separate them from their beloved technology), they may still be very hard to deal with.

One-size-fits-all architecture

The one-size-fits-all architect is the nightmare version of the tunnel-vision architect with a pinch of the hype-driven architect. We have an architect who does not have the experience required for their job but who is power-driven. We encounter this species more often than we might think because power-driven architects push hard to position themselves in the most prestigious projects, no matter if they are qualified for them or not. For them, it is all about power and influence, for their next step on the career ladder, not about competence or – heaven forbid! – doing good architectural work.

Often, they know a solution from their past that worked. While they did not necessarily design that solution themselves, they use as their ticket to the more prestigious projects. As they lack the required expertise, they tend to retreat to the one solution that worked in the past, no matter if it fits the given context or not – resulting in a one-size-fits-all architecture.

Being power-driven, such architects tend to hide their lack of competence behind a surplus of conviction. They hold their opinions obstinately (as they lack the expertise to design a different solution). They sell their architecture as “opinionated” or the like and push hard to suppress alternative solution ideas because that would threaten their position (at least from their point of view). As software is invisible and extremely malleable (and alternative solution designs that could be used for comparison are suppressed), goal-oriented, constructive discussions tend to be really hard, if not impossible, with such persons. Instead, they tend to turn discussions into matters of “belief”, which is quite the opposite of value-oriented work. ²

Personally, I have experienced this pattern several times in various manifestations during my career. It might be hard at first to believe that such “architects” even exist. But it becomes a lot easier to understand if we remind ourselves that most companies are more driven by status and careers than by careful, goal-oriented work. Therefore, we can observe this anti-pattern quite a bit these days, endangering projects and destroying lots of value and money just for the ego of a person. And it is only a small comfort that such behavior is not limited to architects.

Blast-from-the-past architecture

The blast-from-the-past architecture is basically the opposite of the hype-driven architecture. We get it if an architect ignores current developments. The motto is: “If it was good for us in the past, it is good for us now.”

While there is some truth in this motto, it deprives us of potentially valuable options to solve our task in a lot better way. Typically, such architects have quite good knowledge and expertise. However, they are outdated, and not every new architecture approach and technology is pointless. Therefore, ignoring new developments can also increase project risk and effort. Nevertheless, while sharing some of its negative consequences, it is usually less painful than hype-driven architecture.

AI-driven architecture f.k.a. Stack-Overflow architecture

This anti-pattern comes from a different direction than the aforementioned ones. Here, the pattern is: Whenever a developer faces a problem they cannot solve with a few lines of code, they reach out to Stack Overflow and copy the first solution that seems to fit into their code. The pattern is especially widespread in the vicinity of emergent architecture, but it can also be observed in other, often “agile” contexts.

With the rise of generative AI, Stack Overflow lost its dominance. Today, the equivalent anti-pattern is to let the AI agent decide on the solution for a given task. As the underlying LLMs were trained on Stack Overflow and code based on Stack Overflow, the results are comparable.

Such solutions often add many libraries and frameworks, significantly increasing the complexity of the solution. They also only partially fit the problem, and the solution design is complete overkill for the problem. Additionally, such solutions usually do not take architectural needs into account. They only optimize for the number of lines of code written (and with the rise of agentic coding, oftentimes not even this).

From an architectural perspective, this thoughtless library and framework proliferation is a problem – not only from a security perspective but also from other points of view. Understandability. Evolvability. Performance. Throughput. Scalability. Hardware demands. Portability. And so on. This anti-pattern can quickly compromise the architectural goals of a solution. It is easy to add yet another library or framework. It is hard to oversee its consequences.

PowerPoint architecture

We get PowerPoint or ivory-tower architecture if architects detach themselves too far from the implementation work they impact with their designs. It does not mean that an architect needs to code all the time. Actually, “architects” who code all the time neglect all the other non-developer stakeholder groups (because they spend all their time coding). Such persons may be great lead developers, but they typically make lousy architects.

Nevertheless, it is important that architects do not lose touch with development and understand the consequences of their decisions. Otherwise, their designs may look nice on a slide, but very likely do not fit the needs of the project. After all, software architecture comes to life in the code, and thus it is essential to understand the consequences of an architectural design for the development process.

Especially enterprise architects often fall prey to this anti-pattern, caring more about “strategic” architecture than project reality, talking more often to upper management than to developers. While there is value in strategic architecture, it is important that it is also aligned with project needs – and too often, enterprise architects fail to meet these needs.

As a consequence, such architectures are either ignored by the development teams, or they impede the teams. Both alternatives are frustrating and a waste of time and money. Therefore, it is important that architectural work always stays close to development. Architects may not find the time to code themselves as they need to take care of many stakeholder groups. But they still can sit down and pair with developers as often as they find the time for it or find other ways to not lose the connection.

Trifle architecture

A trifle architecture is an architecture that provides too little guidance. By not making relevant decisions, it leaves the developers on their own. While this might sound desirable at first sight, not being limited by architectural decisions, it comes at a big price. Each developer needs to ponder the missing decisions on their own and come up with answers to the missing parts.

In the best case, this leads to various solutions for the same problem, increasing the overall complexity of the solution significantly. In the worst (and more likely) case, we end up with an “accidental architecture”. The developers are so busy solving their task at hand that they forget to ponder the missing architectural questions. This leads to an accidental architecture that is typically not fit for the job, as nobody pondered how to satisfy the required quality properties.

Therefore, it is important to provide the required amount of architectural guidance. Quality goals must be met. While the guidance should not be unnecessarily constraining, too little guidance also has detrimental effects.

Stifling architecture

The stifling architecture is the opposite of the trifle architecture. In this case, the architects tend to patronize the developers by making every little design decision upfront, leaving no room for the developers. However, developers are usually smart and creative people. They do not like being constricted, and they will use their creative power to find their way around the stifling constraints.

Such an approach tends to drive conflict and typically results in more harm than benefit for all people involved. It is important to find the right balance between guidance and freedom. Developers tend to welcome sensible architectural guidance because it reduces their cognitive load. They have enough things to focus on during their daily work that they are quite happy to get guidance on how to implement the required quality goals best.

But they detest being constricted. Thus, provide guidance where needed, and leave room where developers can make their own decisions. After all, they are smart people. Trust them to make the right decisions in their area of expertise.

Disorienting architecture

Surprisingly often, we see a wild mix of trifle and stifling architecture. While essential decisions are partially not made, on the other hand, we find design details which better should be left to developers. Such architectures are not useful but rather irritating and disorienting. They are a sign of an architect who lacks the experience to distinguish between the essential, guiding decisions and the design details that should be left to the developers to decide.

Architect as a step on the corporate career ladder

This final anti-pattern acts as a fire accelerant regarding all the aforementioned anti-patterns: the architect as a step on the corporate career ladder. First, you are a developer, then you become an architect, and finally, you become a manager. This attracts status-driven developers to architect roles, no matter if they have the required qualifications or not. Often, they are power-game savvy enough to push aside the people who would be much better architects regarding their skills and expertise. Of course, the surrounding people perceive very well that they are not good at what they are doing. But being status-aware, such architects tend to do “whatever is needed” to fuel their careers.

Besides leading to lots of unnecessary resentment and conflict, it also leads to bad architectures, serving the companies poorly. The skills needed to be a good architect are very different from the skills needed to be a good developer. I have seen great developers who were poor architects and vice versa. Therefore, architect should be a career path next to developer, and not “above” developer. We need both to be successful. But it only works if we put people into positions based on their skills and expertise, not based on their career ambitions.

Interlude

These were a lot of architectural anti-patterns, but I am sure there are more. These were only the ones I have seen most often over the course of my career. You may have seen different ones. All these anti-patterns share a lack of understanding of the purpose of architectural work. Not understanding why we do architectural work not only makes such anti-patterns much more likely. Oftentimes, it reinforces them because if you do not understand why you do something, you tend to push in some arbitrary direction – usually the one that feels most advantageous for yourself.

This is not malevolence. This is human nature ³. But regarding what we try to achieve with architectural work, it still is harmful. In short:

Without asking why, the value of our architectural work will be accidental, and we become vulnerable to detrimental patterns.

I discussed these anti-patterns in so much detail because we are confronted with them more often than we like. Probably you have suffered from them too in your career. Unhandled, they cause a lot of harm. This is why I used a whole blog post to discuss them. I think it is important that you are able to spot them quickly, to put a finger on them, and to prevent that they will cause harm.

Of course, it is not sufficient to spot such detrimental patterns. We also need to know what to do instead. We must be able to set the direction and steer. This requires understanding the why, the purpose of architectural. Therefore, without any further detour, we will start to discuss the why of architectural work in the next post (link will follow). Stay tuned …