Architecture As Journey
What do we talk about when we talk about architecture?
As with any metaphor, describing software through the lens of architecture can hide as much as it can reveal. It can both promise more than it can deliver and deliver more than it promises.
The obvious appeal of architecture is structure, and structure is something that dominates the paradigms and discussions of software development — components, classes, functions, modules, layers, and services, micro or macro. But the gross structure of so many software systems often defies either belief or understanding — Enterprise Soviet schemes destined for legacy, improbable Jenga towers reaching toward the cloud, archaeological layers buried in a big-ball-of-mud slide. It’s not obvious software structure obeys our intuitions the way building structure does.
Buildings are obviously physical, whether rooted in stone or concrete, whether arching high or sprawling wide, whether large or small, whether magnificent or mundane. Their structures have little choice but to respect the physics of gravity and their materials. Software, on the other hand has little time for gravity (except, perhaps, in the sense of seriousness). And what is software made of? Unlike buildings, which may be made of bricks, concrete, wood, steel and glass, software is made of software. Large software constructs are made from smaller software components, which are in turn made of smaller software components still, and so on. It’s coding turtles all the way down.
When we talk about software architecture, software is recursive and fractal in nature, etched and sketched in code. Everything is details. Interlocking levels of detail also contribute to a building’s architecture, but it doesn’t make sense to talk about physical scale in software. Software has structure — many structures and many kinds of structures — but its variety eclipses the range of physical structure found in buildings. You can even argue quite convincingly that there is more design activity and focus in software than in buildings — in this sense, it’s not unreasonable to consider software architecture more architectural than building architecture!
But physical scale is something humans understand and look for in the world. Although appealing and visually obvious, the boxes on a PowerPoint diagram are not a software system’s architecture. There’s no doubt they represent a particular view of an architecture, but to mistake boxes for the big picture — for the architecture — is to miss both the big picture and the architecture: software architecture doesn’t look like anything. A particular visualisation is a choice not a given. It is a choice founded on a further set of choices: what to include; what to exclude; what to emphasise by shape or colour; what to de-emphasise through uniformity or omission. There is nothing natural or intrinsic about one view over another.
Although it might not make sense to talk about physics and physical scale in software architecture, there are physical constraints we do appreciate and care about. Processor speed and network bandwidth can deliver a harsh verdict on a system’s performance. Memory and storage can limit the ambitions of any codebase. Software may be such stuff as dreams are made on, but it runs in the physical world.
This is the monstrosity in love, lady, that the will is infinite, and the execution confined; that the desire is boundless, and the act a slave to limit.
— William Shakespeare
The physical world is where we and our companies and our economies live. This gives us another calibration we can understand software architecture by, other less physical forces and quantities through which we can talk and reason.
Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.
— Grady Booch
Time, money, and effort give us a sense of scale to sort between the large and the small, to distinguish the architectural stuff from the rest. This measure also tells us how we can determine whether an architecture is good or not: not only does a good architecture meet the needs of its users, developers, and owners at a given point in time, but it also meets them over time.
If you think good architecture is expensive, try bad architecture.
— Brian Foote and Joseph Yoder
The kinds of changes a system’s development typically experiences should not be the changes that are costly, that are hard to make, that take managed projects of their own rather than being folded into the daily and weekly flow of work.
Which gives us a not-so-small physics-related problem: time travel. How do we know what those typical changes will be in order to shape those significant decisions around them? How do we reduce future development effort and cost without crystal balls and time machines?
Architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other.
— Ralph Johnson
Understanding the past is hard enough as it is; our grasp of the present is slippery at best; predicting the future is non-trivial.
This is where the road forks many ways.
Down the darkest path comes the idea that strong and stable architecture comes from authority and rigidity. If change is expensive, change is eliminated — its causes subdued or headed off into a bureaucratic ditch. The architect’s mandate is total and totalitarian, the architecture becoming a dystopia for its developers and a constant source of frustration for all.
Down another path comes a strong smell of speculative generality. A route filled with hardcoded guesswork, countless parameters, tombs of dead code, and more accidental complexity than you can shake a maintenance budget at.
The path we are most interested is the cleanest one. It recognises the softness of software and aims to preserve it as a first class property of the system. It recognises that we operate with incomplete knowledge, but it also understands that, as humans, operating with incomplete knowledge is something we do, something we’re good at. It plays more to our strengths than our weaknesses. We create things and we discover things. We ask questions and we run experiments. A good architecture comes from understanding it more as a journey than a destination, more an ongoing process of enquiry than a frozen artefact.
Architecture is a hypothesis, that needs to be proven by implementation and measurement.
— Tom Gilb
To walk this path requires care and attention, thought and observation, practice and principle. This might at first sound slow, but it’s all in the way that you walk.
The only way to go fast, is to go well.
— Robert C Martin
Enjoy the journey.
