To move from a former waterfall and possibly bottleneck architecture approach to continuous architecture, we do need to adopt new mindset.
Continous architecture believes
1 – Architecture requires holistic approach
Local decisions may impact global system. Customer experience, Data centricity, cloud, interoperability, sustainability, green IT, security,… but also team organisation, ressources management, decision making culture, partnership or/and competitors behaviors, innovation, risk management, roll-out are some of the growing topics to take care. Good architecture job requires more than ever a transversal and holistic view.
We do not architect stand alone system but we are improving a piece of an evolutive XD one system puzzle.
2 – Do architecture for long term products, not just projects solutions
You have to consider architecture activities along product’s life (as it goes through different stages: from craddle to grave). You’ll have to take decisions, design new features, reconsider / rework what you have done given the new period and context you’re in. Design needs to be think in multi-horizon to taking into account future expecting changes. Being focus on building and in a project approach is a much more difficult and unefficient way to do architecture. Not even considering the GO/STOP side effects of switching from one project to the other (each switch resulting in time loss at best case, lapse of memory more certainly), “ones for all” project decision will often not match the coming product ground truth..
3 – Prove (validate) the architecture by implementing it, not by validating document
Powerpoint slides, archimate diagrams … don’t go to production. The code developed by your squad does. And guess what to validate architecture: the sooner, the better 😉
4 – Architects shared the responsibility of the end-product; including its operability
When you’re designing a solution, always keep in mind that the product you’re shaping is likely to be deployed for real and as such it must simply be designed to be operated.
5 – Architecture is a team activity and shared understanding
Architecture is not a document that is passed down from a team to another. An architecture document becomes obsolete as soon as it’s written. Our intention here is not to recommend teams to not write documents. But we think that understanding the architecture, why and how decisions were made, the fullstack nature of your product is way more important than a document. The role of the architect is to transmit this his team … and to write the just enough documents to communicate within and outside the team.
6 – How much architecture work do we still have to do upfront ? just enough.
Why spending a energy to architect a system that may not find its market? Adapt your contribution to the stage on which your product is. Delay decisions until they are absolutely necessary. That’s what we call “the last responsible moment”. The idea is that the more you wait, the more you have feedback and you’ll be in a position to take good decision. The tricky part of the architect job is to know when to make a decision: too early and you’re almost blind; too late and the cost of rework could be high.
7 – Risk-driven prioritization: having impact when architecting to bring the more value possible
Let’s take an example to illustrate this: you want to decompose your monolith and you have the choice between doing it on back office features or user facing ones. We do recommend to start with the user facing features. Why? yes the risk of implementing such changes may look critical for your product but the benefits for your users will be too. In many cases, moving to modern IT, micro services approach will enable the team to deliver more value, to go faster, to reduce the impact of a change, to scale differently the different parts of your product…
8 – Architecture is not a matter of being right but a matter of falling and learning fast
By doing continuous little progress and adopt the architecture’s hypothesys checking method, you will maximize value and accelerate. But more than this finaly classical true agile approach, humility, curiosity, openess, looking for collective excellence will be the boost for advanced architecture’s learning organisation. People are more important than the product itself.
Question your architecture's believes
Contact us to suggest enhancement to Continuous Architecture manifesto