TOGAF EA Practitioner cheat sheet

The Preliminary Phase has exactly two objectives: determine the Architecture Capability that the organization requires, and establish that capability.

Typical outputs are the Organizational Model for Enterprise Architecture, tailored ADM and architecture principles, the Architecture Governance framework, the Architecture Repository, the Architecture Capability Framework, and a Request for Architecture Work.

Architecture Governance operates at corporate, IT, architecture, and technology portfolio levels, and is a quality-of-service concept: disciplined, transparent, and accountable control of architecture creation, maintenance, and monitoring.

The Architecture Board is the principal governing body: it approves architecture, resolves inter-project conflicts, monitors compliance, and sponsors the architecture program; it is usually chaired by the CIO or Chief Architect.

Architecture principles are recorded with a Name, Statement, Rationale, and Implications, are few and stable, and must be formally approved by the executive before use.

The Architecture Maturity Model uses six levels: 0 None, 1 Initial, 2 Under Development, 3 Defined, 4 Managed, 5 Optimized.

The Architecture Skills Framework defines architecture roles, the skills each role needs, and the proficiency levels required, and is used to plan capability development.

Business principles, business goals, and business drivers are inputs to the Preliminary Phase; they are elicited from the enterprise, not created by the architecture function.

ADM tailoring decisions in the Preliminary Phase cover the level of iteration (whole enterprise, segment, capability, or project), scope, and formality.

Phase A objectives: develop a high-level aspirational vision of the capabilities and business value to be delivered, and obtain approval of the Statement of Architecture Work.

Standard steps include establishing the architecture project, identifying stakeholders and concerns, confirming business goals and drivers, evaluating capabilities, assessing transformation readiness, defining scope, and defining the vision.

Key outputs are the Architecture Vision, the approved Statement of Architecture Work, the Capability Assessment, the Communications Plan, and a draft Architecture Definition Document with a Solution Concept Diagram.

The Architecture Vision must be approved by the sponsor and/or Architecture Board before Phase B proceeds; the Statement of Architecture Work is the contract authorizing the engagement.

Phase A views typically include a business scenario or value chain view and a solution concept diagram, chosen from the stakeholder map to address high-priority concerns.

Stakeholders are catalogued and classified using a power/interest grid, which determines the level of engagement and the views produced.

Phase A is re-entered at the start of every ADM cycle, and may also be re-entered when Phase H identifies a re-architecting change.

The Business Transformation Readiness Assessment is first performed in Phase A and reused in Phase E to shape the implementation strategy.

Phase B develops a Baseline Business Architecture and a Target Business Architecture, and performs gap analysis between them, describing the business strategy, capabilities, processes, functions, roles, and organizational structure.

Common techniques are the Business Model Canvas, Business Capability Map, Value Stream Map, Organization Map, and BPMN process modeling.

Outputs populate the Architecture Definition Document and the Architecture Requirements Specification, including business catalogs, matrices, and diagrams.

Gap analysis classifies elements as added, removed, changed, or retained between baseline and target; retained elements must be explicitly recorded.

Business architecture elements must trace back to the business goals, drivers, and vision established in Phase A.

Business services are the building blocks of the Business Architecture and are later mapped to information systems and technology building blocks.

Phase B may be executed at whole-enterprise, segment, or capability level, and may iterate with Phase A if the vision cannot be supported.

Non-functional and behavioral business requirements identified here enter the Architecture Requirements Specification for central management.

Phase C comprises two sub-phases: Data Architecture and Application Architecture; they may be carried out in either order, though data-first is the more common practice.

Data Architecture deliverables include the Data Entity/Data Component Catalog, Data Entity/Data Component Diagram, Data Dissemination Diagram, Data Security Diagram, Data Migration Diagram, and Data Lifecycle Diagram.

Application Architecture deliverables include the Application Portfolio Catalog, Application/Function Matrix, Application Communication Diagram, Application and User Location Diagram, and Application Use-Case Diagram.

The Integrated Information Infrastructure Reference Model (III-RM) is the TOGAF reference model for boundaryless information flow and is reused here where relevant.

Both sub-phases produce baseline and target descriptions plus a gap analysis, and both feed the Architecture Requirements Specification.

Information systems services are defined as building blocks so that Phase D can map them to technology components.

Reference models, standards, and existing assets held in the Architecture Repository must be checked before new data or application models are created.

Access to data and application services should be modeled through the principle of service encapsulation, ensuring services are reusable and location independent.

Phase D describes the baseline and target Technology Architecture: hardware, software infrastructure, networks, communications, processing, and technology standards.

Deliverables include the Technology Standards Catalog, Technology Portfolio Catalog, Environments and Locations Diagram, Platform Decomposition Diagram, Processing Diagram, and Networked Computing/Hardware Diagram.

The TOGAF Technical Reference Model provides the taxonomy and nomenclature of technology services, and the Standards Information Base records the standards that apply.

Design considers security, manageability, performance, availability, scalability, and cost, and must satisfy the information systems and business requirements already specified.

Technology building blocks are defined as candidate Solution Building Blocks derived from the Architecture Building Blocks identified in earlier phases.

A gap analysis between baseline and target technology identifies replaced, retired, and newly introduced technology components.

Phase D commonly iterates with Phase C because application placement decisions constrain, and are constrained by, infrastructure capabilities.

Emerging technologies recognized in Phase D that are not required by the current target feed the change management process in Phase H.

Phase E consolidates the gaps, solutions, and dependencies from Phases B to D into work packages and identifies transition architectures that deliver value before the target state is complete.

Three implementation and migration strategy options are evaluated: Greenfield (build anew), Revolutionary (replace in a single step), and Evolutionary (incremental delivery).

The phase determines which Architecture Building Blocks are reused, replaced, outgrown, or retired, and defines candidate Solution Building Blocks for each work package.

Capability-Based Planning is used to define increments that each deliver a coherent set of business capabilities and measurable business outcomes.

Outputs include the initial Architecture Roadmap, Transition Architectures, Work Packages, the Implementation and Migration Strategy, and the Consolidated Gaps, Solutions, and Dependencies Matrix.

Work packages are grouped by considering dependencies, business value, technical risk, and the capability increments they deliver.

The Business Transformation Readiness Assessment from Phase A is applied here to judge whether each candidate increment is achievable.

Phase E does not produce detailed schedules or costs; those are produced in Phase F during migration planning.

Phase F finalizes the Architecture Roadmap and the Implementation and Migration Plan, and completes the Transition Architectures defined in Phase E.

The Implementation Factor Assessment and Deduction Matrix lists factors affecting implementation, their impact, and the deductions that determine how work packages are organized.

Projects and work packages are prioritized with criteria such as business value, technical risk, cost, resource availability, and dependency; business value against technical risk is the classic plotting.

Outputs include the Implementation and Migration Plan, finalized Transition Architectures, the Benefits and Cost/Business Case information, and the Consolidated Gaps, Solutions, and Dependencies Matrix.

Each work package in the plan is described with its deliverables, milestones, resources, dependencies, and the transition architecture it realizes.

Costs, benefits, and return on investment are estimated and validated with the sponsor to confirm the business case before implementation begins.

Phase F aligns the migration plan with the organization's portfolio and project management methods so that projects can be initiated and resourced.

Phase G begins as soon as the first implementation project is launched from the plan; Phases F and G therefore run concurrently.

Phase G objectives: ensure conformance of implementation projects with the target architecture, and ensure that deployed solutions deliver the expected business value.

The Architecture Contract is agreed between the architecture function and the implementation organization, stating purpose, scope, conformance requirements, acceptance criteria, deliverables, and milestones.

Architecture Compliance Reviews compare project work products with the specification using checklists and a scoring model, and record dispositions with conditions for acceptance.

Typical dispositions are conformant, conformant with conditions, and non-conformant; non-conformance may be escalated to the Architecture Board for a decision to proceed or halt.

Change requests raised by implementers are routed back to the architecture function for impact assessment, and significant ones return to Phase H.

Phase G performs implementation governance through the Architecture Board, architecture contracts, compliance reviews, and deployment oversight.

Implementation governance must also verify that the deployed solution supports the business goals recorded in the Architecture Vision.

Lessons learned and implementation issues recorded in Phase G feed the next ADM cycle through the architecture change management process.

Phase H establishes and operates the processes for managing architecture change, monitors business and technology trends, and maintains the architecture capability and value realization.

Changes are classified into three categories: Simplification Change, Incremental Change, and Re-Architecting Change.

Simplification Change reduces complexity without altering architecture scope and is handled by change management without re-entering the ADM.

Incremental Change extends capabilities inside existing architectural boundaries and usually re-enters the ADM at a later phase such as Phase B, C, or D.

Re-Architecting Change fundamentally alters scope or approach and re-enters the ADM at Phase A, restarting the cycle.

Change drivers include business changes, technology changes, simplification opportunities, and changes in the architecture capability itself.

The Architecture Board governs change via change requests, compliance reviews, and the decision on whether and where to re-enter the ADM.

Phase H also maintains the Architecture Repository and closes the loop by feeding confirmed changes into the next iteration of the ADM.

Requirements Management is the central, continuous phase of the ADM: it stores, prioritizes, and disseminates requirements to every phase through the Requirements Repository.

The Architecture Requirements Specification holds the requirements the architecture must satisfy, with measurable acceptance criteria, and is the basis for compliance checking in Phase G.

A Requirements Impact Assessment determines the effect of a requirements change on the architecture and identifies which ADM phase must be re-entered.

The Business Scenario technique specifies a problem, the business and technology environment, the actors and roles, the desired outcome, and the measures of success used to validate it.

The Business Transformation Readiness Assessment scores readiness factors on maturity, readiness, and difficulty, and records the risk of not addressing each factor.

Gap analysis compares baseline and target element by element and classifies elements as added, removed, changed, or retained.

ADM iteration is applied at four levels: strategic (whole enterprise), segment, capability, and project-level architecture.

Risk management is performed in every phase: risks are identified, classified, mitigated, and residual risk is recorded for acceptance by the sponsor.

Interoperability requirements are captured and assessed per phase, because they constrain how building blocks from different architectures can be assembled.