# Architecture Techniques

TOGAF offers and accommodates techniques that help practitioners reason about
scope, stakeholders, requirements, risk, trade-offs, and migration. Select only
those that support the engagement.

## Stakeholder analysis

Identify stakeholders, their concerns, influence, attitude, decision rights, and
communication needs.

| Stakeholder | Concern | Influence | Needed involvement |
|---|---|---:|---|
| Sponsor | Outcome, cost, timing | High | Decisions and escalation |
| Operations | Reliability, supportability | Medium–High | Target and acceptance |
| Delivery teams | Feasibility, autonomy | Medium | Continuous collaboration |
| Risk owner | Exposure and controls | High | Requirement and exception approval |
| Users/customers | Usability and value | Variable | Research and validation |

Do not treat the matrix as a substitute for engagement.

## Business scenarios

A business scenario makes a problem concrete by describing:

- the business problem and environment;
- desired outcomes;
- human and system actors;
- roles and responsibilities;
- processes and interactions;
- measures of success;
- constraints and resulting requirements.

Use scenarios to discover requirements and test whether architecture choices
solve a real problem.

## Capability-based planning

Capabilities describe what the enterprise must be able to do, independent of a
particular organization chart or system.

Steps:

1. define business outcomes;
2. identify enabling capabilities;
3. assess current and target maturity or performance;
4. heat-map gaps and strategic importance;
5. identify increments and dependencies;
6. connect investments to capability improvements;
7. measure realized outcomes.

Capability maps should be stable enough to organize planning but not treated as
timeless truth.

## Value-stream mapping

A value stream describes the stages through which value is created for a
stakeholder. Map each stage to:

- triggering need;
- value proposition and outcome;
- participating capabilities;
- information;
- measures and pain points;
- supporting applications and technology.

Value streams expose cross-silo problems that capability maps alone may hide.

## Gap analysis

Compare baseline and target elements:

| Baseline vs target | Interpretation |
|---|---|
| Present in both, unchanged | Retain |
| Present in both, materially changed | Improve or transform |
| Baseline only | Retire or replace |
| Target only | Introduce |

Record impact, dependencies, requirement links, and likely work package. Include
non-technical gaps such as policy, skill, ownership, process, and data quality.

## Interoperability analysis

Assess the ability of people, processes, information, and technology to work
together:

- organizational and legal;
- semantic;
- process and service;
- application and interface;
- technical and protocol;
- security and trust.

Technical connectivity does not guarantee shared meaning or operating agreement.

## Business Transformation Readiness Assessment

Assess factors that may enable or block change:

- sponsor strength;
- shared vision;
- organizational capacity;
- funding and incentives;
- skills;
- cultural willingness;
- governance;
- technology and data readiness;
- delivery track record.

Convert findings into actions, owners, and roadmap constraints.

## Risk management

Integrate risk throughout the ADM:

1. identify threat or uncertainty;
2. describe affected objective or asset;
3. estimate likelihood and impact;
4. identify existing controls;
5. choose treatment: avoid, reduce, transfer, or accept;
6. assign owner and due date;
7. monitor residual risk and triggers.

Separate **architecture risk** from **project delivery risk**, while showing
their relationships.

## Migration planning techniques

### Dependency analysis

Identify which work packages enable, constrain, or conflict with others. Look
for data migration, policy, procurement, platform, skill, and organizational
dependencies—not only software dependencies.

### Transition architectures

Define intermediate states when the target cannot be reached in one step. A
transition state should deliver value or reduce risk while remaining coherent.

### Prioritization

Candidate factors:

- strategic alignment;
- outcome value;
- urgency or regulatory deadline;
- risk reduction;
- dependency enablement;
- cost and capacity;
- time to value;
- reversibility and learning.

Make scores explainable and subject them to scenario and sensitivity analysis.

## Trade-off analysis

For consequential decisions:

1. state the decision and deadline;
2. identify stakeholder concerns;
3. define criteria and constraints;
4. generate credible options, including status quo;
5. evaluate evidence and uncertainty;
6. decide with rationale;
7. record consequences and revisit triggers.

Avoid fake precision. A weighted score can structure discussion, but it cannot
remove judgment.

## Architecture principles

Evaluate a candidate principle by asking:

- Is it durable and enterprise-relevant?
- Does it resolve recurring trade-offs?
- Can people understand how it changes behavior?
- Are implications and costs honest?
- Can conformance or exception be assessed?

Example:

> **Data has accountable ownership.** Every critical data domain has a named
> business owner responsible for meaning, permitted use, quality expectations,
> and lifecycle decisions.

## Scenario planning

When the future is uncertain, test the target and roadmap against several
plausible conditions—for example rapid growth, regulation, constrained capital,
supplier exit, or a major incident. Prefer choices robust across scenarios and
mark contingent decisions with explicit triggers.

## Architecture Decision Records

An ADR captures:

- context and decision;
- status and date;
- options considered;
- rationale;
- consequences;
- affected assets and requirements;
- owner and review trigger.

ADRs complement models by preserving why a choice was made.

## Technique selection

Use a technique when it reduces uncertainty or improves a decision. Stop when
additional analysis costs more than the insight it provides.

[Next: Practical adoption](08-practical-adoption.html)