Preliminary Determine the Architecture Capability the organization wants, and establish it: organizational model, governance, tools, Architecture Principles. ADM §2.1–2.4 | - •TOGAF Library; other frameworks
- •Board strategies, business principles, goals, drivers
- •Governance and legal frameworks
- •Existing Architecture Framework / Organizational Model (if any)
| - •Scope the enterprise organizations impacted
- •Confirm governance and support frameworks
- •Define and establish the EA team and organization
- •Identify and establish Architecture Principles
- •Tailor the TOGAF framework
- •Strategy for tools and techniques
| - ★Organizational Model for EA (headline output)
- ★Tailored Architecture Framework (incl. Architecture Principles) (headline output)
- •Initial Architecture Repository
- •Architecture Governance Framework
- •Request for Architecture Work (optional)
| - •Architecture Principles are DEFINED here (refined in A)
- •Sets up the capability — the "how and who" of doing EA, not a specific architecture
| Prepare the kitchen before cooking: team, rules, tools, recipe book. Memory aid — not TOGAF wording |
|---|
A · Architecture Vision Develop a high-level aspirational vision of the capabilities and business value; obtain approval for a Statement of Architecture Work. ADM §3.1–3.4 | - •Request for Architecture Work
- •Business principles, goals, drivers
- •Organizational Model for EA
- •Tailored Architecture Framework
- •Populated Architecture Repository
| - •Establish the architecture project
- •Identify stakeholders, concerns, business requirements (stakeholder map)
- •Evaluate capabilities
- •Assess readiness for business transformation
- •Define scope
- •Develop Architecture Vision
- •Develop Statement of Architecture Work; secure approval
| - ★Approved Statement of Architecture Work (headline output)
- ★Architecture Vision (headline output)
- •Capability Assessment
- •Communications Plan
- •Draft Architecture Definition Document
- •Refined principles, goals, drivers
| - •The trigger is a Request for Architecture Work
- •Approved SoAW is the key sign-off
- •Multiple business scenarios may feed a single Architecture Vision
| A = Agree: agree the vision and sign the SoAW before any detailed design. Memory aid — not TOGAF wording |
|---|
B · Business Architecture Develop the Target Business Architecture to achieve the business goals; identify candidate Architecture Roadmap components from Baseline–Target gaps. ADM §4.1–4.4 | - •Request for Architecture Work
- •Capability Assessment; Communications Plan
- •Approved Statement of Architecture Work
- •Architecture Principles
- •Architecture Vision
- •Draft Architecture Definition Document
| - •Select reference models, viewpoints, tools
- •Develop Baseline, then Target description
- •Perform gap analysis
- •Define candidate roadmap components
- •Resolve impacts; formal stakeholder review
- •Finalize; create/update the ADD
| - ★Draft ADD (Baseline + Target Business Architecture) (headline output)
- •Draft Architecture Requirements Specification
- •Business Architecture components of an Architecture Roadmap
- •Updated SoAW, principles (if necessary)
| - •B, C and D share the same 9-step pattern
- •Output is still a DRAFT ADD
| B–C–D recipe: pick models → Baseline → Target → Gap → Roadmap bits → Review → Update ADD. Memory aid — not TOGAF wording |
|---|
C · Information Systems (Data + Application) Develop the Target Information Systems Architectures (Data and Application) that enable the Business Architecture and Vision; identify candidate roadmap components. ADM §5.1–5.2 · §6 · §7 | - •Approved SoAW; Architecture Vision
- •Draft ADD and Draft Architecture Requirements Specification
- •Business (and Data) components of the Architecture Roadmap
- •Data / application principles, if existing
| - •Same 9 steps as B, done for Data and for Application
- •Baseline → Target → gap analysis per domain
- •Define candidate roadmap components
- •Create/update the ADD
| - ★Draft ADD (Data + Application) (headline output)
- •Draft Architecture Requirements Specification
- •Data and Application components of the Architecture Roadmap
| - •Data and Application may be done in EITHER order
- •Two domains → two gap analyses
- •Logical, vendor-neutral building blocks here
| C = Computers' contents: the data and the apps — any order. Memory aid — not TOGAF wording |
|---|
D · Technology Architecture Develop the Target Technology Architecture that lets business, data and application building blocks be delivered through technology components and services; identify candidate roadmap components. ADM §8.1–8.4 · §8.3.1.1 | - •Product information on candidate products
- •Technology principles, if existing
- •Approved SoAW; Architecture Vision
- •Draft ADD and Draft ARS
- •Business, Data and Application roadmap components
| - •Same 9 steps as B
- •Includes product selection (incl. dependent products)
- •Gap analysis Baseline vs Target technology
- •Create/update the ADD
| - ★Draft ADD (Baseline + Target Technology Architecture) (headline output)
- •Draft Architecture Requirements Specification
- •Technology Architecture components of the roadmap
| - •Product selection MAY occur (re-use, added capacity); significant or non-standard choices → flagged for Phase E
- •The ADD is still a DRAFT after D
| D = Define the platform; big product bets go to E. Memory aid — not TOGAF wording |
|---|
E · Opportunities & Solutions Generate the initial complete Architecture Roadmap; decide if an incremental approach (Transition Architectures) is needed; define the overall SBBs based on the ABBs. ADM §9.1–9.5 | - •Product information; planning methodologies
- •Capability Assessment; Communications Plan
- •Draft ADD and Draft ARS
- •Candidate roadmap components from B, C and D
- •Change Requests for existing programs
| - •Determine corporate change attributes and business constraints
- •Review and consolidate gap results from B–D
- •Consolidate interoperability requirements; refine dependencies
- •Confirm readiness and risk; formulate Implementation & Migration Strategy
- •Identify and group work packages; identify Transition Architectures
- •Create Architecture Roadmap & Implementation and Migration Plan
| - ★Architecture Roadmap (work package portfolio, Transition Architectures, SBBs) (headline output)
- ★Draft Implementation and Migration Plan (headline output)
- •Consolidated Gaps, Solutions, and Dependencies Assessment
- •Business and IT Capability Assessments
- •Draft ADD (Transition Architectures)
| - •Overall SBBs are defined here
- •First phase focused on HOW to deliver (work packages, Transition Architectures)
- •Roadmap and I&M Plan are still drafts
| E = Envelope of change: bundle gaps into work packages and stages. Memory aid — not TOGAF wording |
|---|
F · Migration Planning Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan, aligned with the enterprise change portfolio; make business value and cost of work packages understood. ADM §10.1–10.5 | - •Draft Architecture Roadmap
- •Draft Implementation and Migration Plan
- •Draft ADD (incl. Transition Architectures) and Draft ARS
- •Capability Assessment; Communications Plan
| - •Confirm management framework interactions
- •Assign business value to each work package
- •Estimate resources, timings, delivery
- •Prioritize migration projects via cost/benefit and risk
- •Confirm roadmap; update ADD
- •Complete I&M Plan; document lessons learned
| - ★Approved Implementation and Migration Plan (headline output)
- ★FINALIZED Architecture Definition Document (headline output)
- •FINALIZED Architecture Requirements Specification
- •FINALIZED Architecture Roadmap
- •Re-usable ABBs
- •Implementation Governance Model (if any)
- •Change Requests for the Architecture Capability (lessons learned)
| - •The Finalized ADD / ARS / Roadmap are Phase F outputs
- •Works with project and portfolio managers
| F = Finalize: every draft becomes final here. Memory aid — not TOGAF wording |
|---|
G · Implementation Governance Ensure implementation projects conform to the Target Architecture; perform Architecture Governance for the solution and implementation-driven Change Requests. ADM §11.1–11.4 · §11.3.1 | - •Implementation and Migration Plan
- •Implementation Governance Model
- •Architecture Contract (standard)
- •ADD, ARS, Architecture Roadmap
- •Architecture Governance Framework
| - •Confirm scope and priorities with development management
- •Identify deployment resources and skills
- •Guide development of solutions deployment
- •Perform EA compliance reviews
- •Implement business and IT operations
- •Post-implementation review; close
| - ★Architecture Contract (SIGNED) (headline output)
- ★Compliance Assessments (headline output)
- •Change Requests
- •Architecture-compliant solutions deployed
- •Populated Architecture Repository
| - •Architecture Contract is signed here
- •Solution Architects identify the specific SBBs needed to fill gaps
- •Architects govern — they do not build
| G = Guard: watch the builders and sign the contract. Memory aid — not TOGAF wording |
|---|
H · Architecture Change Management Ensure the architecture development cycle is maintained, the Architecture Governance Framework is executed, and the EA Capability meets current requirements. ADM §12.1–12.4 · §12.5.2 | - •Request for Architecture Work
- •SoAW; Architecture Vision; ADD; ARS; Roadmap
- •Change Requests (technology changes, business changes)
- •Architecture Contract; Compliance Assessments
- •Implementation Governance Model
| - •Establish value realization process
- •Deploy monitoring tools
- •Manage risks
- •Provide analysis for change management
- •Develop change requirements to meet performance targets
- •Manage governance process
- •Activate the process to implement change
| - •Architecture updates (maintenance changes)
- •Changes to framework and principles (maintenance changes)
- ★New Request for Architecture Work (major changes → new cycle) (headline output)
- •Updated SoAW, Architecture Contract, Compliance Assessments
| - •Three change categories: Simplification · Incremental · Re-architecting
- •Re-architecting = the whole architecture goes through the cycle again (new RfAW)
- •Simplification is handled by change management
| H = Heal or rebuild: simplify, increment, or re-architect. Memory aid — not TOGAF wording |
|---|
Requirements Management Keep the requirements process running for all relevant ADM phases; manage architecture requirements from any phase; make them available to each phase as it executes. ADM ch. 13 · ADM §1 (continuous phase) | - •Populated Architecture Repository
- •Organizational Model; Tailored Architecture Framework
- •SoAW; Architecture Vision
- •Architecture requirements populating an ARS
- •Requirements Impact Assessment
| - •Identify and baseline requirements; set priorities with stakeholders
- •Record changes in the Architecture Requirements Repository
- •Assess impact of changed requirements on current and previous phases
- •Feed results to the phase that needs them
| - ★Requirements Impact Assessment (headline output)
- •Updated Architecture Requirements Specification (if necessary)
- •Architecture Requirements Repository kept up to date
| - •Sits at the CENTRE of the ADM — a continuous phase
- •It manages requirements; it does not dispose of them itself
| RM = the heart: every phase pumps requirements through it. Memory aid — not TOGAF wording |
|---|