TOGAF® Enterprise Architecture Foundation study materials
TOGAF® Enterprise Architecture Foundation study resources

TOGAF® Enterprise Architecture Foundation cheat sheet

TOGAF® Enterprise Architecture Foundation · Keep the key ideas within reach.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.