An anonymised account of a real engagement: a large international events, publishing and information-services organisation undertaking a multi-year commerce transformation spanning multiple business units, legal entities and legacy systems. The client and specifics are withheld; the pattern is exactly as it played out.
The real problem
The organisation believed it had a technology-selection problem. In reality it had a decision-ownership problem. Every workshop produced good ideas; every team understood its own domain. Yet the same critical questions kept resurfacing:
- Who owns order status?
- Who owns registration?
- Who owns payment truth?
- Who owns customer truth?
- Who decides when an exception path is acceptable?
The architecture diagrams became increasingly detailed while decision ownership remained ambiguous.
What we did
Instead of starting with system-integration diagrams, we reframed the programme as a Decision Architecture problem. We focused on ownership boundaries, decision rights, escalation paths and lifecycle accountability before technical integration. Architecture reviews became exercises in clarifying decisions rather than debating technology.
The outcome
The programme achieved alignment across multiple delivery streams without requiring every team to agree on implementation details. The most valuable outcome was not a technical artefact — it was a shared understanding of who decides, on what evidence, at which stage, which significantly reduced the recurring debates.
What we’d do differently
We would start the decision mapping much earlier. Several months were spent resolving questions that appeared technical but were fundamentally organisational.
What this proves
Technology architecture often reflects organisational decision architecture. When ownership is unclear, technical complexity expands to compensate.