Why changing the way we architect our solutions?

Since a decade or so, lots of new software engineering practices were introduced mainly to deliver our products faster to our end users. One finds here lean management, agile, devops transformation, Continuous Integration and Continuous Delivery … Why such a trend? because the value is only produced when your product is deployed and used. Everything that is not deployed is just inventory in your souce code base. But one key area was still missing in this massive transformation of our engineering practices and if you end up browsing our Continuous Architecture web site, I guess you already know which area we’re talking about. As the old adage is saying, Rome was not built in a day. We can then perfectly understand that we can not transform all disciplines at the same time. But to complete the journey, we need to finish this off with Architecture. Our creed is “yesterday’s architecture methodologies and processes will not deliver future solutions”. If you take a step back, we can say we build software in a continuous manner today. So let’s adapt our architecture operating model to it !

To make things more interesting, the environment we’re living in is often qualified using the VUCA acronym standing for Volatility, Uncertainty, Complexity & Ambiguity. In such context, the only thing we can do is to build a resilient, flexible, reactive and open information system. We can’t predict what the near future will be so lets design our Information System in a way it can evolve whatever the evolution looks like. So, not only we need to change our operating model to deal with the continuous delivery flow but we also have to maintain our system integrity @scale. Wether we like or not, we’re coming from a world where architecture decisions were taken centrally and quite early in the process. We know it’ll become an unbearable bottleneck something we can not afford in a continuous world. Some decisions still have to be taken centrally of couse (especially the ones that called “strategic”) but we need to empower our teams in this exercise. Not only it will help to increase the delivery flow but we’ll take decision closer to where things happends ie in our product teams. But empowerement is more complex than simply delegating authority. In other words, ALIGNMENT + AUTONOMY > CONTROL.