Dieser Artikel ist auch auf Deutsch verfügbar

But before we enter into this topic, I would like to clarify the terms complicated and complex. This will help us later when it comes to understanding the role of software and IT architecture in large projects. My explanations are based on the well-known Cynefin Framework from British researcher Dave Snowdon.

Complicated

Complicated (Latin complicare, “fold together” in the sense of “intertwined”)

Complicated systems consist of many parts or details whose interactions we can predict specifically and precisely. A sewing machine consists of many individual parts and interrelationships, and we can predict its behavior with great precision. It is possible to learn how to deal with complicated systems based on rules and defined procedures.
Examples of such systems are:

Rules and processes are sufficient for dealing with complicated systems.

Figure 1: Complicated mechanical system with gears and axles, generated by midjourney
Figure 1: Complicated mechanical system with gears and axles, generated by midjourney

Early software and IT systems were frequently complicated, meaning we could predict their behavior fairly precisely [1]. Think of simple algorithms like QuickSort or single-user CRUD applications as examples.

Complex

It’s true – even complicated systems can be quite difficult to manage, but it can also be much worse:

Complexity (Latin complexum) refers to the behavior of a system with many elements with relationships that are often not deterministic or predictable. The behavior of such systems is rarely predictable.

Sources: Wikipedia, Cynefin

We cannot predict the overall behavior of a complex system based on the sum of the individual behaviors. For this reason, the results of complex systems are frequently not repeatable. Complex systems are characterized by unpredictability and (apparently) random influences.

Examples include financial markets, ecosystems, or the weather (over the medium term). We cannot deterministically (in the sense of a formula) make dependable or specific forecasts for any of these. Despite plenty of experience and effort, we can at best determine approximate values for the future states of complex systems. Fixed rules and processes fail us here. We have to fall back on short feedback cycles, heuristics, and experience.

Table 1 summarizes and contrasts the key characteristics of complicated and complex systems.

For complex systems, we need experience, heuristics, and – above all – feedback.

Complicated Complex
Many influencing factors Many influencing factors
Stabile, linear relationships Dynamic, non-linear relationships
Cause-effect relationships are non-trivial but deterministic and comprehensible. Cause-effect relationships are not necessarily repeatable
Calculable, deterministic Not calculable, non-deterministic
Plannable Not plannable

Table 1: Complicated versus complex [2]

How do these terms help us understand the role of software architecture?

Complexity lurks within large projects/systems

Figure 2: Yoda juggles many objects in the rain, generated with midjourney
Figure 2: Yoda juggles many objects in the rain, generated with midjourney

Large software and IT projects with many participants prove to be complex systems with very low plannability. In such systems, the architects must frequently take into consideration many factors at once, without being able to precisely calculate or specifically plan the consequences of their decisions. In Figure 3 (inspired by Uwe Friedrichsen from [3]), I illustrate how today’s IT projects tend to be complex in nature, although also with a sprinkling of complexity, of course. In typical IT projects, there are usually tasks that we can reliably solve with a schematic approach. Unfortunately, we must also deal with tasks of another kind altogether…

Figure 3: IT projects were previously complicated, but today they are complex. Adapted from Uwe Friedrichsen
Figure 3: IT projects were previously complicated, but today they are complex. Adapted from Uwe Friedrichsen

Architecture contains uncertainty

Architects of large (and therefore complex) systems must deal with considerable uncertainties and vagaries. The term size refers here not only to the pure technical scope (e.g. lines of code) of IT systems but also to additional elements, such as:

Figure 4: The amount of uncertainty increases with the size of systems
Figure 4: The amount of uncertainty increases with the size of systems

Let’s summarize what we have covered so far:

In large (complex) systems, you as the architect must make decisions in the face of considerable uncertainty. Your work largely consists of balancing many different factors, very few of which can be addressed with well established procedures.

Sounds difficult. What can we do?

That’s right, it does sound difficult, and probably also somewhat vague.

For simpler systems (i.e. merely complicated), we explained the tasks involved in designing system architecture in article 3 of this series.
As a reminder, they are shown here again in Figure 5. However, I have updated this version slightly to highlight the areas where there is a particular risk of complexity arising. More color also means more risk.

Architecture tasks, repeated from article 3
Architecture tasks, repeated from article 3

Fortunately, we in IT have at our disposal a tried-and-tested tool for dealing with such difficult situations: rapid feedback and adaptive behavior. If you find yourself as an architect in a complex development project and have to make important decisions, try the following tactics:

In general, you should be proactive in such projects and view yourself more as an entrepreneur than as just someone taking orders. The amount of time that must be spent on communication is much higher than in simple projects. Assume that you will have no time left over for pure coding. After all, that is primarily a complicated task and one that you can delegate.

Summary

The path from small (a.k.a. complicated) systems and projects to very large (a.k.a. complex) ones is rocky and steep. You will need significantly greater communication skills (i.e. soft skills), empathy, and perseverance. If the range of stakeholders is diverse, expertise in diplomacy, corporate politics, project management, enterprise architecture management, and requirements engineering will be major assets, not to forget a solid overview of current and less-than-current technologies[5]. As a reward, you can expect great responsibility and extensive influence over long-term project/architecture decisions. On the downside: In such roles, your contact with actual source code will likely be restricted to your (minimal) free time.

With that in mind, may the power of smart decision-making be with you.

Acknowledgements

Many thanks to Gerrit Beine for inspiration and “m” for a thorough review.

Sources

  1. For the pedants among you: Yes, I am aware of the undecidability of the halting problem.  ↩

  2. Dave Snowdon: Cynefin Framework. Conceptual framework to aid in decision–making, identifies five categories (clear, complicated, complex, chaotic, and confused) and attempts to offer assistance in each of these areas. Compact introduction on Wikipedia, original at https://thecynefin.co  ↩

  3. Uwe Friedrichsen: Komplexität – Na und?  ↩

  4. Gregor Hohpe calls this the architecture elevator and refers to the upper (management) levels as the penthouse and the pure technology as the engine room. Personally, I find the term board room more appropriate for management. What matters here is the pronounced abstraction of specific technology and the close connection to the business.  ↩

  5. If you are wondering where to find such an all–singing, all–dancing expert, join the club. I am well aware that such a broad spectrum of skills and abilities is extremely rare, but which of them would you be willing to leave out? If you are personally lacking some of these traits, then approach large systems together with a small group of architects. I have offered a suggestion of this nature in article 4 of this series under the name of “architecture agents.”  ↩

TAGS