Software architecture is an emergent property

If you pay attention to complexity theorists you might notice that they start by emphasizing the difference between various classes of problems. For example, the Cynefin framework distinguishes between simple, complicated, complex, chaotic (there is also disorder, but let's leave it for another time).

The typical issues in software development oscillate between the complicated and complex domains. On the one hand, a complicated problem is a deterministic one. In a complicated domain, you detect problems, devise analyses for them and extract precise answers that you apply directly.

One the other hand, a complex problem is one that is not necessarily repeatable, and it is the result of multiple agents interacting with each other. In a complex domain, it is essentially impossible to predict outcomes precisely. Instead you start from a hypothesis that seems to make sense, you check it to build an empirically verified theory, and then you react.

Complex is not necessarily worse than complicated. Neither is the other way around. However, it is important to distinguish between them because otherwise you risk of approaching a complex problem through a complicated mindset.

Controlling software architecture has long been approached as a command and control type of problem: the architect lays out a master plan at the beginning, and development follows it in every detail. In the best case, some adjustments are allowed during development, but they are always subject of architect's approval. According to this view, architecture is a deterministic artifact and it approached from the point of view of a complicated mindset.

A different point of view says that architecture is not a picture, but the structure defined in the code. The current structure of the code is the result of multiple forces. Multiple developers work at the same time in different corners of the system in order to build new functionalities. Developers work together with product owners, testers, designers and other stakeholders and the system is shaped as a result of this interaction - often relying on social behavior rather than on rigorous planning. Furthermore, the actual technical solutions are not built in vacuum, but they are also subject to the constraints posed by the existing state of the system, and by the underlying technologies and frameworks used in the system.

In other words, architecture is an emergent property produced by multiple agents interacting constantly with each other. This places architecture in the complexity realm.

This suggests that approaching architecture through a prescribed ordered (or even worse, simple) lenses can have a limited impact. More suitable is to rely on setting boundaries and using attractors. For an entertaining brief explanation of how to steer emergent behavior, listen to Dave Snowden's comparison of the different ways of organizing a children's party.

A key element of this approach is that neither the boundaries nor the attractors are static. Instead, they are to be reshaped constantly in order to achieve desired emergent properties.

Daily assessment offers a game for steering the architecture. The game combines social interactions with hard checks against the actual data. Architecture is constrained through an explicit contract between all players. This contract changes over time through social interactions and common decisions. No single person is in control, yet the situation is controllable.

An interesting effect of this approach is that if you want to control the quality of the architecture, you focus less on what exists in the system at any given time, and more on the types of problems that are being explicitly looked at. For example, as long as developers only look for granular issues related to low level technological issues (such as memory leaks), you should not be too confident on the overall architecture. Once high level constraints are placed on dependencies, or on domain-specific patterns, your confidence level should raise.

In this game, the current state is less important. The level of the game matters more.

Posted by Tudor Girba at 22 September 2013, 3:50 pm with tags assessment, daily, economics link