TOGAF Enterprise Architecture cheat sheet

TOGAF defines an Enterprise as a collection of organizations that has a common set of goals and/or a single bottom line; it may be a whole company, a division, or an extended enterprise.

TOGAF identifies four architecture domains: Business, Data, Application, and Technology (commonly abbreviated BDAT); Data plus Application together make up the Information Systems Architectures.

Architecture is defined as the fundamental concepts or properties of a system in its environment, embodied in its elements, relationships, and principles of design and evolution.

TOGAF 10 splits the standard into TOGAF Fundamental Content (the core, containing the ADM and its supporting content) and the TOGAF Series Guides, which provide topic-specific guidance.

The core components of TOGAF 9.2 are the ADM, ADM Guidelines and Techniques, the Architecture Content Framework, the Enterprise Continuum and Tools, and the Architecture Capability Framework.

An Architecture Principle is documented in four parts (Name, Statement, Rationale, Implications) and is judged against the criteria Understandability, Robustness, Completeness, Consistency, and Stability.

TOGAF is a framework, not a methodology: it is designed to be tailored to the size, culture, and context of the enterprise before it is used.

The Enterprise Continuum is a view of the Architecture Repository that ranges from generic Foundation Architectures, through Common Systems and Industry architectures, to Organization-Specific architectures.

The ADM is iterative and cyclic, and TOGAF allows it to be applied at the strategic (whole enterprise), segment (business unit or programme), and capability (single capability) levels.

The Preliminary Phase prepares the organization: it establishes architecture principles, architecture governance, the architecture capability, and any tailoring of TOGAF, and it produces the Organizational Model for Enterprise Architecture.

Phase A (Architecture Vision) establishes scope, stakeholders, and business goals; it delivers the Architecture Vision and, once approved, the Statement of Architecture Work, with the Request for Architecture Work as a key input.

Phase B develops the Business Architecture, Phase C develops the Information Systems Architectures (Data and Application), and Phase D develops the Technology Architecture.

Phases B, C, and D each describe a baseline architecture, define a target architecture, and carry out a gap analysis, recording results in the Architecture Definition Document.

Phase E (Opportunities and Solutions) consolidates gaps into work packages, groups them into projects, and defines transition architectures and candidate solution building blocks.

Phase F (Migration Planning) sequences the work packages and produces the Implementation and Migration Plan, prioritizing by business value, cost, and risk.

Phase G (Implementation Governance) ensures conformance of implementation projects through Architecture Contracts and architecture compliance reviews.

Phase H (Architecture Change Management) manages requests for architecture change and classifies drivers as simplification, incremental change, or re-architecting.

Requirements Management is the central phase of the ADM: it has no phase letter, spans every phase, and stores and feeds requirements to all other phases.

The Business Scenario technique documents a business problem in terms of problem, environment, objectives, human actors, computer actors, and roles and responsibilities, and uses it to derive architecture requirements.

Gap analysis compares the Baseline Architecture with the Target Architecture to identify elements that are added, removed, and retained.

The Risk Management technique classifies risks and tracks them through the states initial risk, identified risk, mitigated risk, and residual risk.

The Business Transformation Readiness Assessment rates readiness factors (such as culture, funding, skills, and sponsorship) and derives actions needed before a transformation can succeed.

Capability-Based Planning plans change around business capabilities and business outcomes rather than around existing organizational silos.

The Interoperability Requirements technique specifies the degree of sharing required between systems at business process, information, and technical levels, and states it as a requirement.

Migration planning techniques include the Implementation Factor Assessment and Deduction Matrix, the Consolidated Gaps, Solutions and Dependencies assessment, the Architecture Roadmap, and Transition Architectures.

Architecture Alternatives and Trade-offs supports systematic comparison of architecture options, for example through weighted criteria in a decision matrix.

The Content Framework distinguishes Deliverables (formal, contractual work products), Artifacts (finer-grained work products inside a deliverable), and Building Blocks (reusable packages of functionality).

Architecture Building Blocks (ABBs) describe the capability that is required; Solution Building Blocks (SBBs) describe the components that will implement it.

Artifacts are classified as catalogs (lists of things), matrices (relationships between things), or diagrams (pictures of relationships).

Core deliverables include the Architecture Vision, Architecture Definition Document, Architecture Requirements Specification, Architecture Roadmap, and Implementation and Migration Plan.

The Architecture Repository holds the Architecture Metamodel, Architecture Capability, Architecture Landscape, Standards Information Base, Reference Library, Governance Log, Architecture Requirements Repository, and Solutions Landscape.

The Architecture Landscape is organized into strategic architectures (whole enterprise), segment architectures (a business unit or programme), and capability architectures (a single capability).

Phases A to D populate the Architecture Definition Document and Architecture Requirements Specification, while Phases E and F populate the Architecture Roadmap and Implementation and Migration Plan.

The Statement of Architecture Work is the agreement between sponsor and architecture function for one ADM cycle, whereas the Architecture Contract governs the implementation of the architecture in Phase G.

The Architecture Capability Framework covers the Architecture Board, Architecture Compliance, Architecture Contracts, Architecture Governance, Architecture Maturity Models, and the Architecture Skills Framework.

The Architecture Board is responsible for consistency of the architecture, enforcement of architecture compliance, resolution of escalation and conflict, and approval of architecture changes.

Architecture Governance is the practice of managing and controlling enterprise architectures at a strategic level, and it operates as part of wider corporate and IT governance.

Architecture Contracts are jointly agreed between the sponsor and development partners and cover deliverables, quality expectations, and compliance requirements; they are applied in Phase G.

The Architecture Maturity Model (ACMM) has levels 0 None, 1 Initial, 2 Under Development, 3 Defined, 4 Managed, and 5 Optimized.

The Architecture Compliance review process identifies scope and roles, selects checklists, conducts the review, produces the compliance assessment, and escalates deviations to the Architecture Board.

The Governance Log in the Architecture Repository records governance decisions, compliance assessments, and any dispensations granted.

The Architecture Skills Framework defines architecture roles together with the skills and proficiency levels required, and is used for capability planning and staff development.

TOGAF defines four iteration cycles around the ADM: Architecture Context (Preliminary and Phase A), Architecture Definition (Phases B, C, D), Transition Planning (Phases E, F), and Architecture Governance (Phases G, H).

ADM phases may be applied iteratively and concurrently; TOGAF states that the boundaries between phases are flexible rather than strictly sequential.

Agile application of TOGAF uses short iterations in which the architecture emerges incrementally, supported by an architecture backlog and only sufficient up-front description.

Tailoring the ADM adjusts scope, level of detail, deliverables, and phase sequence to the size, culture, and context of the enterprise.

Segment architectures address a part of the enterprise such as a business unit, while capability architectures address a single business capability and are the most detailed level.

TOGAF Series Guides address specific practices including Business Architecture, Business Capabilities, Value Streams, Agile application of the ADM, and Digital Transformation.

Digital transformation guidance emphasizes customer-centricity, product-based delivery, participation in business ecosystems, and data-driven services.

In Agile and digital contexts, architecture is continuously validated against working products and running solutions rather than solely through document-based review.