Aldermont's board has finally signed off on the thing every engineer at the bank has wanted for years: consolidate the three core banking systems into one. The Calford mainframe, the Piedmont commercial platform, and the Northline cloud core will become a single core with a single definition of a customer. It is a multi-year, multi-hundred-million-dollar program that touches every part of the bank.
The chief enterprise architect is handed the program and immediately faces a question that has nothing to do with technology. Where do you even start? Not "which core do we keep," but the prior question: what is the actual sequence of work that takes a bank from "we have a vision" to "the new core is live and the old ones are retired," without the program collapsing into chaos halfway through?
That question, repeated across thousands of organizations over thirty years, is what TOGAF exists to answer. It is the most widely adopted enterprise architecture framework in the world, and at its heart is a step-by-step method for doing exactly this kind of program. This post takes that method apart.
What TOGAF actually is
TOGAF stands for The Open Group Architecture Framework. It is maintained by The Open Group, a vendor-neutral industry consortium, and it has been through several major revisions since the 1990s. When people say their organization "uses TOGAF," they almost always mean one specific part of it, so it helps to be precise about what the framework contains.
TOGAF is not a piece of software, a reference architecture, or a prescriptive design for any particular system. It is a method and a set of supporting tools for developing and governing enterprise architectures. Think of it as a process framework: it tells you how to run the work of architecting an organization, not what the answer should be. Two banks both using TOGAF could arrive at completely different target architectures, because TOGAF governs the how, not the what.
The core idea: TOGAF's center of gravity is the Architecture Development Method, or ADM: a cyclic, phased process for taking an organization from a current-state architecture to a target-state architecture. Almost everything else in TOGAF exists to support the ADM. Learn the ADM and you have learned the working core of the framework.
The framework as a whole has several parts, but three matter for understanding it at this level. The ADM is the method, the engine that drives everything. The Architecture Content Framework defines the artifacts and deliverables the method produces, so that a "target architecture" is a concrete set of documents rather than a vague intention. The Enterprise Continuum and repository are where architectural assets are stored and reused, so each program does not start from a blank page. The rest of this post focuses on the ADM, because that is where the real work happens.
The ADM at a glance
The ADM is a cycle. It has a set of phases arranged in a loop, plus a central activity that touches all of them. You move through the phases roughly in order, but the loop is deliberate: enterprise architecture is never "done," and finishing one cycle feeds the next. For Aldermont's core consolidation, one full pass through the ADM takes the program from vision to implementation governance, and the next pass handles whatever comes after the cores are merged.
Before walking each phase individually, it helps to see the whole shape.
Two features of this shape are worth noticing before we walk the phases. First, it is a loop, not a line: phase H hands back to phase A, because the architecture is a living thing that keeps evolving. Second, Requirements Management sits in the middle rather than in the sequence, because requirements change constantly and every phase must be able to feed changes in and pull updates out. It is the one activity that never stops.
The Preliminary phase — getting ready to architect
Before the cycle proper begins, there is setup work. The Preliminary phase establishes the architecture capability itself: who the architects are, what governance they operate under, which principles will guide decisions, and how tailored the framework will be for this organization. It answers "are we ready to do architecture at all?" rather than "what should the architecture be?"
For Aldermont, this is where the bank decides that core consolidation will be governed by an architecture review board, adopts a set of architecture principles (for example, "one system of record per data entity"), and agrees how heavily it will tailor TOGAF. This phase is easy to skip and expensive to have skipped. A program that reaches the hard decisions without agreed principles has no basis for making them except politics.
Phase A — Architecture Vision
Phase A opens every cycle. Its job is to define the scope of this particular architecture effort, identify the stakeholders, articulate the vision, and secure formal approval to proceed. The signature deliverable is the Statement of Architecture Work, the document that authorizes the effort and pins down what is in and out of scope.
This phase is deliberately kept separate from the detailed business architecture that follows, and the separation is the interesting design decision. Phase A is where you get sponsorship and agreement on direction before anyone sinks months into detailed modeling. For Aldermont, phase A is where the vision "one core, one customer definition, three systems retired within four years" is written down, sized at a high level, and signed by the CIO and the board. Only once that is approved does the detailed work begin. Doing it the other way around, modeling first and seeking approval later, is how programs burn a year of effort before discovering the sponsor wanted something different.
Phases B, C, and D — the domain architectures
The middle of the cycle is where the four architecture domains from the previous post in this series reappear, each getting its own phase of detailed work. This is the heart of the method: for each domain, you describe the baseline (what exists today), describe the target (what you want), and perform a gap analysis to identify what must change to get from one to the other.
That baseline-target-gap pattern is the single most repeated idea in the ADM, so it is worth stating plainly: every domain phase produces an honest map of today, a considered map of the future, and an explicit list of the differences. The gaps are the work.
Phase B — Business Architecture
Phase B develops the target business architecture: the capabilities, value streams, processes, and organizational structure needed to support the vision. For Aldermont's consolidation, this is where the bank confirms that "originate a mortgage" and "maintain a customer relationship" are single capabilities that should be supported once, not three times. The gap is glaring: today the customer-relationship capability is implemented in three CRMs, and the target has it implemented once.
Phase C — Information Systems Architecture
Phase C covers two of the four domains together: data and application. The data architecture work here defines the target canonical customer model and names the single system of record that will own it, resolving the three-definitions problem at the level of design. The application architecture work defines which applications survive, which are retired, and how they integrate. For Aldermont, phase C is where the decision "the Northline core becomes the single core; Calford and Piedmont are retired" is made concrete, along with the target integration approach that replaces the point-to-point tangle.
Phase D — Technology Architecture
Phase D develops the target technology architecture: the infrastructure, platforms, and standards the applications will run on. For Aldermont, this is where the batch-versus-real-time mismatch is confronted directly. The target technology architecture commits the consolidated core to a real-time platform and specifies what must be true of the infrastructure for the mortgage decision to stop waiting on an overnight batch window.
Across all three domain phases, the diagram below shows the pattern that repeats.
Phase E — Opportunities and Solutions
By the end of phase D, Aldermont has a full target architecture and a long list of gaps across all four domains. What it does not yet have is a plan. Phase E is the pivot from architecture to delivery. It groups the gaps into work packages, identifies candidate projects, and makes the big delivery-strategy decisions: what gets built or bought, and in what broad increments.
The central decision in phase E is usually how to stage the transition. A bank does not switch three cores off on a Friday and turn one on over the weekend. Phase E is where Aldermont decides on a phased migration: perhaps move retail deposits first, run old and new cores in parallel behind a facade, then migrate commercial, then wealth. These intermediate states have a name in TOGAF, Transition Architectures, and they are the difference between a survivable migration and a catastrophic big-bang cutover.
Phase F — Migration Planning
Where phase E decides the broad strategy, Phase F produces the detailed, sequenced, resourced plan. It prioritizes the projects, assigns them to a timeline, works out dependencies, and delivers the Implementation and Migration Plan that the organization will actually execute against.
The separation between E and F mirrors the separation between A and B earlier in the cycle: decide the strategy and secure agreement before you sink effort into detailed sequencing. For Aldermont, phase F is where "retail first, then commercial, then wealth" becomes a dated plan with named dependencies, cost estimates in the hundreds of millions of dollars, and a clear view of which project cannot start until another finishes.
Phase G — Implementation Governance
Now the building starts, and Phase G is where the architecture function stays involved during delivery. It provides architectural oversight of the implementation projects, ensuring what actually gets built conforms to the target architecture rather than quietly drifting from it under delivery pressure.
This phase exists because of a specific, predictable failure. Under deadline pressure, a delivery team facing a hard integration will reach for the expedient shortcut, the direct point-to-point call, the quick copy of the data, the temporary second definition of a customer. Each shortcut is reasonable in isolation and collectively they rebuild the exact mess the program was meant to eliminate. Phase G is the architecture review board saying "no, route it through the agreed integration layer," at the moment the shortcut is proposed. It is where governance stops being a document and becomes a decision. This is important enough that governance gets its own post later in the series.
Phase H — Architecture Change Management
The final phase, Phase H, handles change to the architecture after it is in place. The world does not hold still while a multi-year program runs. New regulations arrive, technologies shift, the business changes direction. Phase H establishes the process for assessing those changes and deciding whether each is a minor adjustment the current architecture absorbs, or a trigger significant enough to start a new turn of the whole ADM cycle.
This is what makes the ADM a loop rather than a line. For Aldermont, once the consolidated core is live, phase H is the ongoing process that catches the next major shift, say a decision to expand into a new market or adopt a new payments rail, and feeds it back into a fresh phase A. The architecture is never finished; it is continuously governed.
Requirements Management — the center that never stops
At the center of the cycle sits Requirements Management, and its placement is the most quietly important design choice in the whole method. It is not a phase you pass through once. It is a continuous activity that every phase reads from and writes to.
The reason is simple and hard-won. Requirements are discovered and changed throughout a program, not gathered once at the start. Aldermont will uncover a regulatory constraint during phase D that changes a decision made back in phase B. Rather than pretend requirements are frozen after some early sign-off, the ADM makes their management a permanent, central activity. Any phase can raise a new requirement; the change is recorded centrally and pushed to whichever phases it affects. It is the mechanism that lets a rigid-looking phased method cope with a world that refuses to stay still.
A full pass through the ADM, end to end
Put the phases together and Aldermont's core consolidation has a complete spine, from a board-approved vision to a governed, living implementation. The diagram below traces the whole program through the method in one view.
Where TOGAF gets criticized, honestly
A framework this dominant attracts real criticism, and an authoritative treatment has to include it rather than pretend TOGAF is beyond reproach.
The most common charge is heavyweight process. The full ADM, taken literally, can generate mountains of documentation and move at a pace that suits a five-year bank program but actively harms a fast-moving product organization. Applied without judgment, it becomes exactly the ivory-tower bureaucracy that gives enterprise architecture its bad name.
The framework's own answer is tailoring: TOGAF explicitly expects you to adapt it, dropping phases, lightening deliverables, and running the ADM at whatever weight fits the effort. The catch is that tailoring well requires the judgment the framework cannot supply. A less common but sharper criticism is that TOGAF is strong on process and weak on content: it tells you how to run the method thoroughly but says comparatively little about what a good target architecture actually looks like. That is why organizations pair it with reference architectures and pattern catalogs that supply the substance the ADM organizes. It is also why the next posts in this series turn to the artifacts, capability maps, portfolios, governance, that give the method something concrete to work on.
Summary
TOGAF is best understood not as a giant body of knowledge to memorize, but as one working engine surrounded by supporting parts. The engine is the ADM: a cyclic method that takes an organization from an approved vision, through detailed target architectures for each of the four domains, into a staged and governed implementation, and then keeps the whole thing alive through change management. Every phase runs the same underlying move, describe the baseline, describe the target, close the gap, and requirements management sits at the center because the targets never stop shifting.
For a program like Aldermont's core consolidation, the value of the method is not that it makes the hard decisions for you. It does not. It will not tell the bank whether to keep the Northline core or which customer definition to canonicalize. What it does is guarantee those decisions get made in the right order, by the right people, with sponsorship secured before effort is spent and governance in place before shortcuts accumulate. TOGAF governs the how so the organization can concentrate on the what. Understanding the ADM is what turns "we should really consolidate those cores someday" into a program that can actually be run.
Part of the Enterprise Architecture series on this blog.
Related on this blog: Architecture series