Why a Target-State Diagram Has Never Modernized Anything

Companion to LinkedIn Post 1 - “Enterprise Architecture Isn’t About Diagrams”

The most expensive shortcut in enterprise IT: a cost curve showing how skipping the transition state looks cheaper early, then overtakes the disciplined path - the trap where the bill comes due

A few years into my career I could draw a flawless target-state architecture. Clean domains. Crisp boundaries. Every integration accounted for. The kind of diagram that makes a steering committee nod.

And I watched plenty of those diagrams change absolutely nothing.

After 25+ years - and somewhere north of 1,200 SQL Server databases and 64 enterprise applications migrated to the cloud - I’ve come to a blunt conclusion: the target state is the easy part. The hard part, the part that actually decides whether a transformation succeeds, is the messy, unglamorous space between where you are and where you’ve drawn.

This is the first in a six-part series on what Enterprise Architecture looks like when you treat it as a delivery discipline rather than a documentation exercise.

The artifact trap

Here’s a pattern I’ve seen at organization after organization.

A transformation program kicks off. The architects go heads-down. Three months later, there’s a gorgeous set of deliverables: a current-state assessment, a target-state reference architecture, a capability map color-coded by maturity, maybe a slide that says “Cloud-Native, AI-Ready, Future-Proof.”

Meanwhile, in the same three months:

Technical debt kept compounding. The legacy monolith didn’t pause for the slideware.
Cloud spend kept climbing, often because teams started building in the cloud without the standards the architecture was supposed to provide.
The application portfolio kept sprawling, because nobody had the authority - or the roadmap - to say “stop building that.”
Delivery teams invented new silos, because the target state described a destination but not a way of working.

The diagram was correct. It was also inert. Correct-but-inert is the most expensive artifact in enterprise IT, because it consumes your most senior people and produces the appearance of progress.

Architecture is a verb

The reframe that changed how I work: architecture only creates value when it changes how systems are built and operated. Not when it’s approved. Not when it’s published to the wiki. When it changes behavior.

That means the deliverable an Enterprise Architect owns is not really the target state. It’s the set of decisions and mechanisms that move an organization toward it without falling over in the process:

Migration sequences - what moves first, what it unblocks, and what you explicitly defer. Order is architecture.
Governance models - the guardrails that let teams move fast without recreating the mess you’re trying to escape. Done well, governance is enabling, not gatekeeping.
Platform standards - the landing zones, the golden paths, the paved roads that make the right thing the easy thing.
Funding strategies - modernization that isn’t funded is a wish. Architects who can’t speak to how the work gets paid for don’t get to set direction.
Organizational change - Conway’s Law is undefeated. If the target state implies new boundaries, the org chart and the operating model have to move too.

None of those fit cleanly in a box-and-line diagram. All of them determine whether the diagram ever becomes real.

What “getting there” actually looks like

A concrete example. Migrating 1,200+ SQL Server databases and 64 applications to Azure was never, fundamentally, a database problem. The target state - “the database estate runs on Azure SQL Managed Instance under a governed landing zone” - fit on one slide. The transition is where the real architecture lived:

Which databases share an application blast radius, and therefore have to move together?
What’s the identity and networking model that lets the half-migrated estate keep talking to itself for the eighteen months it spends in two places at once?
What’s the operating model on day one of the migration - not day one of the end state - when half your DBAs are running on-prem patterns and half are learning cloud ones?
How do you sequence it so each wave funds and de-risks the next, instead of asking for one giant act of faith up front?

Answer those well and the migration can survive imperfect tooling. Answer them poorly and no amount of lift-and-shift automation saves you. The target-state diagram had nothing to say about any of it.

TOGAF is misunderstood, not obsolete

A lot of architects point to TOGAF here as the problem - too heavy, too document-driven, too slow for a cloud-native world. I’d argue the opposite: TOGAF is misunderstood and underappreciated.

In practice, teams often stop after the target architecture work in Phases B through D, as if the hard part ended once the future state was described. But the phases that actually carry the weight are E (Opportunities & Solutions) and F (Migration Planning) - where you define transition architectures: real, intermediate, operable states the enterprise passes through on the way to the target.

That word - operable - is the whole game. A transition architecture isn’t a milestone on a Gantt chart. It’s an architecture you could actually run a business on, even though it’s not the destination. Most transformation pain comes from skipping straight from current state to target state with nothing runnable in between. Read the ADM closely and you’ll see how much of the framework is about the transition - and how reliably that’s the part teams skip.

Two ways to reach a target state: the big-bang leap versus a sequence of operable transition architectures

That’s the subject of the next post in this series: the transition state is the real architecture.

The takeaway

If you’re an Enterprise Architect, your value isn’t measured by the quality of your target-state diagram. It’s measured by whether systems are being built and operated differently because of your work.

So the question I’d leave you with - the same one I now ask at the start of every engagement:

We know where we want to end up. What’s the first transition state we can actually run - and what has to be true to get there?

If your architecture can’t answer that, it isn’t a roadmap yet. It’s a drawing.

Next in the series: The Transition State Is the Real Architecture - a closer look at TOGAF ADM phases E and F, and why incremental, operable transition states beat big-bang target states every time.