TOGAF® 10 in Practice: Structuring and Rationalizing a Complex IT Landscape

When you step into a large corporation as an enterprise architect, the first thing that hits you is the sheer complexity of the existing information system. Hundreds of applications, cross-subsidiary data flows, heterogeneous technologies accumulated over three decades of mergers and tactical projects. Nobody has the full picture, and every investment decision is made in the fog. This is exactly where TOGAF® 10 proves its worth — not as a theoretical framework to recite, but as a pragmatic toolkit for regaining control.

In fifteen years of engagements, I've watched TOGAF® fail every time it was applied to the letter, and succeed every time it was used as a shared grammar in service of concrete decisions. This article distills how I use it in the field: an ADM adapted to context, an entry point through business architecture and capabilities, and a mapping effort that drives arbitration rather than decorating slides.

The ADM: a cycle to adapt, never to follow religiously

The Architecture Development Method (ADM) is the backbone of every engagement. In practice, I never run the full cycle sequentially, from Vision to Governance. The approach is iterative and opportunistic: start with the Vision phase to align stakeholders on a precise scope and problem, then dive into the business and application layers in parallel, wherever the value is most immediate.

The rule I impose on myself: produce actionable deliverables fast. A capability map on a single A3 page, an impact matrix, a dependency diagram that unblocks a decision. Not a 200-page document nobody reads and that's obsolete before it's approved. The ADM is a means, not an end — success is measured by the trade-offs it enables, not by the number of phases ticked off.

Start with business architecture, not with technology

The most common mistake I see: jumping straight to applications and infrastructure because they feel more tangible. You should do exactly the opposite. Phase B — Business Architecture — lays the foundation for everything else, and its cardinal deliverable is the business capability map: what the organization knows how to do, independent of who does it and with which tools.

Capability is the right anchor because it's stable over time and technology-neutral. 'Execute Payment' remains a capability whether settlement runs through a wire transfer, a card, or a wallet. By anchoring IT to capabilities rather than to projects or a shifting org chart, you build an architecture that survives reorganizations and technology fads.

Concretely, I run short workshops with business directors to stabilize level-1 and level-2 capabilities, then I connect each capability to the value streams it serves. This business backbone becomes the common language between the executive committee, IT, and delivery teams — the only vocabulary a CEO, a CIO, and a developer can share without misunderstanding.

Capitalize with reusable Building Blocks

One of TOGAF®'s most powerful levers is the Building Blocks concept. Throughout my engagements with organizations like AXA and Airbus, I've consistently built reusable architecture patterns: API-first integration patterns, event-driven reference models, application rationalization blueprints, data governance templates.

This capitalization compounds: every engagement feeds a library that drastically cuts design time on the next one. You don't start from a blank page — you instantiate a proven pattern and adapt it to context. It's also what distinguishes an experienced architect from a beginner: not knowledge of the framework, but the depth of their solution library.

The Enterprise Continuum: a taxonomy to avoid reinventing

The Enterprise Continuum is often overlooked, yet it's essential. It establishes a clear taxonomy between generic architecture assets (industry standards, sector patterns) and organization-specific solutions. In the field, I use it to avoid two symmetrical traps: reinventing a pattern that already exists, or force-fitting an inappropriate standard onto a singular context.

Kept well, the Continuum becomes a living repository that answers a simple but structuring question: 'have we already solved this problem somewhere, and is the solution generic or specific to us?' It's a decision accelerator as much as a guardrail against architecture debt.

Map to decide: the capabilities × applications matrix

A mapping effort only has value if it leads to a trade-off. My highest-ROI deliverable is the capabilities × applications matrix: capabilities in rows, the application portfolio in columns. The intersections immediately reveal the real decisions, without political debate.

• Critical capability poorly supported by IT: investment priority.
• Low-strategic capability that's over-tooled (three applications for the same thing): rationalization candidate.
• Strategic capability running on a spreadsheet or a shadow system: urgent risk to address.

I model these views in ArchiMate® and industrialize them in a repository tool (MEGA HOPEX, for example), leveraging the native relationship between Application and Capability. The logic is always the same: describe the current ecosystem, describe the target with the same vocabulary, and make transformation the explicit arbitration between the two.

TOGAF® 10 and agility: governance that accelerates instead of blocking

TOGAF® 10 formalized a major evolution: native agility integration. In my recent engagements, I systematically combine the framework with short delivery cycles. Architecture review boards are no longer blocking gates where teams come to beg for a visa, but lightweight synchronization points that support teams in their technical decisions.

The secret comes down to two principles. First, clear guardrails (architecture principles, sanctioned patterns) that let teams decide on their own in 80% of cases. Second, governance that traces significant decisions rather than controlling everything. An enterprise architecture that slows delivery down has failed, no matter how good its diagrams are.

Architecture principles: the contract that holds over time

Before any diagram, I formalize about ten architecture principles — not fifty. Each follows the TOGAF® structure: statement, rationale, implications. 'Buy before build', 'API-first by default', 'one source of truth per business object', 'data belongs to the business, not to the application'. These principles are the moral contract between IT and the business.

Their value doesn't show on the day you write them, but six months later, when a project wants an exception. The principle turns a clash of opinions into a documented exception discussion: you no longer ask 'who's right?' but 'do we own this deviation, and at what cost?'. That's what makes governance sustainable without the architect who set it up.

Three mistakes that kill a TOGAF® effort

First mistake: confusing exhaustiveness with value. Trying to map everything before producing a single decision exhausts teams and kills the sponsor. Eighty percent of the value lives in twenty percent of the objects — the level 1-2 capability map and the capabilities × applications matrix. The rest is enriched by iteration, on demand.

Second mistake: confusing capability and process. The capability describes the 'what' (Manage Claim), the process describes the 'how' (the handling steps in a given system). Mixing the two ruins traceability and produces unreadable maps that change with every reorganization.

Third mistake: doing architecture without a business owner. Without a sponsor on the executive committee, the repository stays an IT artifact with no strategic reach, abandoned the moment the consultant leaves. On my application rationalization engagements, that sponsorship is the difference between 20-30% maintenance savings actually captured and a nice diagram filed away in a drawer.

What I take from the field

TOGAF® 10 is neither a religion nor administrative red tape. It's a shared language and a discipline that let you structure a complex IT landscape, anchor it on business capabilities, and make investment decisions based on facts. Used with judgment — business-first entry, capitalization on Building Blocks, decision-oriented mapping, agile governance — it turns an application landscape you merely endure into a steered asset.

The real success indicator is never the number of deliverables produced. It's the number of decisions the organization managed to make, faster and with more confidence, because it could finally see clearly.