The Future Has No Target State

TOGAF is dying. Not because it failed — because the world changed.

Before we bury TOGAF, it is worth acknowledging what it is. The Open Group Architecture Framework has been the dominant language of enterprise architecture for much of the past quarter-century. Entire careers have been built upon it. Entire transformation programmes have been justified through it. It offered a structured way to connect business ambition with technological execution at a scale few other frameworks attempted. The certification itself is no trivial undertaking, exposing practitioners to a substantial body of knowledge spanning strategy, governance, business architecture, data, applications and technology.

Yet every framework is a product of its time. And the question facing architects today is not whether TOGAF was useful, but whether the assumptions that made it useful still hold true.

There was a time when TOGAF made perfect sense.

A world of annual planning cycles. Monolithic applications. Data centres that took months to provision. Multi-year transformation programmes. Thick architecture documents printed, reviewed, signed and filed.

In that world, the central question of architecture was simple:

“What should the future look like, and how do we govern our way towards it?”

TOGAF answered that question brilliantly.

The problem is that the world TOGAF was designed for no longer exists. There was always a future to be designed, a target state to be reached. The deeper shift — the one this piece is really about — is that the target state itself has quietly disappeared.

The Ghost of a Different Age

Every framework carries the assumptions of the era that created it.

TOGAF’s intellectual DNA stretches back through TAFIM to the United States Department of Defense in the early 1990s. It emerged from a world where systems were expensive, change was slow, and certainty was prized above adaptability.

At its heart sits the Architecture Development Method (ADM):

Vision → Business Architecture → Information Systems → Technology Architecture → Opportunities & Solutions → Migration Planning → Governance.

The sequence feels logical because it mirrors how engineers once built physical systems.

First design. Then approve. Then build. Then govern.

The assumption is subtle but profound:

The future can be sufficiently understood to define a target state before the journey begins.

That assumption is increasingly difficult to defend.

Modern organisations do not travel through predictable terrain. They navigate moving landscapes. Markets shift. Customer expectations evolve. AI changes capabilities overnight. New competitors emerge from unexpected directions.

In such an environment, the notion of a fixed target architecture begins to resemble navigating a storm by drawing a perfect map before leaving harbour.

The Architecture That Nobody Reads

Most architects who have lived through large TOGAF implementations recognise a familiar pattern.

Months are spent creating capability maps. Reference architectures. Technology standards. Governance models. Architecture principles. Current-state assessments. Target-state visions.

The artefacts are beautiful. The diagrams are immaculate. The PowerPoint decks are enormous.

And then reality happens.

Development teams continue shipping. Business priorities change. Leadership rotates. Budgets move.

The architecture repository slowly becomes a museum of good intentions.

The challenge is not that TOGAF lacks intelligence. The challenge is that architecture documentation ages faster than organisations can maintain it. The moment a target-state diagram is published, reality has already diverged from it. The faster the organisation moves, the faster the divergence occurs.

In many companies, architecture governance became an exercise in documenting decisions after they had already been made.

A cartographer chasing an army that never stops moving.

The Cloud Broke More Than Infrastructure

The arrival of cloud computing exposed another weakness.

TOGAF devoted significant effort to Technology Architecture. This made perfect sense when organisations owned physical infrastructure. Servers had lifecycles. Networks required planning. Capacity forecasting mattered. Procurement timelines measured in months.

Today infrastructure is often provisioned through APIs in minutes. A modern engineering team can deploy global infrastructure before a traditional architecture review board schedules its next meeting.

When AWS, Azure and Google Cloud began publishing concrete, actionable frameworks such as their Well-Architected Frameworks, many architects discovered something uncomfortable: the cloud providers offered more practical guidance than many internal architecture standards.

The centre of gravity shifted. Architecture moved closer to the teams building systems — away from committees, away from documentation, away from central planning.

The Rise of Conway’s Law

The deeper issue is organisational.

TOGAF assumes architecture can be designed centrally. Modern software teaches the opposite lesson.

Conway’s Law tells us:

Organisations design systems that mirror their communication structures.

Architecture is not merely a technical problem. It is an organisational one.

The most influential architecture decision is often not technology selection. It is team design. Who talks to whom. Who owns what. Where decisions are made. Where knowledge resides.

This realisation changed everything. Because once you accept Conway’s Law, architecture stops being a blueprint. It becomes an emergent property of the organisation itself.

What Replaced TOGAF?

Nothing.

And that is precisely the point.

The successor to TOGAF is not another framework. It is an ecosystem — a collection of lighter practices that together perform the same functions without requiring a central planning authority.

Rather than asking:

“How do we govern towards a target state?”

Modern architecture asks:

“How do we create conditions for good architecture to emerge?”

The difference is subtle. The implications are enormous.

Domain-Driven Design: Finding the Natural Boundaries

If one part of enterprise architecture survived and flourished, it was Domain-Driven Design.

Strategic DDD provides something TOGAF often struggled to define clearly: natural organisational boundaries. Bounded contexts. Ubiquitous language. Context maps. EventStorming workshops.

These tools help organisations discover where complexity naturally separates. Not according to organisational charts. Not according to technology stacks. But according to the business itself.

Instead of forcing the enterprise into a predetermined model, DDD allows the model to emerge from the domain.

It answers the question: Where are the seams?

And in complex systems, finding the seams is often the most important architectural decision of all.

Team Topologies: Architecture Through Organisation

Once boundaries are identified, the next question emerges: Who owns them?

This is where Team Topologies enters.

Perhaps the most important architecture book written in the last decade, it reframed architecture around cognitive load. Not technical complexity. Human complexity.

Stream-aligned teams. Platform teams. Enabling teams. Complicated-subsystem teams.

These concepts transformed organisational design into an architectural discipline. Architecture became less about drawing boxes and more about shaping interactions.

The architect’s role shifted from blueprint creator to organisational gardener — creating conditions, removing friction, cultivating healthy structures, allowing systems to evolve.

Platform Engineering: Governance as Product

Traditional governance relied on reviews. Modern governance relies on defaults.

This may be the most significant shift of all.

Under TOGAF, governance happened through documents. Under platform engineering, governance happens through products. Golden paths. Paved roads. Internal developer platforms. Reusable templates. Automated controls.

Instead of telling teams how to behave, platforms make desirable behaviour effortless.

The compliant path becomes the easiest path. The secure path becomes the default path. The governed path becomes the natural path.

This is governance transformed from bureaucracy into usability.

Evolutionary Architecture: The End of the Fixed Target State

Perhaps the most profound shift is philosophical.

TOGAF assumed architecture was a destination. Evolutionary architecture treats architecture as a continuously negotiated set of characteristics: security, resilience, scalability, performance, observability.

Rather than documenting these qualities and reviewing them periodically, modern systems test them continuously. Fitness functions run inside CI/CD pipelines.

Architecture becomes executable. Governance becomes measurable. Conformance becomes automatic.

Instead of asking:

“Does this solution comply?”

The system asks:

“Can it pass?”

And the answer arrives in seconds.

Architecture Decisions Belong With the Code

The same philosophy explains the rise of Architecture Decision Records.

The old world stored decisions in repositories. The new world stores them beside the software — near the place where change occurs, near the people who must understand the consequences.

Architecture becomes less like legislation and more like a living conversation. Recorded. Versioned. Traceable. But never detached from reality.

Wardley Mapping: Strategy in Motion

One area where enterprise architecture still matters enormously is strategy.

Understanding what should be built. What should be bought. What should be commoditised. What creates differentiation, and what does not.

This is where Wardley Mapping has become increasingly influential.

Unlike capability maps, Wardley Maps recognise that every component evolves. Novel ideas become products. Products become utilities. Utilities become commodities.

The map is not static. It captures movement.

And in a world defined by constant technological evolution, movement matters more than structure.

The New Architect

The architect is not disappearing. The role is evolving.

The enterprise architect of yesterday often acted as a planner. A reviewer. A governor. A custodian of standards.

The architect of tomorrow looks different. Part strategist. Part systems thinker. Part platform steward. Part organisational designer.

Their responsibility is no longer to draw the future. It is to create the conditions in which the future can emerge safely.

To understand domains. Shape team boundaries. Cultivate platforms. Define fitness functions. Steward decision-making. Guide evolution — not command it.

The shift is from control to enablement. From blueprint to ecosystem. From governance to guidance.

Technology Scales Capability. People Scale Possibility.

TOGAF is not dead.

Banks will continue to use it. Governments will continue to certify it. Defence organisations will continue to rely upon it. And in highly regulated environments, some of its disciplines remain valuable.

But it is no longer the centre of gravity.

The industry has moved. The frontier has moved. Architecture has moved.

The future belongs less to those who can describe a perfect target state and more to those who can create adaptive systems capable of discovering one.

Because the most important lesson of the modern technology era is this:

The future is no longer something we design in detail. It is something we continuously uncover.

And the organisations that thrive will not be those with the most comprehensive architecture documents. They will be those that learn, adapt and evolve faster than the world changes around them.

Technology scales capability. People scale possibility.

And architecture’s next chapter is about enabling both.