Residues: Time, Change, and Uncertainty in Software Architecture

A random simulation of stress is a better way of generating a software architecture than prediction, requirements analysis, reuse of patterns, or reactive change management by coding. Despite the huge number of failing projects in the enterprise software industry, these ideas, with their roots in traditional engineering, are inherited without question by each new generation.

Core thesis challenging traditional architectural methods

Ref. D9AE-A

A hyperliminal system is a system where a complicated, ergodic, ordered system executes inside a complex, non-ergodic, disordered context. In this environment the context will constantly change and warp by definition. There will be constant flux. However, the complicated core will by definition be rigid and slower to respond to changes. With the wrong design, the changes in the context can cause the complicated core to fail.

Definition of hyperliminal systems - key concept explaining unique challenge of software architecture

Ref. FCAF-B

Residuality is the belief that software systems should be thought of as a collection of residues. A residue is what is left over when the software system is stressed. The residue becomes the base unit for describing a software architecture. With this idea, an architecture can be expressed as changing residues over time–capturing time, change and uncertainty.

↩️ Core definition of residuality and its relationship to system stress

Ref. 4A07-C

Software engineers have long been aware of the relationship between N, K and P in their architectures. Most methodologies and ideas–including SOLID, DRY, and most of OOP and pattern approaches are directed toward finding the right balance of N, K, and P. What is difficult is knowing what the right levels of these things are. This becomes a matter of conjecture, opinion and debate. This problem is solved by randomly simulating the environment until the architecture shows signs of criticality.

Key insight about using random simulation to achieve architectural criticality

Ref. 7E11-D

Linear thinkers make excellent programmers. They often come to architecture with a sense of mastery over programming, and often a sense of superiority. It can be quite shocking for many to find themselves outmaneuvered by seemingly lesser programmers who have a knack for lateral thinking and can use their imagination to skip many steps ahead in a single leap. I would venture to say that for the mythical 10X developer, 9X is lateral thinking.

Important distinction between programming and architectural thinking skills

Ref. 0B90-E

The goal of the architect is criticality, not correctness. Correctness is the goal of the programmer and the mathematician. This is one of the first major lessons a becoming architect must learn.

Critical distinction between architectural and programming goals

Ref. A521-F

Residuality is very restrictive in what we can say about the hyperliminal system and helps us to know our own limitations. We cannot successfully describe the entirety of a complex, hyperliminal system. We cannot successfully predict what exactly will happen or when in the hyperliminal system. The only thing we can honestly say to be true is that something will happen, and the hyperliminal system will be slightly different when it does.

Key insight about the limitations of architectural knowledge and prediction

Ref. 6773-G

Software architecture is the practice of being consistently wrong until you reach a point of being a little bit less wrong. Lateral thinking is necessary when we now have to spend more time formulating and understanding the problem and less time jumping straight into solutions.

Important perspective on the iterative nature of architectural understanding

Ref. F8D0-H

The paradigm shift is this: the belief that we could know enough about complex domains to create rigid, lasting structures through the analysis of language or prediction of the future has shown itself to be flawed. Instead, random simulation of the environment generates better architectures.

↩️ Fundamental challenge to traditional architectural methods

Ref. CFA4-I

Despite the fact that these seemingly structured methods are actually unstructured and random, the random simulation that feeds software engineering suffers by default from something called the curse of high dimensionality. This describes how people are generally terrible at randomly simulating a complex environment. They tend to generate patchy samples that they believe to be true. In a group, this behavior becomes worse, and the simulation centers around highly likely scenarios and consensus.

Important insight about the limitations of human-generated random simulations

Ref. 2431-J

Architecture is the structure of a software application that drives the behavior of a software application in its environment. That is, the way the system responds to scale, load, changes, integrations, and things we normally refer to as non-functional concerns.

↩️ Core definition distinguishing architecture from functionality

Ref. 3235-K

Traditional methods of architecture focus on producing static pictures–architectures captured as a set of components and their relations. These traditional approaches suffer from three very serious issues. They have no way of capturing time, uncertainty, or change.

↩️ Fundamental limitations of traditional architectural approaches

Ref. DBD5-L

A hyperliminal system is a system where a complicated, ergodic, ordered system executes inside a complex, non-ergodic, disordered context. In this environment the context will constantly change and warp by definition. There will be constant flux. However, the complicated core will by definition be rigid and slower to respond to changes.

↩️ Key concept defining the unique nature of software systems

Ref. D186-M

Software Engineering is the engineering of hyperliminal systems. There is nothing in the history of engineering that is like this, and no grounds for importing historical concerns. The history of software engineering thus far has been tantamount to nailing horseshoes to car tires.

↩️ Critical perspective on misapplication of traditional engineering approaches

Ref. 417E-N

We cannot successfully describe the entirety of a complex, hyperliminal system. We cannot successfully predict what exactly will happen or when in the hyperliminal system. The only thing we can honestly say to be true is that something will happen, and the hyperliminal system will be slightly different when it does.

↩️ Fundamental limitations in understanding and predicting complex systems

Ref. 7E9E-O

Software requires certainty in order to be written. This conflict lies at the heart of what makes architecture difficult. Most reports on software engineering failures will blame “poor or incomplete requirements”. This is a symptom rather than a cause–business environments are inherently uncertain.

↩️ Core tension between software’s need for certainty and business uncertainty

Ref. 0CF5-P

These business environments are not predictable or mappable, which means that an architecture is subject to change over time which is not knowable to the architect who designs the system. When these changes are significant or numerous enough the software application may not be able to change at the same pace as the business environment.

↩️ Fundamental challenge of designing for unpredictable change

Ref. 3BDA-Q

In the mature sciences have at their root the idea of a fundamental unit. In Physics the atom or the Newtonian particle. In Chemistry the molecule, in Biology the cell. In software this fundamental unit has not yet been arrived at. The machine, the punchcard, the procedure, the module, the object, the service, the microservice, all have been tried at various junctures.

↩️ The search for software architecture’s fundamental unit

Ref. 3FF8-R

It is the job of the architect to design a structure for the complicated system that will allow it to survive as the complex context around it changes and moves. This is incredibly difficult as the nature of the complex context means that we cannot know what is going to change and the number of possibilities is enormous.

↩️ Core challenge and responsibility of the architect

Ref. 8338-S

We cannot successfully describe the entirety of a complex, hyperliminal system. We cannot successfully predict what exactly will happen or when in the hyperliminal system. The only thing we can honestly say to be true is that something will happen, and the hyperliminal system will be slightly different when it does. The residue will contain a software part that is a damaged version of our software architecture. The future of the system will be a function of the residue.

↩️ Key philosophical constraints on architectural knowledge

Ref. 9B48-T

Despite the fact that these seemingly structured methods are actually unstructured and random, the random simulation that feeds software engineering suffers by default from something called the curse of high dimensionality. This describes how people are generally terrible at randomly simulating a complex environment. They tend to generate patchy samples that they believe to be true.

↩️ Critical insight about human limitations in random simulation

Ref. FD95-U

In the complexity sciences the concept of random simulation is commonplace. In environments where there are simply too many elements or properties to measure, or that measurement is extremely difficult, a random sample of these measurements is used as a foundation for making decisions. A well-known example of this is a Monte Carlo simulation.

↩️ Core definition of random simulation’s role in complex networks

Ref. A237-V

Kauffman realized that connecting the nodes in particular ways led to more or less stability and affected the number of possible configurations of their elements, also called phase states, present in each network. He realized that the number of nodes, the number of links between them, and the tendency of the nodes to behave in a somewhat similar fashion, all affected the number of phase states in a system.

↩️ Foundational concept explaining how network connections affect system stability

Ref. 2F02-W

In any complex system you will find evidence of the presence of attractors. Despite countless possibilities of combinations of the possible individual states of events of these systems, order appears, and the systems consistently return to the same relatively small group of attractors as they shift and change over time. This explains the repeating patterns across social systems, workplaces and cities that make it possible for us to move around despite the countless millions of changing variables.

↩️ Key insight about how order emerges from complex systems

Ref. 5635-X

Kauffman identified the property of criticality. This means that at a certain level of N (nodes) and K (links), a system is resilient to unexpected changes and at the same time not so complicated that it collapses under the weight of managing its own resources. A good parallel in the software industry is the comparison of monoliths (Low N and K) and microservices (high N and K). Criticality is finding the balance between these things.

↩️ Essential concept defining optimal system configuration

Ref. EBAB-Y

There is a big difference between criticality and correctness. A system which is critical is necessary in any complex environment–but correctness is not achievable or even desirable. Very often an engineer will interpret criticality as perfection–a system that is unable to be damaged. This is not the case–criticality is simply the right level of N, K and P that allows the system to survive unknown stressors. The goal of the architect is criticality, not correctness.

↩️ Critical distinction between architectural and programming objectives

Ref. 1E72-Z

The straight jacket of structuralism forces architects to work within a very limited scope regarding the business system that they interact with. The belief that the disordered system in which software executes must by necessity have a rigid structure like software and that it can be discovered by analyzing language or assigning probabilities, or that it is recurring and can be solved by simple patterns, is called structuralism.

↩️ Fundamental critique of traditional architectural approaches

Ref. 9D28-A