The TOGAF Standard in Practice: Make the Architecture Change What Happens Next

Everyone agrees with the target architecture. The diagrams describe a better future, the systems fit together, and the direction is approved. Six months later, the initiative is still struggling to move.

Consider a hypothetical consolidation across two business units. Both want a shared customer-registration capability: a way to create and maintain the customer records their services use. They have not agreed who will operate it. A legacy contract constrains the timing, and funding is not connected to a feasible transition.

The destination is understandable. The next investment decision is not.

That is the question I would bring to architecture work: what becomes possible because this model or analysis exists? The TOGAF Standard can support that work, but filling its vocabulary with diagrams is not the same as giving the organization a route into change. [1][2]

Ownership changes the design, not just the name in a box

In our customer-registration example, one business unit might operate the shared service for both. An enterprise platform team might take responsibility instead. Or the units might keep separate operations temporarily while standardizing the information they exchange.

These are hypothetical alternatives, not interchangeable names for the same architecture. They change who funds support, which team handles incidents, how access is managed, and what skills must be available. If nobody can accept those duties, the technically attractive shared service has no workable operating arrangement.

That is why enterprise architecture includes the business, data, application, and technology relationships. A contract renewal or an unavailable operating team isn't necessarily a detail outside the architecture. It can determine which transition is possible.

An additional diagram is useful when it helps expose that choice. A model of current registrations, dependencies, and data responsibilities could show what each prospective operator would inherit. Detailing an unrelated part of the technology estate would add precision without helping the decision at hand.

The target needs a journey the business can afford

The legacy contract creates a real constraint. A rapid replacement might avoid renewal while concentrating migration risk. A phased transition might preserve continuity while the shared operation is established, but require a period of duplicate cost. A temporary continuation might buy time while accepting the price of delay.

Calling one option modern and another cautious doesn't compare those consequences. The question is what the business can actually operate during the transition, with the funding, people, and dependencies available.

For this case, I would first make the operating choice and transition alternatives explicit enough to decide together. Selecting an owner after committing to the migration sequence could reveal that the chosen team cannot support the schedule. Selecting a sequence without discussing renewal could conceal a cost the sponsor believed was being avoided.

A compact comparison might look like this:

The case doesn't supply enough evidence to declare a winner. It does tell us what the next architecture work should clarify. A broad request to approve the destination would leave those choices hidden again.

Use the method to carry learning, not to freeze the first answer

TOGAF's Architecture Development Method connects the purpose of change, the architecture, transition planning, implementation governance, and continued reconsideration. Its value here is the relationship between those activities, not the production of an identical document set for every initiative. The 10th Edition's fundamental content and supporting guides allow the work to be tailored. [1][2]

Suppose a supplier review reveals that the planned registration interface cannot support a required use. That finding should reopen the affected option or transition assumption. It needn't erase unrelated conclusions whose evidence still holds, and it shouldn't be ignored because a phase was already marked complete.

I would keep a compact record of the choice and why it was made: the alternative selected, the closest credible alternative rejected, and the condition that could change the comparison. This is a suggested working format, not a prescribed TOGAF template.

Keeping the rejected alternative visible matters because a later team may face different funding or capacity. It should be able to reconsider the choice without treating yesterday's architecture as permanent policy or starting from nothing.

An approved architecture should change the work that follows

Once ownership and transition are accepted, the consequences must reach the budget, delivery sequence, service preparation, and teams relying on the plan. Otherwise the organization has recorded agreement without enabling implementation.

Governance then has a concrete job: distinguish local choices within the accepted design from changes to risk, responsibility, or business promises that require a wider decision. It should help the team resolve those choices, not repeatedly discuss an issue nobody present can settle.

For the two business units, the next useful output may be smaller than another complete architecture package. It may be a clear comparison of who can run customer registration and which transition they can support before the contract decision. That is enough to focus the work.

Architecture becomes valuable when the organization can make a better consequential choice and carry it into delivery. The diagram remains part of the evidence. The movement it enables is the result worth looking for.