Stage 3 summary. Business Architecture

The objective of Phase B is to develop a target Business Architecture that describes how the enterprise needs to operate to achieve its business goals and respond to the strategic drivers set out in the Architecture Vision, in a way that addresses the Statement of Architecture Work and stakeholder concerns. The operative word is target. The phase's second objective follows from it, identifying candidate Architecture Roadmap components from the gaps between the Baseline and Target Business Architectures. The baseline is documented at the same level of abstraction as the target, and it exists to make the gap visible, not as an end in itself.

The work runs in a recognisable arc. Select reference models, viewpoints, and tools for the stakeholder concerns in hand, develop the baseline and target descriptions, perform gap analysis, define candidate roadmap components, resolve impacts across the Architecture Landscape, hold a formal stakeholder review, and finalise the results in the Architecture Definition Document that Phase C inherits. Business architecture itself is broader than any single artefact. It covers business models, capabilities, services, organisation relationships, value streams, measures, and gaps, which is why org charts and process maps are inputs, not the complete output.

The failure mode the module fixes is system-first architecture. Jumping to applications mistakes current tooling for the shape of the business problem, lets today's team structure dictate the target design, and hides service, accountability, and handoff failures behind solution language. The working test is blunt. If the architecture cannot say which 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.

The G18A Business Models guide describes a business model as the rationale of how an organisation creates, delivers, and captures value, and the definition is deliberately broad enough to cover commercial firms, public bodies, and regulated utilities. The stage unpacks it into four working components. The value proposition says what outcome is delivered and to whom. Value creation says how it is produced. Value delivery says how it reaches the stakeholder. Value capture says how the enterprise sustains itself, which for a network operator means allowed revenue under the RIIO price control rather than quarterly sales.

That last point is why the frame matters for architecture. A distribution network operator's model is shaped by licence conditions, legally binding service obligations, Long Term Development Statement publication duties, and a funding cycle set years in advance, and the transition from DNO to DSO with growing distributed energy resources is a business-model change, not a technology upgrade. Architecture that ignores these constraints proposes targets the enterprise cannot legally implement or finance.

Business-model work is not a capability map, not a process catalogue, not a solution brief, and not a one-off exercise. Its value shows in the framing test. Stated as replace the connections portal, the transformation is an application project. Stated as improve the enterprise's ability to deliver timely, transparent, evidence-backed connections outcomes within the regulatory framework, it is business architecture that every later choice can be traced back to.

The G206 Organisation Mapping guide, paired with the content metamodel's actor and role concepts, gives Phase B a lens the org chart cannot provide. An actor is an entity that participates in a business interaction. A role is a responsibility assigned to an actor in a specific context, so the same planning engineer is a technical approver in one interaction and a data contributor in another. The actor/role catalogue separates identity from responsibility, exposing role duplication, where ownership is contested, and role gaps, where ownership is absent.

The business interaction matrix then maps what flows between actors and reveals four kinds of insight. Dependency density predicts bottlenecks. Missing interactions explain where information is lost at handoffs. Asymmetric authority marks actors who carry an outcome without authority over its contributors. External interface risk marks boundary crossings to regulators, partners, and customers with unclear internal ownership. A useful map answers three questions a chart never will. Who owns the change outcome, where do handoffs fail, and where is authority blurred.

In the London case the map exposes three interface problems. Planning and design both claim the technical specification at their handoff, so neither owns it. Data governance holds responsibility for information quality with no authority over the systems that generate the data. And the Architecture Board reviews evidence on a fixed monthly cycle while delivery accountability sits with a programme director who cannot wait for it. The map is a diagnostic for the change effort, not a proposal to redraw management lines.

G211 Business Capabilities defines a capability as an ability the enterprise needs to possess and improve over time, named independently of the systems, teams, or processes that currently deliver it. The wording it aligns with, from the BIZBOK Guide, is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome. The stage also places competence between strategy and capability, the mechanism of related capabilities, knowledge, and skills that realises strategic intent, so each capability can be judged against the competence it serves rather than rated in the abstract.

Four negative tests keep the naming honest. If it sounds like a software product, a department, or a single task, it is not a capability, and the strongest test is replacement. A good name survives every system in the enterprise being swapped tomorrow. For assessment, G211 suggests heat mapping each capability by maturity, effectiveness, performance, and its value or cost contribution, and notes that a capability is realised through people, processes, information, and resources. The stage widens that into a seven-dimension lens, because why a capability scores poorly decides what kind of intervention to fund.

The London capability map spans a customer and connections domain, a network planning and operations domain, and an information and governance domain. Assessed across the dimensions, its weaknesses sit in information and data quality, governance and accountability, and process maturity. Technology support contributes but is not the primary weakness, which is exactly the insight that stops every capability gap being answered with a system replacement.

G233 Business Capability Planning builds on G211 and treats capabilities as the unit of analysis that frames the business need and ties change back to strategic intent. The stage runs it as a seven-step method. Establish an evidence-based baseline, set measurable targets aligned to strategic intent, identify multi-dimensional gaps, map dependencies between capabilities, prioritise, name the intervention type for each gap, and feed the results into Phase E and Phase F. Intervention types come in four broad categories, business change, governance change, information change, and technology change, and the planning step names which applies rather than defaulting to technology.

Three disciplines keep heatmaps honest. Every colour traces to evidence such as a service metric, audit finding, or incident pattern. Every high-priority capability connects to a planning or governance consequence. And the colours change over time or the assessment is stale. A map where everything is amber or red is a refusal to prioritise, and the right test of any heatmap is what changed because of it. Planning earns its keep in three places, roadmap priority, governance attention, and where the architecture team invests analytical depth in later phases.

Applied to London, the method puts network planning visibility first, then evidence-backed decision-making, then information publication, with customer connections management last. The ordering looks upside down until the dependency analysis explains it. The information and governance capabilities are blocking dependencies, and a faster connections platform built on fragmented planning data would still generate inaccurate offers.

G178 defines a value stream as a representation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end user. Each phrase carries weight. End-to-end means the whole journey from expressed need to realised outcome. Value-adding means administrative overhead shows up as friction, not as stages. Overall result means the stream must name its outcome. A value stream is not a simplified process map. A process map shows how work is done, a value stream shows where value is delayed, degraded, or made expensive, and the stream is the inside-out view whose outside-in complement is the customer journey.

A complete map records six elements, the triggering stakeholder, value stages, stage outputs, participating stakeholders, enabling capabilities, and pain points. A stream that has been drawn without them is a picture, not an analysis tool. The working rule keeps five to twelve stages, each recognisable to the triggering stakeholder, with a clear output and a significant handoff, readable by a non-specialist audience. The capability cross-reference runs both ways. A weak capability predicts a slow stage, and a bottleneck points to the capabilities that need attention, which is why G178 and G211 are designed to be used together.

The London connections stream runs eight stages, request, assess, study, decide, publish, connect, operate, and learn, triggered by the customer who submits the application. Its pain concentrates at three handoffs. Assess-to-study loses information between systems and adds twelve to fifteen working days, decide-to-publish introduces manual transcription errors, and connect-to-operate leaves as-built records incomplete. The portal the executives blamed accounted for less than fifteen per cent of the delay.

The content metamodel in Part 4 of the standard defines the relationships that hold business architecture together. Goals drive services, services require capabilities, and measures evaluate both. A business footprint renders those relationships on one page, with goals at the top, services in the middle, capabilities at the base, and measures alongside. Proximity is not connection. Four boxes near each other on a slide are a layout, and the footprint only exists once the relationships between them are explicit.

Measures are what make the difference between a descriptive architecture and an evaluable one, and three rules make them earn their place. They must be observable with obtainable data, they must connect to a goal, and they must be challenging enough that the architecture could fail against them. A target without measures is an assertion, not an architecture. The business service catalogue supplies the middle layer, and each entry carries a business-language name, a consumer, a purpose stated as an outcome, and a performance expectation.

The London footprint connects five goals to seven services with measures a board can hold the work to. Connection offers below 30 working days against a current average of roughly 65. LTDS publication accuracy at 98% against an estimated 85%. Planning data completeness at 95% against roughly 70%. Urgent governance decisions reviewed within five working days instead of waiting for a monthly board. Twelve months after implementation, the enterprise can check each one and say whether the architecture delivered.

The gap analysis technique in the ADM Techniques volume compares baseline and target to identify what is missing, what changes, and what can be reused, using a matrix in which each baseline element is retained, modified, replaced, or eliminated and each unmatched target element is new. A useful gap analysis goes further than the comparison. The stage runs five steps, identify the gaps across every Stage 3 view, classify them, attach a consequence to each, map the dependencies between them, and assign an intervention type from business change, governance change, information change, organisational change, or system change.

Five kinds of business gap carry the most architectural weight. Missing or underpowered capabilities, weak ownership or broken accountability, value-stage friction, misaligned goals, services, or measures, and business dependencies that are not governed. Every significant entry carries four attributes, why it matters, what consequence follows if it stays open, which dependencies are involved, and what intervention it points toward. That traceability runs both vertically, from strategy to operations, and horizontally across domains, which is what lets the log answer hard questions instead of listing differences.

The London gap log holds four gaps. Planning-data visibility is foundational, blocking publication quality and governance confidence. Accountability clarity is independent and can proceed in parallel, so those two open the first transition state and the other two follow. Three of the four need a non-technology intervention as the primary response, and the log feeds directly onward, giving Phase C its data authority justifications, Phase D its priorities, and Phases E and F their candidate work packages.

The walkthrough is a worked example, not a summary. It applies every Stage 3 method to the connections modernisation, beginning at the point where the programme had scheduled vendor demonstrations before anyone had identified which business capabilities needed to improve. The order matters. The business model frame anchors the effort in obligations and funding, the organisation view exposes the three interface problems, the capability and value-stream pair cross-reference ability against flow, the footprint synthesises goals, services, and measures into an evaluable argument, and the gap view closes with consequence, dependency, and sequencing.

A coherent pack has six connected elements, the business model frame, the organisation relationship view, the capability map with its assessment, the value stream with its pain points, the footprint with its measures, and the gap log with its change logic. The test of coherence is that each element refers to and reinforces the others. Capability weaknesses appear as value-stream bottlenecks, bottlenecks appear as gaps, gaps connect to services and goals, and the measures set the success criteria for the whole. If any element stands alone, the pack is a collection, not an architecture.

The hardest discipline is resisting application talk before the business layer is complete. Stay with service, ownership, handoff, and evidence problems. Ask whether each gap would survive a complete system replacement, and in London three of the four would, which proves the transformation is a business-architecture problem rather than a single-system one. Use capability language rather than product language, and test every proposal against the footprint measures.

Business architecture becomes theatre when outputs multiply but consequence does not, and it is dangerous precisely because it feels productive. Five warning signs recur. Capability maps with no planning or governance consequence, value streams with no bottleneck evidence or no downstream action, organisation maps that restate the org chart, gap logs that list differences without consequence or intervention, and endless workshops that widen the conversation but never sharpen it toward a decision-ready output.

The corrective is a four-question usefulness test applied to every artefact during production, not only in retrospect. Which decision does it improve. Which dependency, bottleneck, or governance issue does it expose. Who actually consumes it and for what action. And what would be lost if it did not exist. Three operational disciplines back the test up, decision linkage before production begins, consumer identification, and consequence tracking after the artefact has been in use, when the team should be able to point to at least one thing that changed because of it.

Retiring artefacts that serve no current decision is part of doing TOGAF well, not a betrayal of it, because the standard recommends many possible artefacts and requires none of them for every engagement. Quality is measured by consequence, not volume. Every artefact in the London pack passes the test because each was produced with a named decision, a named consumer, and a consequence in mind, and that is the bar to carry into every future engagement.

The connections modernisation arrived as a system project. The brief said deliver a modern digital connections platform, and vendor demonstrations were booked before any capability had been named. The stage reopens it properly. The business model frame sets the obligations and the funding envelope. The organisation map finds the contested specification handoff, the responsibility-without-authority data governance function, and the monthly board that urgent decisions wait on. The capability assessment rates planning visibility and information publication weakest. The eight-stage value stream shows the portal causing less than fifteen per cent of the delay while three handoffs cause most of it. The footprint ties five goals to seven services with measures, and the gap log closes with four gaps and a sequence.

Hold the shape of that result. Planning-data visibility is foundational and accountability clarity runs in parallel, so they open the first transition state, and three of the four gaps need a non-technology intervention first. The pack is also the terms of reference for everything that follows. Phase C inherits its data authority questions, Phase D its technology priorities, and Phases E and F their work packages, all traceable to a business layer that was made explicit before a single product was chosen.