Facilitating Software Architecture

Chapter 13. Tackling Architectural Variability

In software, you never build the same system twice. In fact, software engineering could be considered the art of effectively and efficiently making something more or less new every time.

Because of this constant newness, every significant step you take in software development is a step into some unknown. Every significant decision you take is a selection of one hoped-for future at the expense of all other possible futures.¹ And you only find out if that hope is valid when it’s turned into code and tested, ideally by real users in production.

Acknowledging that you’re always making a new system is another way of saying that there are many unknowns in software development that need to be addressed—unknowns that are present throughout a system’s cycle of evolution. Product managers and other planners call this variability, and it encompasses both the fact that no one can ever predict exactly what they’re building and they can never know precisely how long it will take them to build it. In such a world, consistent flow and feedback are the best they can hope for.

Phrased like that, you can see why product managers would care about variability: they want some form of predictability in a world of unknowns—a predictability that can only come from flow. You should care, too, because the practice of software architecture and its results have an arguably greater impact on variability than anything else—both positively (when done well) and ...