Perspectives
Complexity Through a Systems Architect's Eyes
Software teams learn that ten tightly coupled services can be harder to reason about than a hundred isolated components. Dependency structure matters more than raw…
I approach complexity with an occupational habit: I want to draw boxes and arrows. That habit is useful because architecture forces questions about state, boundaries, interfaces, resources and failure. It is dangerous because natural systems were not designed to respect our diagrams.
Complexity often comes from interaction, feedback, adaptation, heterogeneity and multiple timescales rather than merely from having many components. Simple parts can create behavior that is difficult to predict once strongly coupled.
Where does state live?
Complexity often comes from interaction, feedback, adaptation, heterogeneity and multiple timescales rather than merely from having many components. Simple parts can create behavior that is difficult to predict once strongly coupled.
Software gives us the expectation that important state should have an owner. Natural systems often distribute state across structure, concentrations, relationships and history. A snapshot can therefore tell us less than the process that produced it.
Where are the interfaces?
Software teams learn that ten tightly coupled services can be harder to reason about than a hundred isolated components. Dependency structure matters more than raw count.
Engineered interfaces are declarations. Natural boundaries are often material: membranes, tissues, ecological borders, channels, gradients or social conventions. They can leak, adapt and participate in the behavior they constrain.
What is the failure model?
Natural complexity is not completely under design control. Evolved systems have open boundaries, path dependence and adaptive agents, so modularity is often partial.
Failure analysis is useful because normal operation hides assumptions. A healthy component can coexist with an unhealthy whole. A local optimization can damage the larger system. Robustness at one level can create fragility at another.
History is part of the architecture
Twentieth-century systems thinking increasingly focused on organized complexity: problems too structured for pure statistics and too interconnected for simple mechanism diagrams.
In a designed system, legacy structure may be accidental baggage. In an evolved or historically accumulated system, legacy structure can be the reason the current architecture exists at all. The path is not documentation around the system; sometimes it is part of the system.
The zoom test
A good architectural description should survive zooming. Going down a level should reveal mechanisms capable of implementing the higher-level pattern. Going up should reveal regularities that justify discussing the larger entity in its own vocabulary.
Complexity reveals a limit of intuition: understanding every component individually does not guarantee understanding the system created by their interactions.
What is the smallest description that still preserves the behavior we care about?
Reading trail
These links are starting points for the scientific and historical ideas. The systems interpretation, analogies and conclusions here are my own.