TOGAF® Enterprise Architecture Foundation cheat sheet
TOGAF® Enterprise Architecture Foundation · Keep the key ideas within reach.
Enterprise Architecture Concepts and the Purpose and Structure of the TOGAF Framework
TOGAF is published by The Open Group. Its core is the Architecture Development Method (ADM): eight phases (A–H) plus a Preliminary Phase, with Requirements Management at the centre of the cycle.
Four architecture domains: Business, Data, Application, Technology (BDAT). Business architecture is developed in Phase B; Data and Application in Phase C; Technology in Phase D.
TOGAF defines architecture in two senses: (1) a formal description of a system, or a detailed plan at component level to guide implementation; (2) the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
The stated vision is boundaryless information flow: access to integrated information that supports business process improvement and secure sharing across organizational boundaries.
TOGAF Standard structure - six parts: Introduction; Architecture Development Method; ADM Guidelines and Techniques; Architecture Content Framework; Enterprise Continuum and Tools; Architecture Capability Framework.
An architecture principle is documented as Name, Statement, Rationale, and Implications. Principles must be complete, consistent, robust, stable, and understandable.
Architecture levels, broadest to narrowest: strategic architecture (enterprise-wide), segment architecture (business unit or program), capability architecture (a specific capability or project scope).
Iteration pattern: Preliminary sets context; Phases A–D define the architecture; E–F plan the transition; G governs implementation; H manages change and can restart the cycle.
The TOGAF Architecture Development Method (ADM): Phases, Objectives, Inputs, Outputs, and Application
Preliminary Phase: establish the desired architecture capability - define organizational context, apply architecture principles, tailor TOGAF and the ADM, and secure sponsorship. Outputs include the Organizational Model for Enterprise Architecture, the Tailored Architecture Framework, Architecture Principles, and a populated Architecture Repository.
Phase A (Architecture Vision): define scope and constraints, identify stakeholders and their concerns, produce the Architecture Vision, and obtain sponsor sign-off of the Statement of Architecture Work; also outputs the Communications Plan and Capability Assessment.
Phase B (Business Architecture): develop baseline and target Business Architecture - organization structure, business functions, services, processes, roles, and the data the business needs.
Phase C covers Data Architecture and Application Architecture, in either order (data first is typical). Phase D covers Technology Architecture: platform services, infrastructure, and technology standards.
Outputs of Phases B–D: the Architecture Definition Document (baseline and target per domain) and the Architecture Requirements Specification (quantitative statements implementations must satisfy).
Phase E (Opportunities and Solutions): consolidate the gaps from Phases B–D, group changes into work packages, define transition architectures, and produce the initial version of the Architecture Roadmap.
Phase F (Migration Planning): finalize the Architecture Roadmap, prioritize work packages, and produce the Implementation and Migration Plan plus the Implementation Governance Model.
Phase G (Implementation Governance): agree and enforce Architecture Contracts, run compliance reviews, and issue compliance assessments and change requests to delivery projects.
Phase H (Architecture Change Management): triage change requests as simplification, incremental, or re-architecting; re-architecting triggers a new ADM cycle. Requirements Management stores and tracks requirements continuously across all phases.
Architecture Content, the Architecture Content Framework, Enterprise Continuum, and Architecture Repository
Content Framework hierarchy: a deliverable is a formally reviewed and approved work product that contains artifacts; artifacts (catalogs, matrices, diagrams) describe architecture and solution building blocks.
ABB = Architecture Building Block: technology-neutral, captures architecture requirements, and directs creation of SBBs. SBB = Solution Building Block: product- or vendor-specific, implements an ABB.
Three artifact types: catalogs (lists of architecture elements), matrices (relationships between elements), and diagrams (visual representations of elements and connections).
Enterprise Continuum = Architecture Continuum + Solutions Continuum; it classifies architecture and solution artifacts as they evolve from generic to organization-specific.
Architecture Continuum levels: Foundation Architectures → Common Systems Architectures → Industry Architectures → Organization-Specific Architectures.
Solutions Continuum mirrors it: Foundation Solutions → Common Systems Solutions → Industry Solutions → Organization-Specific Solutions.
Architecture Repository comprises six parts: Architecture Metamodel, Architecture Capability, Architecture Landscape, Standards Information Base, Reference Library, and Governance Log.
The Architecture Landscape holds strategic, segment, and capability architectures; the Standards Information Base records standards with version, lifecycle status, and compliance requirements.
Deliverable map: Phase A → Statement of Architecture Work and Architecture Vision; B–D → Architecture Definition Document and Architecture Requirements Specification; E–F → Architecture Roadmap and Implementation and Migration Plan; G → Architecture Contract.
Architecture Capability, Architecture Governance, and Stakeholder and View Management
Architecture Capability is the organization's ability to do architecture work: roles, responsibilities, skills, processes, tools, and governance. It is established in the Preliminary Phase.
Architecture Board duties: approve architecture, monitor compliance, resolve architecture disputes, and provide direction. Membership spans business and IT and the board operates under a charter.
Governance instruments: Architecture Principles, the Architecture Board, Architecture Contracts, compliance reviews, and the Governance Log.
Six architecture compliance levels: Irrelevant, Consistent, Compliant, Conformant, Fully Conformant, and Non-Conformant.
Viewpoint versus view: the viewpoint supplies the conventions and template (where you look from); the view is the representation the stakeholder actually sees.
Stakeholder management: identify stakeholders in Phase A, map them by influence and interest, record their concerns, and set engagement approach in the Communications Plan.
The TOGAF Architecture Capability Maturity Model (ACMM) is based on CMMI and rates architecture maturity from Level 0 (None) to Level 5 (Measured).
The Architecture Skills Framework defines roles, required skills, and depth of knowledge for practitioners, supporting capability planning, recruitment, and professional development.