Skip to content
What is the TOGAF ADM? – Larkinized
togaf

What is the TOGAF ADM?

The TOGAF Architecture Development Method (ADM) is a iterative cycle of phases for developing and maintaining Enterprise Architecture—from initial vision and business architecture through information systems architectures, opportunities and solutions, migration planning, implementation governance, and architecture change management.

ADM as an Iterative Architecture Cycle

The ADM is not a waterfall checklist but a cycle organizations traverse repeatedly at varying scope—whole enterprise, segment, or project. Each pass refines architecture as strategy, technology, and delivery feedback evolve. Requirements Management sits at the center, continuously feeding all phases so architecture stays aligned with stakeholder needs.

Preliminary Phase establishes architecture capability—principles, governance, frameworks tailored to the organization. Without preliminary work, later phases lack decision criteria and authority. Many failed TOGAF adoptions skip this foundation and wonder why reviews lack teeth.

Phase A Architecture Vision sets scope, stakeholders, constraints, and high-level aspirational target aligned to strategic drivers. It produces the charter for deeper architecture work and secures executive sponsorship before expensive modeling begins.

ADM iteration boundaries should be documented in architecture contracts for major programs—what constitutes complete Phase C for this funding gate versus deferred detail.

Domain Phases: Business Through Technology

Phase B Business Architecture develops baseline and target business architecture—capabilities, organization, processes, value streams as applicable. Phase C covers Information Systems Architectures split into Data and Application domains, detailing entities, applications, interfaces, and gaps. Phase D Technology Architecture describes hardware, software, network, and platform target states supporting applications and data.

These phases produce structured gap analyses between baseline and target across domains. Cross-domain dependencies—data shared by multiple applications, platforms hosting critical capabilities—surface here for migration planning.

Organizations may iterate B through D out of strict order when drivers demand—cloud-first programs may emphasize Phase D constraints early—but all domains must eventually reconcile to avoid incoherent targets.

Cross-phase workshops prevent handoff loss—invite migration planners into gap analysis sessions so surprises do not appear only at Phase F.

Planning and Delivery Phases

Phase E Opportunities and Solutions identifies major projects, identifies dependencies, and evaluates build versus buy versus reuse options at a portfolio level. Phase F Migration Planning sequences work packages, estimates resources, and produces the Implementation and Migration Plan that executives fund.

Phase G Implementation Governance ensures projects comply with target architecture and standards during delivery, updating architecture descriptions as solutions deploy. Phase H Architecture Change Management captures lessons, triggers new ADM cycles when external or internal changes invalidate assumptions.

These phases connect EA to PMO and agile delivery. Migration plans become portfolio backlogs; governance integrates with architecture review boards and release processes.

Architecture contracts with project managers define which ADM outputs are acceptance criteria for phase completion—reducing ambiguity at closeout.

Tailoring the ADM

TOGAF explicitly encourages tailoring—skipping phases for narrow scope, combining phases for speed, running agile iterations within phases. A divisional roadmap might emphasize B and F; a platform program might loop C and D rapidly with frequent Phase H updates.

Tailoring must be documented and agreed with stakeholders so shortcuts do not become silent omissions of risk. Architecture contracts should state which ADM outputs apply to which initiative tiers.

Larkinized LLC documents tailoring decisions in architecture governance charters so teams share expectations about depth, templates, and review points.

Lessons learned repositories tagged by ADM phase build institutional tailoring knowledge—Phase B facilitation tips accumulate over cycles.

Common ADM Pitfalls and Success Patterns

Pitfalls include treating ADM as linear documentation marathon, producing targets disconnected from funding cycles, and failing to update baselines after implementation. Success patterns link Phase A visions to live strategic programs, time-box modeling to decision needs, and embed Phase G reviews in existing stage gates or agile release governance.

Executive-readable outputs from each phase—not only technical models—sustain sponsorship. Migration plans expressed in business outcomes and capability milestones resonate more than infrastructure diagrams alone.

Mature practitioners view ADM as organizational learning loop: each cycle improves repository quality, sharpens principles, and accelerates the next pass.

External change triggers—new regulation, merger—should explicitly launch Phase H assessment with checklist rather than informal ad hoc reactions.

Running Your First ADM Workshop Series

Larkinized LLC schedules ADM workshops in executive-friendly sequences: half-day vision, full-day business capability for priority segment, two half-days for application and data inventory synthesis, full-day migration sequencing. Pre-work includes surveys and data extracts so workshop time debates decisions rather than collecting facts live. Graphic recorders or digital whiteboards capture outcomes directly into repository tools same week—momentum prevents decay.

Requirements Management central to ADM succeeds when linked to product management backlogs. Architecturally significant requirements appear as enabler epics with acceptance criteria referencing principles and standards. Bi-directional traceability from vision to stories prevents drift without separate requirements silo.

ADM cycles should publish executive one-pagers after each major phase—vision statement, top ten gaps, migration wave summary—so sponsors stay engaged without reading technical catalogs. Communication is part of the method, not optional packaging.

ADM Artifacts in Digital Workflow

Digital workflow integration means ADM outputs are URLs in workflow tools with approval stamps—not email attachments lost in inboxes.

ADM phase checklists embedded in project templates reduce forgotten steps without heavyweight bureaucracy.

Retrospectives tag improvement actions to specific ADM phases—Phase B facilitation improved, Phase G automated checks added.

ADM training simulations using internal historical programs beat abstract case studies for adult learning retention.

Practical Guidance from Larkinized LLC

Larkinized LLC documents ADM tailoring in governance charters— which phases apply to which initiative tiers, expected outputs, review SLAs—so teams do not guess depth each project start.

Cross-phase workshops keep migration planners in gap analysis sessions—surprises at Phase F mean Phase B through D failed to include operations and finance voices with authority to commit.

Requirements Management at ADM center is operational discipline, not diagram decoration—continuous stakeholder concern updates prevent architecture describing last year’s strategy during this year’s funding.

Phase G integrates with existing stage gates or release trains—parallel shadow processes die from neglect. Architecture compliance checks must be steps teams already perform, enriched with architecture criteria.

Phase H triggers on defined change events—regulation, merger, platform obsolescence—with checklists rather than ad hoc panic replanning. Change management maturity separates repeatable EA from one-off consulting visits.

ADM iteration at segment scope delivers value before enterprise-wide encyclopedia completion—executives fund next iteration when first segment decisions improve; marathon cycles without milestones lose sponsorship.

Larkinized LLC connects guidance on what is the togaf adm to named portfolio decisions within the current fiscal year so architecture work is legible in funding systems executives already use. Workshop outputs publish to the repository within two weeks with owners assigned, preventing loss of context when facilitators rotate or consultants depart after initial engagement.

Cross-functional participation includes operations staff who execute daily processes—not only senior leaders whose high-level views omit workarounds that define real performance. Their input grounds models in operational truth and reduces downstream rejection when delivery teams claim architecture ignored how work actually happens.

Education scales beyond central architects through micro-learning for product owners, procurement staff, and engineers, reducing exceptions driven by ignorance rather than genuine strategic conflict. Office hours and internal communities of practice keep guidance current as cloud, agile, and AI practices evolve faster than annual training cycles.

Measurement pairs business KPIs—cycle time, cost per transaction, error rates, regulatory findings—with architecture metrics such as repository usage, review SLA compliance, and portfolio alignment scores. Improvements tied to architecture interventions build executive trust more reliably than model counts alone.

Regulatory and audit stakeholders increasingly expect traceability; viewpoint-specific views linked to repository entities produce evidence in days rather than weeks during examinations. Proactive documentation reduces fire drills, punitive findings, and leadership distraction from core transformation priorities.

M&A, divestiture, and market expansion stress-test architecture assets—scenario playbooks updated annually let leadership pivot with cost and timeline estimates instead of panic discovery after announcements. Capability maps and application inventories become due diligence assets before deals close, not afterthought spreadsheets.

Governance forums for what is the togaf adm should meet on a predictable cadence tied to portfolio and release planning—not ad hoc when crises force attention. Larkinized LLC recommends standing architecture review slots with published intake criteria, SLA targets, and escalation paths so delivery teams know how to engage without treating architecture as unpredictable gatekeeping that rewards political access over merit of design.

Traceability from strategy statements to capability or architecture elements to funded initiatives to deployed solutions closes the loop executives expect when they approve EA funding. Without traceability, architecture remains a parallel documentation universe. Link charters, requirements, design records, and operational inventories in one searchable repository so auditors, product managers, and engineers retrieve consistent answers instead of conflicting spreadsheets maintained in silos.

Risk management benefits when what is the togaf adm practices identify concentration risks—single vendor platforms, fragile integrations, key-person dependencies, regions without failover—and map mitigations into migration plans with owners and dates. Risk registers integrated with architecture repositories beat oral tradition during incidents when leadership demands answers within hours and teams cannot afford heroic manual discovery across dozens of systems.

Innovation programs need explicit guardrails within what is the togaf adm so experiments proceed safely: sandbox environments, data masking rules, time-boxed pilots, and kill criteria before production commitments. Architecture enables innovation velocity by stating what teams may try without enterprise approval versus what requires board-level review because customer data, financial reporting, or safety-critical operations are affected.

Global enterprises localizing what is the togaf adm should tier standards: mandatory worldwide, recommended regional, optional local—documented in governance charters to prevent both harmful divergence and rejection of valid regional regulatory requirements. Regional architects on a council synchronize proposals before they become de facto standards that conflict with enterprise principles approved by executive sponsors accountable to the board.

Quality assurance for architecture artifacts includes peer review, automated validation where schemas exist, and executive readability checks before publication. Larkinized LLC teaches teams to reject diagrams that look complete but lack definitions, owners, and measures—hallmarks of documentation theater that erodes trust faster than publishing fewer, higher-quality views updated on schedule.

Stakeholder onboarding for what is the togaf adm never ends; annual refreshers for new leaders, rotating product managers, and engineers hired from acquisitions prevent repeated violations caused by ignorance rather than defiance. Micro-learning, office hours, and annotated examples in repositories scale literacy without requiring week-long courses that busy executives and engineers will not attend consistently.

Ultimately what is the togaf adm succeeds when leaders reference architecture evidence in routine decisions—funding, hiring, vendor selection, incident response—not only during transformations. Larkinized LLC measures cultural adoption through decision log sampling: what percentage of major investments cited architecture assets in approval packets last quarter? Rising percentages indicate durability; flat or falling percentages signal sponsorship or relevance problems requiring honest retrospective, not additional templates.

TOGAF ADM Cycle

Circular ADM diagram showing phases A through H—Preliminary, A Vision, B Business, C Information Systems, D Technology, E Opportunities, F Migration, G Implementation Governance, H Change Management—with Requirements Management at the center.

TOGAF ADM Cycle

Key Takeaways

  • The ADM is an iterative cycle of phases from capability setup through change management.
  • Phases B through D develop business, data, application, and technology architectures with gap analysis.
  • Phases E through F plan portfolio work and migration; G and H govern delivery and capture change.
  • Tailor ADM scope and depth to initiative risk—document tailoring explicitly.
  • Link ADM outputs to funding cycles and governance already used in the organization.

References & Further Reading

  • The Open Group, TOGAF Standard — Architecture Development Method
  • The Open Group, Applying the ADM in Agile Environments
  • Gartner, Practical ADM Tailoring Guide

Need Expert Guidance?

Larkinized LLC helps organizations design, govern, and execute enterprise architecture programs that deliver measurable business outcomes.

Scroll to Top
Scroll to Top