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.

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:

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