Technology selection is at most 20% of architecture in a transformation programme. The remaining 80% is organisational: aligning stakeholders on a shared vision, designing decision-making structures that don't become bottlenecks, managing the politics of legacy system decommissioning, and translating technical constraints into business language that non-technical executives can act on.
Stakeholder Mapping as an Architecture Activity
We treat stakeholder mapping as a first-class architecture activity — as important as technical design. For each significant architectural decision, we map: who has authority to approve, who will be impacted operationally, who has relevant expertise to inform the decision, and who will resist and why. This prevents the common failure mode of technically excellent architectures that never get implemented because the political landscape wasn't understood.
Resistance to architectural change is usually not irrational. A business unit leader resisting a new integration platform often has legitimate concerns about service continuity, resourcing, or loss of control. Architects who treat resistance as ignorance to be overcome fail. Architects who treat it as a signal worth understanding succeed more often.
Architecture Storytelling
The most effective skill a transformation architect can develop is the ability to tell a coherent story about why the architecture matters to the business. Not a technical story — a value story. "By moving to event-driven integration, we will eliminate the 4-hour batch windows that prevent the logistics team from shipping orders before noon" is architecture storytelling. A slide deck of swimlane diagrams is not.
We develop an Architecture Narrative at the start of every engagement: a 1-page document in plain language describing the current state, the target state, and why the gap matters in business terms. This narrative is referenced in every stakeholder communication throughout the programme.
- Stakeholder mapping is architecture work — do it explicitly and early
- Resistance to change is usually a signal worth understanding, not overcoming
- Develop an Architecture Narrative in plain language before any technical design
- Measure architectural success by business outcomes, not technical compliance