Architecture Scoping

TL;DR

Scoping defines the boundaries of an architecture effort. In TOGAF, scope is set across four dimensions: breadth, depth, time period, and Architecture Domains.

Why scoping matters

If scope is unclear, architecture work becomes too broad, too detailed, or disconnected from business goals.

Scoping helps answer:

• what part of the enterprise is included
• how detailed the work should be
• which architecture domains are required
• what time horizon the architecture covers

Where scoping happens in TOGAF ADM

Scoping appears at two levels in TOGAF:

• Preliminary Phase: sets the scope of the enterprise architecture capability (mandate, governance, principles, and authority).
• Phase A (Architecture Vision): sets scope for a specific architecture engagement.

This distinction helps avoid confusion between organization-level EA setup and project-level architecture work.

The 4 scoping dimensions

1. Breadth (enterprise scope)

Breadth defines how much of the enterprise is in scope.

Examples:

• one business process
• one department or business unit
• multiple business units
• the full enterprise

Question to ask: Which organizations, teams, or processes are included in this architecture effort?

2. Depth (level of detail)

Depth defines how detailed the architecture description should be.

Examples:

• high-level conceptual model for decision alignment
• logical-level model for solution shaping
• detailed design-level model for implementation planning

Question to ask: What is the minimum level of detail needed to solve this problem well?

3. Architecture Domains

This dimension defines which core TOGAF domains are in scope:

• Business
• Data
• Application
• Technology

You do not always need all four at the same level of detail.
For some initiatives, Business + Data + Application may be enough. For others, Technology detail is critical.

Question to ask: Which domains are necessary to meet the objective and reduce risk?

4. Time period

Time period defines the planning horizon for the architecture vision and target state.

Examples:

• near-term (6-12 months)
• medium-term (1-2 years)
• longer horizon (3+ years, usually with staged transitions)

Question to ask: Is this time horizon realistic for available budget, people, and authority?

Stakeholders and concerns drive scope

Stakeholder concerns are not only constraints; they are core inputs to scope definition.

Examples:

• executives may need strategic coverage and investment view
• delivery teams may need implementation-level depth
• risk/compliance may require explicit security and control viewpoints

In practice, stakeholders and concerns directly influence breadth, depth, time period, and Architecture Domains.

Practical scoping approach

TOGAF does not mandate one fixed order. A common starting pattern is:

1. Breadth: what part of the enterprise
2. Depth: how detailed
3. Time period: what horizon
4. Architecture Domains: what viewpoints are needed

Teams usually iterate between these dimensions rather than deciding them once in a strict sequence.

Scoping output: Statement of Architecture Work

In Phase A, agreed scope is formally captured in the Statement of Architecture Work.

It typically records:

• scope and boundaries
• objectives and expected outcomes
• constraints and assumptions
• approach and governance expectations

What usually limits scope

Architecture scope is often constrained by:

• people and skills
• budget and funding cycle
• business objectives and deadlines
• Architecture Principles
• stakeholder concerns and decision speed
• governance authority of the architecture team

Practical example

A bank wants to modernize its payments platform.

• Breadth: retail payments only (not all banking products)
• Depth: logical-level architecture for platform selection and integration planning
• Time period: 18-month target with two transition steps
• Architecture Domains: Business + Data + Application + Technology (all four needed due to regulatory and reliability constraints)

This keeps scope realistic while still covering what is needed for decision-making and delivery planning.

Exam note

• Scope must be explicit before architecture development starts.
• TOGAF scoping uses four dimensions: breadth, depth, Architecture Domains, and time period.
• Scope is shaped in Preliminary Phase (EA capability scope) and Phase A (engagement scope).
• Scope can be narrow (single initiative) or broad (enterprise-wide).
• Good scoping balances ambition with feasibility.

Sources

• The Open Group - TOGAF Standard