No big bang: reaching a target architecture one step at a time
Why I prefer to reach a target architecture in phases: the risks of a big bang, how I choose the first capabilities, and what I would tell a CEO who wants it all at once.
As my career moved from programming to designing systems, and then to large transformation projects, I often saw that people prefer big-bang transformations: multi-million-dollar programmes for digital transformation, infrastructure transformation, and so on.
But what I have learned over the last couple of decades is that the better approach is to take one step at a time. Visualise the whole transformation first, then plan it in iterative phases. Assessing the risks and the capabilities is the key.
Why big bang is risky
A big transformation puts huge risk on the whole programme, especially for non-technology companies. They often rely heavily on consultants and partner vendors.
The key risks fall into three pillars:
- Business outcomes change very often. What the business wants in year three is rarely what it wanted in year one.
- Technology changes fast. A big transformation programme runs for years, and the technology moves on while it runs.
- Adoption. People have to adopt the new technology and systems. Every transformation depends on this.
Then there is the cost. I often feel that a company is ready for a big bang from one perspective, but not from the others. A company has to think about systems, processes, people and data, in every area.
Map the capabilities first
In the target architecture, the full capabilities map has to be evaluated first. Then plan iterative phases to fill those capabilities, making sure the scope of a capability is not duplicated across phases.
For example, suppose you are modernising an e-commerce platform, and you have five capabilities to choose from:
| Capability | Business impact | Complexity | Priority |
|---|---|---|---|
| Checkout optimisation | High revenue impact | Medium | High |
| Product discovery | High conversion potential | Medium | High |
| Inventory accuracy | High customer and operational impact | High | High |
| New CMS | Medium | Medium | Depends on dependencies |
| Complete backend replacement | Possibly high, long term | Very high | Later, unless it blocks other priorities |
I would start with the first three, if the existing architecture can support them. Why? Because they can show measurable improvement in revenue, customer experience and operational efficiency, without replacing the whole platform.
But imagine checkout optimisation depends on a payment service that cannot support the planned changes. Then fixing that dependency becomes part of the first phase, even if on its own it gives customers very little they can see.
I have done this kind of work myself. I got the opportunity to work on a few systems that were tightly coupled and kept the same copy of data. I helped design and modernise the solution so that they could be decoupled easily.
In a multi-year programme
If I were part of a multi-year transformation programme, I would first focus on the capability map and the target architecture. The key points:
- Reuse. Reuse the existing capabilities, and map them to the new ones.
- Principles. Define the overall architecture principles from every perspective: people, process, technology and data.
- Adoption. Check how quickly customers and processes can adopt the change, and roll out capabilities to customers and people in iterations.
Keep ownership
External partners and consultants can bring valuable experience, especially when introducing new technologies. But I believe organisations should keep ownership of the transformation, and of the key architecture decisions.
If the CEO wants the big bang
Even if the CEO wants the big bang, I recommend prioritising the key capabilities that give measurable business benefit within 90 days. Assess each one against customer impact, implementation feasibility and architectural dependencies. This shows early results, and builds the foundation for the rest of the transformation.
I don’t believe every big-bang transformation is wrong. Sometimes a large, coordinated change is necessary. But wherever possible, I prefer to design the complete transformation upfront and deliver it in measurable phases. This gives the business the chance to learn, adapt and validate its investment.