The TOGAF® ADM (Architecture Development Method) is a well-known and well-defined framework for structuring architecture work. However, in many organizations it’s perceived as abstract or overly theoretical.
In this post, I show a simplified, concrete version of how I’ve applied ADM in practice, tailored to a transformation context — and enriched with the EDGY™ enterprise design language.
Why TOGAF ADM?
The official ADM defines nine phases: Preliminary, Architecture Vision, Business Architecture, Information Systems Architecture (Data and Application), Technology Architecture, Opportunities and Solutions, Migration Planning, Implementation Governance, and Architecture Change Management. Requirements Management is a continuous process across all phases.
This provides structure and traceability, but in practice ADM is often seen as too abstract or “owned by IT.” That’s why I bring in the EDGY™ enterprise design language as a complement.
EDGY defines three core facets: Identity, Experience, and Architecture.
- Identity expresses why the enterprise exists — its values, purpose, and promise.
- Experience shows how the enterprise is perceived and interacted with — by customers, employees, and partners.
- Architecture describes how the enterprise is structured and operates — through Capabilities, Assets, and Processes.
At the intersections of these facets, EDGY highlights outcomes that make design tangible:
- Brand (Identity ∩ Experience)
- Products (Experience ∩ Architecture)
- Organization (Architecture ∩ Identity)
By combining ADM with EDGY, architecture steps become easier to communicate, more business-driven, and actionable in transformation contexts.
My Adapted ADM Process
Below is a customized interpretation of the ADM cycle, where each step is linked to capabilities, assets, processes, domains, technology choices, and integration strategy:
EDGY Architecture facet (Capabilities, Assets, Processes):
Capabilities describe what the enterprise can do as enduring abilities.
Assets include platforms, data, APIs, infrastructure, and relationships.
Processes cover value streams, governance routines, and delivery practices.
Step 1: Situation Assessment
Start with a clear understanding of the current state: existing systems, integration patterns, business processes, and organizational setup. In EDGY terms, capture Capabilities, Assets, and Processes as they exist today.
Step 2: Objectives and Driving Forces
Anchor the transformation in why change is needed: efficiency, improved customer experience, regulatory compliance, or scalability. In EDGY terms, link to Identity and Experience — brand promise, values, and desired interactions.
Step 3: Capability–Asset–Process Planning (EDGY Architecture)
Instead of working through TOGAF’s traditional layers (Business, Data, Application, Technology), I use EDGY’s Architecture facet (Capabilities, Assets, Processes). Capabilities are enduring abilities of the enterprise. Assets are what the enterprise has and can leverage, such as platforms, data, APIs, or infrastructure. Processes define how the enterprise works and changes through value streams, governance, and delivery. Mapping CAP gives a business-accessible way to link strategy to execution and helps prioritize which abilities, enablers, and flows need to be strengthened.
Step 4: Define Domains and Subdomains
From CAP, define modular digital building blocks. Example domains are customer management, payments and billing, order and warehouse, analytics and insights, and business administration. Each domain groups systems such as CRM, CDP, ERP, BI, or HR, and ties them back to capabilities and processes.
Step 5: Integration Strategy
A robust integration architecture is critical. The approach emphasizes API First, Event-Driven Architecture, API Gateway, and Master Data Flows. Integration ensures that Assets and Processes work together across domains, enabling seamless capability execution.
Step 6: Roadmap
Translate the target state and CAP priorities into a sequenced roadmap. This shows how initiatives align over time and deliver value step by step. In EDGY terms, ensure the roadmap is tied back to Organization (Architecture ∩ Identity), supported by governance, and continuously adapted.
Key Learnings
ADM provides discipline, but it must be translated into the organization’s own language. EDGY complements ADM with facets that make architecture tangible to business leaders. The Architecture facet reframes traditional TOGAF layers into capabilities, assets, and processes. Integration is the glue that ties domains and assets into working capabilities. Roadmaps must balance ambition with iteration and deliver visible value.
Closing Thoughts
TOGAF ADM is more than a method – it’s a structure for clarity, trust, and transformation. By combining ADM with the enterprise design lens of EDGY™ — Identity, Experience, and Architecture — and especially its Architecture facet (Capabilities, Assets, Processes), the method becomes a shared language across business and IT, practical for sequencing change from baseline to roadmap.
Historical Note: IBM Roots of ADM
The Baseline → Target → Gap → Roadmap cycle is not new.
It was first popularized by IBM’s Enterprise Architecture Method (EAM) and
Business Systems Planning (BSP) in the 1980s–1990s.When The Open Group created TOGAF in the mid-1990s, it drew heavily on the
U.S. DoD’s TAFIM framework — which itself was influenced by IBM’s approaches.
The TOGAF ADM expanded this simple four-step logic into nine formal phases,
with Requirements Management cutting across.In other words:
- IBM gave us the practical 4-step core.
- TOGAF formalized it into the 9-phase ADM.
- This post brings it back to its pragmatic essence, enriched with EDGY language (Capabilities, Assets, Processes) and modern domain/integration practices.
Disclaimer
This is an alternative interpretation of the TOGAF® ADM cycle, adapted for transformation contexts and expressed with EDGY’s Architecture facet (Capabilities, Assets, Processes).
It is not the official ADM diagram.TOGAF® is a registered trademark of The Open Group.
EDGY™ is a registered trademark of the Intersection Group.