Phase B and the point of business architecture

Phase B is where the enterprise stops speaking only in terms of aspiration and starts describing how value is created, which abilities matter, which services exist, who is accountable, and where the current business arrangement is failing. It sits inside the Architecture Development Method immediately after Phase A: Architecture Vision, which secured stakeholder buy-in and set the scope.

That does not mean Phase B is a purely strategic essay. It is architecture work. The point is to make the business layer explicit enough that later data, application, and technology decisions can be tested against something real. When Phase B is weak, Phases C and D lose their anchor and optimise around current systems rather than around the capabilities and outcomes the enterprise actually needs.

C220 Part 2 lists several objectives for Phase B. Each one matters because it prevents a specific failure mode. Here is the complete set, with a plain-English explanation of why each one exists.

1. Develop the target Business Architecture, describing how the enterprise needs to operate to achieve business goals and respond to the strategic drivers set out in the Architecture Vision. This is the primary objective. Everything else in Phase B serves it. If the team finishes Phase B without a clear target business architecture, the phase has not been completed.

2. Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures. Phase B does not just describe. It also identifies what needs to change. The gap analysis between baseline and target produces the first set of roadmap candidates, which are refined in later phases.

3. Select relevant viewpoints for the architecture to address key stakeholder concerns. Different stakeholders need to see different things. A board member needs a capability view. An operations manager needs a service and handoff view. A regulator needs a compliance and governance view. Phase B must choose the right viewpoints to address the concerns that matter.

4. Select the tools and techniques to be used for business architecture modelling. This is a practical objective. The team decides whether it will use capability mapping, value streams, organisation mapping, business scenarios, or a combination.

Phase B does not start from nothing. It receives a set of inputs from earlier work, and each input shapes what the team can do. C220 Part 2 lists the following inputs to Phase B. Understanding what each one provides helps explain why Phase B can go wrong when inputs are missing.

External reference materials. Industry frameworks, regulatory requirements, market analysis, and comparable architecture patterns from the Enterprise Continuum. For London Grid, this includes Ofgem regulatory guidance, connections reform expectations from NESO, the ED3 framework decision, and cyber resilience frameworks from the National Cyber Security Centre.

Request for Architecture Work (from the Preliminary Phase or from a governance trigger). The Request for Architecture Work defines why the architecture effort exists and what business problem it is responding to. If this input is vague, the team will struggle to scope Phase B.

Architecture Vision and Statement of Architecture Work (from Phase A). The Statement of Architecture Work defined the scope, approach, schedule, and governance for the engagement. The Architecture Vision confirmed stakeholder buy-in and the high-level direction. Phase B inherits both.

Architecture Principles (from the Preliminary Phase). The principles set out the rules that guide all architecture decisions. For London Grid, principles such as "data is a shared enterprise asset" and "buy before build" directly constrain Phase B choices.

Enterprise Continuum and Architecture Repository contents. Existing architecture repository material, reusable patterns, and any previous baseline architecture descriptions. If the organisation has done architecture work before, Phase B should build on it rather than starting from scratch.

Relevant capability assessments, business plans, and strategy documents. These are the business-side inputs. Strategy documents, business cases, capability assessments, and performance data all feed Phase B. If these inputs are missing, the team will need to gather them as part of the Phase B work.

Outputs from Requirements Management. Requirements Management sits at the centre of the ADM. It feeds architecture requirements into every phase. Phase B receives requirements that are relevant to the business layer.

C220 Part 2 describes a series of steps for Phase B. These are not a rigid sequence that must be followed in exact order, but they represent the logical progression of the work. Each step has a clear purpose.

Step 1: Select reference models, viewpoints, and tools. Before drawing anything, the team chooses which modelling approaches will serve the stakeholder concerns. For a connections modernisation, a capability map, a value stream, and an organisation relationship view are more useful than a detailed process catalogue. The choice of viewpoints determines what the Phase B artefacts will look like.

Step 2: Develop the Baseline Business Architecture Description. The team documents the current state of the business. This is not a pure documentation exercise. The purpose of the baseline is to make the starting point visible so that gaps can be identified. A baseline that is too detailed wastes time. A baseline that is too shallow misses the real problems. The discipline is to describe the baseline at the same level of abstraction as the target.

Step 3: Develop the Target Business Architecture Description. This is the core of Phase B. The target describes what the business needs to become. It should include the capabilities the enterprise must possess, the services it must deliver, the accountability structures that must be in place, and the value flows that must work. The target is not a wish list. It is a structured description of the required future state.

Step 4: Perform gap analysis. The team compares baseline and target to identify what is missing, what changes, and what can be reused. Gap analysis at the business layer is not just about comparing two diagrams side by side. It is about understanding why the differences matter, what consequences follow if they are not addressed, and what kind of intervention each gap requires.

Step 5: Define candidate roadmap components. The gaps identified in Step 4 produce candidate roadmap components. These are not final work packages. They are early signals of the changes that later phases will refine into a sequenced roadmap.

Step 6: Resolve impacts across the Architecture Landscape. Phase B outputs must be checked against the wider Architecture Landscape. Changes in the business layer may have implications for other segments or for strategic architecture that the team has not yet considered.

Step 7: Conduct formal stakeholder review. The business architecture is reviewed with stakeholders to confirm that it addresses their concerns, that the target is achievable, and that the gap analysis is credible. This review is a governance checkpoint, not a presentation. If stakeholders cannot challenge the target, the review is theatrical.

Step 8: Finalise the Business Architecture. The team incorporates feedback from the stakeholder review and produces the finalised business architecture deliverables. These become the primary input to Phase C.

Step 9: Create the Architecture Definition Document. The Architecture Definition Document captures the baseline and target business architectures, the gap analysis, and the candidate roadmap components. It is the formal output that later phases inherit.

C220 Part 2 lists the following outputs from Phase B. Each output serves a specific downstream purpose.

Refined and updated Statement of Architecture Work. Phase B may have revealed scope changes or new constraints that require updating the original statement.

Validated architecture principles (business-specific). If the principles established in the Preliminary Phase need refinement based on what Phase B revealed, the updated principles are an output.

Draft Architecture Definition Document, including baseline and target business architecture views. This is the core output. It contains the capability views, value-stream views, organisation views, service views, and gap analysis that define the business layer.

Draft Architecture Requirements Specification (business-level). The architecture requirements that Phase B has identified, ready to feed into Requirements Management and into Phase C.

Business Architecture components of the Architecture Roadmap. The candidate roadmap components from Step 5, now confirmed and ready for refinement in Phase E and Phase F.

Impact analysis. How the business architecture changes affect other parts of the Architecture Landscape, including any implications for segment architectures or existing transition states.

Business architecture is broader than any single artefact. It covers at least four distinct areas, and each one matters for different reasons. Understanding what belongs inside business architecture prevents the team from treating a single view (often a process map) as if it were the complete output.

Business model and value logic. Why the enterprise exists, who it serves, what obligations it carries, and what outcomes justify change. This is the strategic anchor that prevents business architecture from becoming an internal efficiency exercise. TOGAF supports this through the G203 Business Architecture Guide and G18A Business Models guide.

Capabilities and services. What the enterprise must be able to do and which services it provides to deliver value or meet obligations. Capabilities are stable enterprise abilities; services describe what the enterprise delivers to customers, partners, or internal actors. TOGAF supports this through G211 Business Capabilities and G178 Value Streams.

Organisation and accountability. Which actors, functions, and governance relationships shape the business outcome. This is not a restatement of the org chart. It is a view of responsibility, ownership, and decision interfaces that matter to the change effort. TOGAF supports this through G206 Organisation Mapping.

Measures and business gaps. How the enterprise judges success and where the current business arrangement is not good enough. Without measures, the target business architecture becomes decoration. Without gaps, the stage has no bridge to later work. TOGAF supports this through the gap analysis techniques in C220 Part 3 and the content metamodel in Part 4.

One of the most common failure modes in enterprise transformation is jumping to systems before the business layer is explicit. That instinct feels productive, but it creates several serious problems that compound in later phases.

• It mistakes current tooling for the shape of the business problem. The enterprise sees its world through the lens of existing applications rather than through the lens of required capabilities.
• It lets current team structure dictate the target business design. If the only organisation view is the HR org chart, the target architecture will mirror the current silos.
• It hides service, accountability, and handoff failures behind solution language. A statement like "we need a new CRM" sounds concrete but says nothing about which service outcomes need to improve or which accountability gaps need closing.
• It makes later roadmap choices feel technical when the real gaps are often business-led. If the gap log only contains system replacement entries, the planning work will sequence technology changes rather than business improvements.

The test is straightforward: if the architecture cannot explain what business abilities need to improve before the first application diagram appears, the business layer is still too weak to guide the rest of the work.

Phase B is not a standalone exercise. It is the foundation layer that every later stage inherits from. When the business architecture is strong, later phases can make sharper decisions because they have a clear business context to test against.

1. Data architecture can ask which information authorities matter because the business layer has already defined the services and capabilities that depend on them.
2. Application architecture can draw boundaries based on business capability ownership rather than current system accidents.
3. Technology architecture can prioritise infrastructure that supports the business outcomes under most pressure.
4. Migration planning can sequence work packages around business priority rather than technical convenience.

When Phase B is weak, those later phases lose their anchor. Systems look more important than they should, and architecture becomes a series of local optimisations that never reconnect to enterprise purpose.

In London Grid Distribution, the business problem is not a portal refresh. It is an enterprise change problem touching customer responsiveness, planning coherence, operational handoffs, information publication, resilience, and governance. Phase B is where that full scope becomes explicit.

Consider what each Phase B step means for the London case.

Selecting viewpoints (Step 1). The London team needs capability views (to identify which enterprise abilities need to improve), value-stream views (to show where connections outcomes get stuck), organisation views (to expose accountability gaps at handoff points), and a business-footprint view (to connect goals, services, and measures). A process-only viewpoint would miss most of the enterprise questions.

Documenting the baseline (Step 2). The current London connections process is paper-heavy, with information scattered across multiple systems. The GIS holds some asset data. The DMS holds some operational data. The connections team uses a separate workflow tool. Planning data is held in spreadsheets. The baseline is fragmented, and the baseline architecture should make that fragmentation visible.

Developing the target (Step 3). The target business architecture describes an enterprise that can deliver timely, transparent, evidence-backed connections outcomes. That means improved capabilities in planning visibility, information publication, and evidence-backed decision-making. It means clearer accountability at the handoff points where work crosses teams. And it means services that are measurable against regulatory expectations.

Performing gap analysis (Step 4). The London gaps include planning-data visibility (fragmented across systems), accountability clarity (contested ownership at handoff points), publication quality (cannot meet LTDS accuracy requirements), and governance confidence (periodic manual review instead of continuous evidence).

Defining roadmap candidates (Step 5). The gaps produce candidate roadmap components: a planning data integration initiative, an accountability and governance redesign, an information publication capability uplift, and supporting technology changes. Notice that only the last of these is a technology initiative. The others are business and governance changes that technology will enable but not replace.

The London case shows why Phase B cannot be optional. If the architecture team jumps straight to application design, the connections problem gets reduced to a queue-management conversation. The real enterprise questions about planning visibility, evidence quality, and governance confidence never get asked.