Scope: breadth, depth, time, and domains

Scope is not a neutral wrapper around architecture work. It changes the kind of answers the team can honestly produce. TOGAF treats scope as a deliberate design decision because the choices an organisation makes about what to include and exclude directly affect the quality and usefulness of every architecture output.

Think of it like a camera lens. A wide-angle lens captures a broad scene but loses detail in any one area. A telephoto lens captures fine detail in one area but cannot show the surroundings. Neither is inherently better. The right lens depends on what photograph you are trying to take. Scope works the same way.

A broad scope may help surface dependencies but can destroy delivery usefulness if it prevents the team from getting concrete. A narrow scope can sharpen decisions but may hide dependencies that later break the roadmap. The discipline is to choose consciously rather than pretending everything can be tackled at once.

TOGAF identifies four dimensions that together define the scope of an architecture effort. Each dimension involves trade-offs that the team must make consciously.

Breadth (enterprise scope). How much of the enterprise, value chain, or actor landscape is being considered. Breadth determines which organisational units, external interfaces, and enterprise functions fall inside the architecture cycle.

The trade-off: broad breadth surfaces cross-enterprise dependencies but risks spreading effort too thin. Narrow breadth enables depth but may miss dependencies that later break the design. The right breadth is determined by the decisions the architecture must support. If the business scenario from Module 11 involves actors across five departments and two external regulators, the breadth must encompass all of those actors. But it does not need to encompass departments that are merely interested observers.

Depth (level of detail). How detailed the architecture descriptions need to be to support the intended decisions. A board-level investment decision needs different depth from an integration-design decision.

The trade-off: greater depth produces more actionable outputs but costs more time and effort. Less depth is faster but may not be specific enough to guide the decisions the architecture was created to support. The architecture landscape concept in TOGAF recognises three levels of depth: strategic (high-level direction), segment (a portion of the enterprise), and capability (detailed enough to guide implementation). The first cycle does not need to reach capability depth everywhere. It needs to reach the depth that matches the decisions it must support.

Time (planning horizon). The period the architecture effort is trying to influence. A two-year horizon and a ten-year horizon produce very different target-state and transition-state outputs.

The trade-off: a long time horizon helps the organisation plan for fundamental shifts but can dilute the architecture's ability to guide near-term delivery. A short time horizon focuses on immediate decisions but may miss strategic dependencies. The right time horizon is usually long enough to show why transition states matter but short enough to shape current delivery choices. For most first cycles, two to five years is a practical range.

Domains (architecture domains). Which architecture domains and cross-cutting concerns are in play for this cycle. TOGAF defines four main architecture domains: business, data (or information systems), application, and technology. Not every cycle needs equal depth across all four.

The trade-off: covering all four domains ensures completeness but often means none of them reaches decision-grade depth in the first cycle. Prioritising two or three domains allows the team to produce genuinely useful outputs while acknowledging that the remaining domains will be addressed in later cycles. TOGAF explicitly supports this approach through iteration and partitioning.

One of the most important but least understood aspects of the ADM is that it is designed to be iterative. The Preliminary Phase and Phase A do not have to cover the entire enterprise in one pass. TOGAF explicitly supports two strategies for managing scope across multiple cycles:

Iteration means running the ADM cycle multiple times, with each iteration refining or deepening the architecture. The first cycle might produce a strategic overview. The second might deepen one domain. The third might address a specific capability area.

Partitioning means dividing the enterprise into segments and running separate ADM cycles for each segment, with a coordination mechanism to ensure the segments remain consistent. One team might work on business and data architecture while another works on technology architecture.

Both strategies are legitimate and both are common in practice. The key is that the first cycle's scope should be honest about what it will and will not cover, and later cycles should be planned rather than accidental.

Here is a practical method for making scope decisions that connect to real architecture value:

1. Name the live decisions the architecture effort must support. These should come directly from the business scenario (Module 11). If the scenario identifies connections responsiveness as the core problem, the scope must encompass the actors, systems, and data that shape connections decisions.
2. Choose the minimum depth required to support those decisions honestly. For a board investment decision, strategic depth may be sufficient. For an integration-design decision, you need capability-level depth showing specific data flows and interface contracts.
3. Expand breadth only where external actors or dependencies materially change the answer. If the regulator's requirements shape data architecture, the regulator is in scope. If a department is merely interested in the outcome, it can be noted as an observer without receiving equal architecture attention.
4. Set a time horizon that matches the decision cycle. If the organisation needs to make investment decisions in the next 12 months, a ten-year horizon will not help. If the organisation is planning a five-year transformation, a six-month horizon will miss the transitions.
5. Prioritise domains based on where the most pressing decisions sit. If the business scenario identifies data handoff failures as the root cause, data and application architecture should receive more depth in the first cycle than technology architecture.
6. Keep deferred areas visible and documented. Omission should be deliberate rather than accidental. The Statement of Architecture Work (Module 14) must name what is excluded and why.

Over-scoping is the more common failure. It looks like ambition but produces weakness:

• The architecture team promises to redesign the whole enterprise before producing any usable outputs.
• Every domain is declared critical, so none receives decision-grade depth.
• The time horizon is so wide that current obligations and near-term sequencing disappear.
• The artefact set grows, but decision confidence does not.
• Stakeholders initially support the broad scope (nobody objects to their area being included) but lose faith when the architecture cannot answer specific questions about their domain.

Under-scoping is less common but equally dangerous:

• The architecture covers one system or one process without acknowledging the enterprise context.
• Cross-cutting dependencies are missed because the scope does not extend to the actors that create them.
• The architecture looks internally complete but breaks when it meets external reality (regulation, partner interfaces, upstream data dependencies).
• The architecture team produces a solution design and calls it enterprise architecture.

The right scope sits between these extremes. It is tight enough to produce decision-grade outputs and broad enough to expose the dependencies that materially affect those decisions.

The business scenario from Module 11 identified connections responsiveness, data-publication discipline, and resilience evidence as the core problems. The scope dimensions for the first London Grid cycle should follow directly from those problems.

Breadth. The first cycle encompasses the planning, connections, operations, digital, cyber, telecoms, and regulatory functions that are directly involved in the connections process and data-publication discipline. It also includes the Ofgem and NESO interfaces that constrain data and process design. It does not attempt to cover every London Grid function. Commercial and retail functions that do not directly shape connections or data-publication decisions are noted as observers but do not receive full architecture attention.

Depth. The first cycle needs segment-level depth for business architecture (understanding the connections process and its handoff points) and capability-level depth for data architecture (understanding the specific data flows, quality gates, and authority boundaries that cause the current problems). Technology architecture receives strategic-level depth in the first cycle: enough to identify major platform constraints but not detailed enough to specify implementation choices.

Time. A three-year planning horizon. This is long enough to encompass the connections improvement targets and the data-publication reforms that Ofgem expects, but short enough to shape the delivery decisions that need to be made in the next 12 to 18 months. The three-year horizon also allows for one or two transition architectures between the current state and the target state.

Domains. The first cycle prioritises business architecture and data architecture because the business scenario identifies process handoffs and data-quality failures as the root causes of the connections problem. Application architecture receives moderate attention (understanding which systems are involved and where integration gaps exist). Technology architecture receives lighter attention in the first cycle, with a plan to deepen it in a subsequent cycle once the data and application requirements are clearer.

What is explicitly excluded from the first cycle:

• Long-term DSO transition architecture (deferred to a later cycle)
• Commercial and retail systems that do not directly affect connections or data publication
• Detailed technology platform selection (deferred until data and application requirements are clear)
• Smart meter data integration (noted as a future dependency but not in the first cycle's scope)

Notice how each scope choice can be traced back to the business scenario. The connections problem drives the breadth. The data-handoff failures drive the depth. The regulatory performance targets drive the time horizon. The root-cause analysis drives the domain priorities. That traceability is what separates a disciplined scope from an arbitrary one.