The book "Evolutionary Architecture. Continuous Change Support

It's time to take a fresh look at the postulates that have remained unchanged over the years. The dynamically changing world dictates its own rules, including in computer architecture. The ongoing changes require new approaches, forcing rigid systems to become flexible and adapt to new conditions. Is long-term planning possible if everything changes continuously? How to prevent a gradual deterioration of the architectural solution over time? Here you will find answers and recommendations that will protect the most important characteristics of the project in the context of continuous changes. “This book marks an important milestone indicating the current level of understanding of the problem. As people become aware of the role of software in the 21st century, information on how to respond to changes, while maintaining what has been achieved,

Evolutionary architecture: traps and anti-patterns

We spent a lot of time discussing the proper levels of connectedness in architecture. However, we also live in the real world and see many connections that damage the project’s ability to evolve.

Two bad design practices have been identified that manifest themselves in software projects: traps and anti-patterns. Many developers use the word anti-patterns as a slang term for “bad,” but its real meaning needs clarification. Antipattern software consists of two parts. First part: the anti-pattern is a practice that initially seems like a good idea, but turns into a mistake. The second part: for most antipatterns, there are many much better alternatives. Architects notice many antipatterns only in retrospect, so they are hard to avoid. The trap at first glance looks like a good idea, but immediately manifests itself as a bad way. In this chapter, we look at traps and anti-patterns together.

Technical architecture

This section focuses on common practice used in industry, which is particularly detrimental to the ability of a team to evolve architecture.

Antipattern: Vendor King

Some large enterprises acquire Enterprise Resource Planning (ERP) software to solve common business problems, such as accounting, inventory management, and other routine operations. This works if companies are willing to bend their business processes and other solutions in order to tailor this tool, and can be used strategically when architects understand the limitations and benefits.

However, many organizations become overly ambitious for software of this category, which leads to antipattern vendor king, whose architecture is entirely built on the basis of the supplier’s products, which pathologically binds the organization to this tool. Companies that purchase vendor software plan to increase the package using its plug-ins to extend the core functionality to bring it into line with the enterprise subject area. However, for a long time, an ERP tool cannot be sufficiently tuned to fully realize what is needed, and developers discover their helplessness as a result of the limitations of the tool and because they have made it the center of an architectural universe. In other words,

In order to avoid the anti-pattern, the software should be considered simply as another point of integration, even if it initially had a wide range of responsibilities. Assuming integration at the initial stage, it is easier to change useless characteristics with other integration points, overthrowing the king from the throne.

By placing an external tool or platform at the very heart of the architecture, developers have significantly limited their ability to evolve in two main directions, namely, technically and in terms of the business process. Developers are technically limited by the choice of vendor for storage systems, supported infrastructure, and a host of other restrictions. From the point of view of the subject area, a large encapsulation tool ultimately suffers from the “Trap in the last 10%” anti-pattern. From a business process point of view, this tool cannot support optimal workflow; This is a side effect or trap in the last 10%. Most companies complete submission to the platform, replacing processes, rather than trying to set up a tool. More companies will do so

The principle let's stop work and call it success is one of those that developers usually take into account when dealing with ERP packages in the real world. Since they require a significant investment of time and money, companies are reluctant to accept them when they are not working. No technical department wants to accept a loss of millions of dollars, and the tool supplier does not want to agree to a poor multi-layer implementation. Thus, each of the parties agrees to stop the work and call it success with most of the unrealized promised functionality.

Do not associate your architecture with the king-supplier.

Instead of falling victim to the anti-pattern of the king of the supplier, try to view the supplier’s products as another integration point. Developments can isolate changes in the supplier's tool from the impact of their architecture by building layers of countering destruction between integration points.

Trap: holey abstraction

All non-trivial abstractions are to some extent full of holes.
- Joel Spolsky

Modern software rests on a tower of abstractions: operating systems, platforms, dependencies, etc. As developers, we build abstractions so that we do not have the ability to constantly think from the lower levels. If developers needed to translate binary numbers that come from hard disks to text for a program, they can never do anything! One of the triumphs of modern software is how well we can build efficient abstractions.

But abstractions are costly, because there are no perfect abstractions, and if they were, then they would not be abstractions, but something real. According to Joel Spolsky, all non-trivial abstractions have a hole (flow). This is a problem for developers, because we believe that abstractions are always accurate, but they are often destroyed in an amazing way.

The increased complexity of technology stacks has recently turned abstraction into a destructive problem. In fig. 7.1 shows a typical technology stack, dating back to around 2005.

In this stack, the name of the supplier on the blocks varies depending on local conditions. Over time, as software becomes increasingly specialized, our technology stack becomes more complex, as shown in Figure 2. 7.2.


As seen in fig. 7.2, each part of the software ecosystem has expanded and become more complex. As the problems faced by developers become more and more complex, their solutions also become more complex.

Original holey abstractionwhere a destructive abstraction at a low level leads to unexpected chaos, is one of the side effects of increasing complexity of the technology stack. What if one of the abstractions at the lowest level fails, for example, some unexpected side effect from the seemingly harmless database call? Since there are so many layers, this failure will move to the upper part of this stack, possibly causing “metastasis” on its way, manifested in a deeply embedded error message in the UI. Debugging and retrospective analysis become more difficult, the more complex the technological stack.

Try to fully understand at least one level of abstraction, which is below the level at which you usually work.
- Sages software

Although understanding the layer below is good advice, it is becoming more and more difficult to follow as software specializes and becomes more complex.

Increasing the complexity of the technology stack is an example of the problem of dynamic equilibrium. Not only does the ecosystem change, but its parts also become more complex and confused over time. The proposed protection mechanism for evolving changes, namely the use of fitness functions, can protect the fragile junctions of the architecture. Architects define invariants at key integration points, such as suitability functions, that work as part of the deployment pipeline, ensuring that abstraction does not start in an undesirable way.

»More information about the book can be found on the publisher's website.

For Habrozhiteley a 20% discount on the coupon - Evolutionary architecture