Most enterprise architecture programs don't fail because the framework was wrong. They fail because, twelve months in, nobody outside the architecture team can point to a single decision the program actually changed.
The documentation trap
Give a new architecture function a mandate and a modelling tool, and the instinct is to start mapping everything — every application, every integration, every process — before anything gets used. Six months later there's an impressively complete model and zero adoption, because nobody asked what decision this was supposed to inform.
By the time the model is "done," the business has moved on, budgets have already been set without it, and the program looks like overhead rather than infrastructure.
Start with one decision, not the whole landscape
The programs that survive year one pick a real, current decision — a platform choice, a consolidation case, an M&A integration — and build just enough model to support it. The application portfolio doesn't need to be complete; it needs to be complete enough for the question in front of you.
That gives you two things a fully mapped-but-unused model never does: a visible win, and a reason for stakeholders to keep their part of the model current, because they've seen it used for something that mattered to them.
What to measure instead of coverage
- Decisions the model was actually used in, not percentage of the estate documented.
- How often business stakeholders open the model without being asked to.
- Whether the same question gets asked twice — a sign the answer isn't visible enough yet.
Coverage is a means, not a goal. A ruthlessly incomplete model that's trusted and used beats a comprehensive one that sits untouched — every time.