# Practical TOGAF Adoption

## Start with a business problem

Do not begin by announcing a framework rollout. Begin with a consequential
problem that needs better cross-enterprise decisions, such as:

- reducing customer onboarding time;
- modernizing a critical legacy estate;
- meeting a regulatory deadline;
- consolidating duplicate platforms after a merger;
- improving data trust;
- enabling a new digital business model.

Use TOGAF to structure the response, then retain practices that prove useful.

## A 90-day bootstrap

### Days 1–30: establish the minimum

- confirm sponsor, mandate, scope, and outcomes;
- map key stakeholders and governance;
- inventory existing strategy, portfolio, risk, and architecture material;
- define 5–10 useful principles;
- choose a pilot engagement;
- establish a lightweight repository and decision log;
- agree architecture roles and escalation paths.

### Days 31–60: run a pilot

- produce a concise vision and Statement of Architecture Work;
- develop fit-for-purpose baseline and target views;
- identify requirements, gaps, dependencies, and options;
- work alongside product and delivery teams;
- record decisions and reusable findings;
- test a risk-based review process.

### Days 61–90: connect and improve

- agree the roadmap with portfolio and delivery owners;
- publish reusable patterns and standards discovered by the pilot;
- measure lead time, stakeholder usefulness, and decision outcomes;
- remove unnecessary artifacts or approvals;
- clarify decision rights exposed by the pilot;
- select the next engagement and maturity improvements.

## Tailoring the ADM

Tailor along these dimensions:

| Dimension | Questions |
|---|---|
| Scope | Enterprise, domain, product, capability, or solution? |
| Risk | What is the impact if the decision is wrong? |
| Reversibility | How costly is it to change later? |
| Uncertainty | What must be learned before commitment? |
| Regulation | What evidence and approval are mandatory? |
| Delivery model | Project, product, Agile, vendor-led, or hybrid? |
| Time horizon | Immediate release, roadmap, or strategic target? |
| Existing assets | What can be reused rather than recreated? |

Examples:

- A strategy-led transformation emphasizes Phases A–F and multiple transition
  architectures.
- A solution engagement may consume established domain architecture and focus
  on scoped B–D work plus Phase G.
- A product team may run small continuous cycles synchronized with quarterly
  planning.
- A regulated platform may need deeper requirements traceability and formal
  compliance evidence.

## Engagement tiers

| Tier | Typical trigger | Architecture response |
|---|---|---|
| 0: Local/reversible | Small change within guardrails | Team decision or ADR |
| 1: Bounded | One product/domain, moderate risk | Architect consultation and focused views |
| 2: Material | Multiple systems/teams or high risk | Formal architecture engagement and reviews |
| 3: Strategic | Enterprise-wide, regulated, or irreversible | Full governance, roadmap, and executive decisions |

Define quantitative and qualitative thresholds appropriate to the organization.

## Minimum operating cadence

- weekly architecture office hours or clinics;
- architecture participation in discovery and portfolio shaping;
- asynchronous decision records with response targets;
- regular domain/landscape review;
- risk-based compliance points;
- quarterly principles, standards, and debt review;
- outcome and architecture health reporting.

## Integrate with existing management systems

Architecture should connect to:

- **strategy** for drivers, outcomes, and scenarios;
- **portfolio management** for prioritization and funding;
- **product management** for persistent outcomes and roadmaps;
- **program/project management** for dependencies and delivery control;
- **security and risk** for requirements and acceptance;
- **data governance** for ownership, quality, and permitted use;
- **procurement** for architecture-aligned evaluation;
- **engineering** for patterns, standards, and automation;
- **operations** for service evidence and lifecycle feedback.

Do not create parallel truth when another authoritative system already exists.
Link to it.

## How much baseline is enough?

Capture baseline detail when it affects:

- a target decision;
- a gap or dependency;
- migration feasibility;
- cost or risk;
- stakeholder understanding;
- compliance or operational continuity.

Stop mapping when additional detail no longer changes the decision or roadmap.

## Workshop sequence for a pilot

1. **Outcome and scope** — drivers, measures, boundaries.
2. **Stakeholders and concerns** — decisions and communication.
3. **Baseline** — relevant pain points and constraints.
4. **Target options** — principles, scenarios, trade-offs.
5. **Domain coherence** — business, data, application, technology.
6. **Gaps and work packages** — dependencies and transition states.
7. **Roadmap** — priority, ownership, outcomes.
8. **Governance** — evidence, decision points, exceptions.

Send pre-reading and record decisions during the session.

## Common adoption failures

### Framework-first rollout

Symptoms: training, templates, and tools appear before a valued use case.

Correction: demonstrate value on a real decision and evolve the method from
evidence.

### Artifact factory

Symptoms: document completeness is rewarded, but decisions and outcomes are
unclear.

Correction: require each artifact to name its audience, concern, and decision.

### Review board bottleneck

Symptoms: teams wait weeks for a committee unfamiliar with their context.

Correction: delegate bounded decisions, publish guardrails, engage earlier, and
set response-time targets.

### Ivory-tower target state

Symptoms: elegant models ignore funding, legacy constraints, delivery capacity,
or operations.

Correction: co-create with delivery, finance, operations, and affected business
owners; use transition states.

### Tool-led metamodel

Symptoms: teams populate hundreds of fields because a repository supports them.

Correction: begin with questions the repository must answer, then model the
minimum data needed.

### Architecture without authority

Symptoms: principles and decisions are routinely ignored.

Correction: establish sponsorship, decision rights, portfolio connection, and
transparent exception handling.

### Governance without feedback

Symptoms: designs are approved but real implementations and outcomes are never
examined.

Correction: use operational evidence, post-implementation learning, and Phase H
to update the architecture.

## Adoption measures

Within the first six months, look for:

- earlier involvement in important decisions;
- faster decision turnaround;
- fewer unresolved cross-team dependencies;
- visible roadmap ownership;
- reuse of patterns or services;
- time-limited, governed exceptions;
- architecture changes informed by delivery evidence;
- stakeholder reports that architecture improved a decision.

## Definition of done for architecture work

An architecture engagement is done enough when:

- the intended outcomes and stakeholders are explicit;
- baseline knowledge is sufficient for the decisions;
- target choices and rationale are understood;
- requirements and material risks are owned;
- gaps and dependencies are connected to work;
- roadmap decisions are agreed by accountable people;
- conformance and change mechanisms exist;
- controlled content is stored and discoverable;
- learning and review triggers are scheduled.

[Next: Modern delivery](09-modern-delivery.html)