- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Future-state architectures are often beautifully drawn—and are mostly quietly ignored.
In many programs, the future-state design represents an ideal world where constraints don’t exist: clean data, aligned stakeholders, stable funding, and disciplined teams. Delivery, however, happens in the real world—where priorities shift, timelines compress, and compromises accumulate.
The biggest reason future-state architectures fail is that they’re treated as destinations, not trajectories. There’s no clear path from current to future, only a leap of faith that delivery will somehow get there. When pressure hits, teams optimise for immediate outcomes, and the future-state quietly drifts out of reach.
Another issue is ownership. Once the architecture phase ends, who protects the future-state vision? If no one actively governs alignment, delivery naturally diverges. Community forums are full of stories where “temporary exceptions” became permanent features.
The most effective future-state designs I’ve seen were pragmatic. They acknowledged constraints, defined intermediate states, and explicitly called out what would not be achieved in the current phase. They were living artefacts, revisited and adjusted—not static diagrams.
Architecture doesn’t fail because people ignore it. It fails because it’s disconnected from how delivery actually works. A future-state that can’t survive contact with reality was never a strategy—it was an aspiration.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
