Evolutionary architecture: How the last responsible moment is helping project teams to embrace change
The development of software has changed. Static three- or five-year project plans, decided upfront, have gone the same way as those aforementioned turning circles. System architecture needs to change too, because when the only inevitability is change, it’s no longer possible to make the majority of architectural decisions at the start of a transformation. The odds that the world will be the same a month down the line – never mind a year – are remote. This is why evolutionary architecture is so important.
One of the most important principles of evolutionary architecture is a belief in holding decisions until the last responsible moment. This isn’t about leaving anything to chance or making it up as you go along. It’s about not being forced to make decisions before it’s necessary to do so, reducing technical debt and the architectural footprint.
Fundamental to this, in turn, is the idea of iterative learning, or failing fast and failing often.
Moving towards a pattern as extreme as Microservices doesn’t suit every organisation; nor will it be an overnight change. But businesses need to get better at embracing and building for change. Starting to think about architecture as an evolutionary piece, rather than a destination, and embracing the concept of non-breaking incremental change is a good start. It’s only a first step in the journey, but using this principle to guide decisions will smooth the way, protecting against difficult to anticipate changes and expensive retrofits, making change easier and cheaper.
Evolutionary architecture, like agile, continues the theme of acknowledging that human beings, despite the data and technology at our fingertips, are not infallible when it comes to predicting the future. Rather than wasting time trying to prevent the inevitable, architecture needs to be agile to adapt to unforeseen changes; it needs to evolve. There are a number of architectural patterns for doing this. At Answer Digital, one we have used is the ‘Microservices’ pattern. This breaks software down into small, independent, encapsulated contexts.