Evolutionary architecture in dynamic environments with self-organizing teams

Contents

Software developers are often surprised by unexpected events: users employ new features in unforeseen ways, leading to unexpected load on servers; a third-party library suddenly logs personal data after an update, violating data protection policies; the fallback mechanism unexpectedly causes the cache to fill up with particularly data-intensive components. Every software architect knows many more examples.

Alexander Kaserbacher

Alexander Kaserbacher is a consultant specializing in software architecture. He is currently working intensively on evolutionary architecture and platform engineering.

At the beginning of a project, these events were Unknown Unknowns, which no one knew they didn't know. They are typical of complex problems like those in software development and lead to problems, especially in an organizational structure with distributed teams. In such structures, overarching governance guidelines usually exist regarding technologies, programming languages, patterns, and interfaces. Central architecture teams are responsible for defining them. However, strict central guidelines of this kind often hinder effective response to Unknown Unknowns, for several reasons:

• The guidelines typically focus on software quality aspects such as security, maintainability, or reliability. Central units must assess how teams apply the guidelines at different levels of abstraction. They also need to know in advance whether the intended implementation can meet the desired quality requirements at all.
• Standardization slows down software development, as central units are responsible for many decisions, requiring constant coordination of all teams with them. This often leads to bottlenecks.
• The guidelines relieve development teams of responsibility, so they do not feel responsible for externally defined topics.
• Innovation is hampered because development teams strictly adhere to guidelines and do not deviate from them. This lacks feedback on whether they are actually suitable or if there are better alternatives.

Problem-solving in dynamic environments

Since suitable solutions for surprising problems are often unpredictable and unplannable in a dynamic environment, actors must gradually approach a good answer. Similar challenges exist in science, where researchers gain new insights through hypotheses. Experiments and formal proofs confirm or refute these hypotheses, so the approach to new insights is gradual. The more Unknown Unknowns that could be hidden in a software project, the more developers benefit from small steps (hypotheses) that are regularly validated by feedback. Figure 1 illustrates this process.

Development teams view each release as a hypothesis. Regardless of whether it's about choosing messaging technology and databases for high throughput or a failover mechanism to improve availability – instead of following central guidelines, development teams decide on a suitable approach themselves. They implement it within their area of responsibility. They then validate this approach as quickly as possible through effective feedback. For example, if throughput and associated speed are important goals, performance measurements on the live system provide valuable feedback. Goals such as availability are also directly measurable, while maintainability can often be derived from metrics such as coupling or cyclomatic complexity (control flow graph of a program).

The feedback mechanisms show development teams areas for improvement, which they then implement in new hypotheses. This is similar to the evolutionary process in biology, where genetic variation arises locally and decentrally, while natural selection sorts out poor variants.

In the IT context, variation arises in the work results of self-organizing teams, while feedback mechanisms (selection) quickly reveal unsuitable parts. Following biology, this concept is called Evolutionary Architecture. It describes product development that acts dynamically through incremental, emergent practices and regular, qualitative feedback in complex environments.

The interaction between hypotheses and feedback should be rapid and granular. Empirical data like the Four Key Metrics illustrate this dynamic (Forsgren, N. et al.: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations; 2018). They define important metrics that distinguish high-performing teams from others:

• Deployment Frequency indicates how often development teams go through the cycle shown in Figure 1.
• Lead Time for Changes shows how quickly development teams complete this cycle.
• Time to Restore Service and Change Failure Rate describe the risk associated with deploying potentially faulty hypotheses.

For development teams to approach a satisfactory result as effectively as possible, small and frequent deployments with low potential for damage are crucial. Classic governance approaches (see box "How classic governance approaches arise") often stand in the way of this, as manual release and control processes extend deployment frequency and lead time for changes.

How classic governance approaches arise

Software systems consist of several components: modules, services, applications – depending on the context and level of detail, they can be named differently. Together, they form a larger system, be it a single software product or the entire IT infrastructure of a company. Software architects often divide components according to functional criteria, particularly through techniques like Domain-driven Design or architectural patterns like Microservices. An example is an online shop consisting of components like product catalog, search, and shopping cart.

When such systems become so extensive that a single team cannot maintain and further develop them, many organizations split the responsibility and assign individual components to separate teams. One team, for instance, could be specifically responsible for the shopping cart component.

As the number of components and teams grows, organizations face the challenge of managing increasing complexity. Typical problems such as a proliferation of technologies lead to a desire for overarching rules and guidelines. Central architecture teams then take care of defining generally valid standards. This results in rules regarding technologies, programming languages, patterns, and interfaces, as well as specific structuring guidelines.

The hope is to increase efficiency through standardization and unification. Development teams should be able to work faster if they adhere to guidelines instead of spending a long time making decisions and evaluating and weighing alternatives themselves. Once developed components could be reused, including across teams. Operations teams would be more efficient because they would only have to maintain one standardized target environment.

While these classic approaches promise increased efficiency at first glance, they often lead to problems in responsibility transfer and innovation stagnation in the long run.