# TOGAF ADM ↔ eTOM Mapping Sheet

A working reference for where TOGAF's ADM phases and eTOM's process
framework overlap, and where they don't — use this to decide which
artefacts each phase of your architecture programme actually needs to
produce, instead of re-litigating it every time.

| TOGAF ADM Phase | Primary Purpose | Corresponding eTOM Level | Typical eTOM Processes Engaged | Notes |
|---|---|---|---|---|
| Preliminary | Establish architecture capability & principles | — | — | eTOM has no direct equivalent — this is where you decide *how* you'll use eTOM going forward |
| A: Architecture Vision | Define scope, stakeholders, high-level vision | Level 0 | Strategy, Infrastructure & Product; Operations; Enterprise Management | Vision should name which Level 0 domains are actually in scope |
| B: Business Architecture | Define target business processes & organisation | Level 1–2 | e.g. Order Handling, Problem Handling, Customer Management | Most eTOM mapping work concentrates here |
| C: Information Systems Architecture (Data) | Define data entities and their relationships | — | Map to SID domains, not eTOM directly | Use SID as your data reference model at this step, not eTOM |
| C: Information Systems Architecture (Application) | Define application components | Level 2 | Application capability should trace to specific L2 processes | Cross-check against TAM for application-type coverage |
| D: Technology Architecture | Define technology platform | — | — | eTOM is process-focused; ODA is the better technology-layer reference here |
| E: Opportunities & Solutions | Identify delivery packages / projects | Level 2–3 | Group by process area to define logical delivery packages | |
| F: Migration Planning | Sequence the transition states | — | — | Sequence by which eTOM processes are most fallout-prone or highest business risk |
| G: Implementation Governance | Ensure delivery conforms to architecture | — | — | ARB should check conformance against the Level 1–2 process map, not just the tech design |
| H: Architecture Change Management | Manage ongoing change | — | — | Re-run the Business Architecture mapping whenever eTOM process scope changes materially |
| Requirements Management | Continuous, runs through all phases | All levels | All | Every requirement should cite the eTOM process and SID domain it affects |

## Worked Example: Order-to-Activate

| ADM Phase | What you'd produce for this journey |
|---|---|
| Vision | Scope statement: reduce order fallout and activation time for a defined product set |
| Business Architecture | Process map of Order Handling (eTOM L1/L2), as-is and target state |
| Data Architecture | Customer, Product, Service and Resource entities from SID, with ownership assigned |
| Application Architecture | Order Management, Product Catalog, Provisioning and Billing components, mapped to ODA |
| Technology Architecture | Integration pattern (orchestration vs. choreography) for the order lifecycle |
| Opportunities & Solutions | Phased delivery: catalogue consolidation first, then the order engine, then provisioning automation |
| Migration Planning | Transition states sequenced so each phase reduces fallout independently, even if the programme stalls after one phase |