Reflection on Software Architecture
Software development is (mostly) about taking decisions. Software architecture is a process framework for guiding those decisions toward consistency with a set of prioritised goals across the development of many different systems.
Goals should, always, be driven by strategic business imperatives, even where that’s a bit indirect.
For example, there’s no direct business case for source-code version control; version control is there because it allows us to recover from mistakes, to undo poor decisions, to roll back the state of our world to something previous, known (presumably stable), and to be a time machine that allows us to look back in time at how the world was when a particular decision was made. It’s a tool to help us manage the fact that we’re fallible human beings. We have our off days, we decide things in haste, and we forget stuff — like why a thing should be a certain way and not any other way — why, way back in the past, we decided something one way and not another way. In short, it’s about risk management. Insurance. It doesn’t make money for the business, nor does it save money for the business most of the time. But when things do go pear-shaped you absolutely want it in place. Like any other form of insurance, the value of a Version Control System might range from being a mere cost-saving in the face of accident, all the way to ensuring the very survival of the business.
The next task is to review these goals every once in a while – perhaps once a year or so – but at least at each doubling of the organisation’s software budget.
Using the business’ goals-list in place and prioritised (and it should never be more than a one-pager!) we derive our software architecture: the heuristics that guide and inform our day-to-day decisions over the software production process. Architecture done this way is a vision not an artefact. It is ever evolving, and never complete, always adapting to changes in the business environment.
In this spirit, it is well to remember that any architectural decision is a decision for today. We make choices in the face of the context of how our world is right now – not tomorrow, not next year, and not the way things were when we were very young. We decide how best to proceed – in alignment with our architectural goals – in the face of the facts as we best understand them at present. We acknowledge that today’s facts might become different facts tomorrow. Regulations and laws change. Markets, competitors and suppliers all morph and move and won’t stand still. Our today-decision might turn out to be less than optimal for tomorrow’s world. That hardly means than our architecture is wrong or bad, misconceived or inappropriate. We cannot judge today’s best-effort by tomorrow’s standards.
This may all sound a little trite, a little contrived, but all too often I have seen organisations striving with all their might to define The One True Architecture, a shining (and usually ivory-tower) edifice intended to serve the needs of the organisation For All Time To Come – or at least until the next Architect comes along. It reflects a view of software-architecture-as-artefact, a belief that software architecture is a thing that can be nailed down and perfected, rather than viewing architecture as a dynamic, organic, evolving process. And this seems to go hand-in-hand with a mindset that says, “If we just use the right framework, consistently, across the entire enterprise; if we rigidly enforce the rules of the architecture as laid down in our Architecture Master Plan, then everything will be easy and all will be well with the world.”
When was it ever that way?