Business footprints, goals, services, and measures

C220 Part 4 defines the content framework and content metamodel that structure all architecture content in TOGAF. The metamodel defines entities and their relationships. For the business layer, the relevant entities include goals, business services, capabilities, and measures. Understanding how these entities relate in the metamodel is what gives the footprint view its structural foundation.

The content metamodel is not advisory. It is definitional. If the architecture team ignores the relationships that the metamodel defines, the team's artefacts may look professional but they will not connect in the way that TOGAF intends. The footprint view is simply a practical rendering of relationships that the metamodel already requires.

Goals

Goals are defined as high-level statements of intent or direction for the enterprise. They represent the outcomes or conditions the enterprise is trying to achieve. In the metamodel, goals drive the selection and prioritisation of capabilities and services. A goal without connected services or capabilities is an aspiration floating in space. A goal with connected services and capabilities is a structured architecture input.

Goals in the business architecture are not the same as strategic objectives written on a corporate poster. They should be specific enough to drive architectural choices. "Become a leader in customer experience" is a strategic objective. "Reduce average connection elapsed time from 65 working days to 30 working days" is a goal that can drive architectural choices about which capabilities to strengthen, which services to redesign, and which measures to track.

Business services

Business services are defined as units of business functionality that the enterprise provides to its customers, partners, or internal actors. In the metamodel, services are delivered by capabilities and exist to fulfil goals. A service without a supporting capability is a promise without delivery. A service without a connected goal is activity without purpose.

Business services are distinct from technology services and application services. A technology service might be "cloud hosting". An application service might be "online application portal". A business service is "connection application processing". The business service describes what the enterprise provides to the stakeholder, not what technology delivers under the hood. This distinction matters because business services can outlive any particular technology implementation.

Capabilities

Capabilities sit beneath services and goals as the enabling layer. In the metamodel, capabilities are the enterprise abilities that make service delivery possible. The relationship is directional: goals require services, services require capabilities. If a service cannot name the capabilities it depends on, the service is not yet architecturally grounded.

The capability layer is where the footprint view connects to the work already done in Modules 19 and 20. The capability map and the capability assessment results feed directly into the footprint view. If a capability was assessed as weak in Module 19, that weakness should be visible in the footprint view as a constraint on the services and goals that depend on it.

Measures

Measures are the signals used to judge whether the architecture is achieving its intended outcomes. The metamodel treats measures as attributes of goals and services: each goal should have at least one associated measure, and each service should have performance measures that indicate whether it is being delivered effectively.

Measures are what make the difference between a descriptive architecture and an evaluable architecture. Without measures, the target business architecture is an assertion: "This is what the enterprise should become." With measures, the target becomes a testable claim: "This is what the enterprise should become, and here is how we will know if we got there."

A business-footprint style view places four elements in relationship. Each one plays a specific role, and the connections between them are what make the view useful. Producing the four elements separately and placing them side by side is not a footprint view. The value comes from the explicit connections.

Goals at the top. The outcomes or conditions the enterprise is trying to achieve or improve. In a regulated utility, these include service-performance targets, regulatory compliance conditions, resilience commitments, and customer-experience thresholds. Goals sit at the top of the footprint because they define what the enterprise is working toward. Every other element on the page should trace upward to at least one goal. If an element cannot trace to a goal, it is either misplaced or a goal is missing.

Services in the middle. What the enterprise provides to customers, users, partners, or internal actors in support of those goals. Services describe the external-facing delivery that the enterprise is accountable for. A business service catalogue lists these services with their purpose, consumers, and performance expectations. Each service should connect upward to at least one goal and downward to at least one capability.

Capabilities at the base. The enterprise abilities that must exist to deliver the services and support the goals. Capabilities sit beneath services in the footprint because they are the enabling layer. The connection from services to capabilities answers the question: what must the enterprise be able to do to deliver this service? If a service has no connected capability, it is a commitment with no identified means of delivery.

Measures alongside. The signals used to judge whether the business architecture is materially better than the baseline. Without measures, the footprint view is descriptive. With measures, it becomes a testable claim about improvement. Each goal should have at least one measure. Each service should have performance indicators. And the measures should be observable, connected to goals, and challenging enough to hold the architecture accountable.

Measures are often added too late, after the target picture is already socially accepted. That is risky because it becomes much harder to challenge a target business architecture once it has been drawn attractively and presented to the board. By the time someone asks "how will we know this is better?", the political cost of reopening the conversation is high.

Bringing measures closer to the business architecture makes the architecture more accountable. It also makes the architecture more useful to the governance bodies that must decide whether to fund the transformation. An Architecture Board reviewing a target that includes specific measures can make a more informed decision than a board reviewing a target that promises improvement without defining what improvement looks like.

Three practical rules help measures earn their place in the business architecture.

Rule 1: Measures should be observable

They should describe something that can actually be tracked with available or obtainable data. "Improved customer satisfaction" is too vague to be observable. "Average elapsed time from validated application to connection offer issued" is observable. "Better data quality" is vague. "Percentage of LTDS records passing defined quality criteria within each publication cycle" is observable. The discipline of making measures observable forces the architecture team to think concretely about what improvement actually means.

Rule 2: Measures should connect to goals

Each measure should trace to at least one goal in the footprint. Orphan measures are noise. If a measure cannot be connected to a goal, either the measure is irrelevant or a goal is missing from the footprint. This traceability also works in the other direction: a goal with no measure is untestable. The footprint view should make every goal-to-measure connection explicit so that reviewers can challenge the completeness of both.

Rule 3: Measures should challenge the architecture

A good measure makes it possible to say, twelve months later, whether the target architecture delivered what it promised. If all measures are easily achieved regardless of the architecture, they are not testing anything. A measure of "the connections system is operational" is not a challenge. A measure of "average connection elapsed time is below 30 working days for standard domestic connections" is a challenge that the architecture must actually deliver.

The architecture team should be willing to have measures that could fail. If every measure is designed to pass regardless of what the enterprise does, the measures are protective, not evaluative. Protective measures exist to make the architecture team look good. Evaluative measures exist to make the enterprise better.

The footprint view serves as a quality gate against four common fragmentation problems that appear when Stage 3 artefacts are produced independently.

Goals floating free from delivery. A goal that has no connected service or capability is an aspiration, not an architecture input. In a fragmented Stage 3 pack, the goals might sit in a strategy document, the capabilities in a separate model, and the services in a third view. Nobody checks whether the goal actually connects to something the enterprise can deliver. The footprint view forces the connection.

Capabilities discussed without outcome context. If a capability improvement cannot be traced to a goal, the investment case is weak. A team might argue for strengthening "network planning visibility" because the capability scored low on a maturity assessment. That argument is stronger when the footprint view shows that the capability supports the "connection application service" and the "network capacity information service", both of which connect to the goal of reducing connection elapsed time.

Services redesigned without success criteria. If a service redesign has no performance measure, the enterprise will not know whether the change was worth the investment. The footprint view requires every service to have at least one measure, preventing service changes that cannot be evaluated.

Stage 3 ending as a collection with no synthesis. This is the fragmentation problem from the opening story. Four individual artefacts that never combine into an argument for change leave the architecture unable to support governance decisions. The footprint view forces synthesis by requiring the team to show how goals, services, capabilities, and measures connect.

The business service catalogue is the central element of the footprint view. It lists the services that the enterprise provides to its stakeholders, with enough structure to connect each service to goals above and capabilities below.

Each entry in the catalogue should include four pieces of information.

1. Service name. A clear, business-language name that describes what the enterprise provides. "Connection application service" is a business service name. "CRM module 4.2" is a technology label.
2. Consumer. Who receives the service. This could be an external customer, a regulatory body, an internal team, or a partner organisation. Naming the consumer prevents services from being defined in the abstract.
3. Purpose. What the service achieves for the consumer. The purpose should be stated in terms of outcome, not activity. "Receive, assess, and respond to connection applications within regulatory timescales" is a purpose. "Process forms" is an activity.
4. Performance expectation. What good looks like for this service. This connects directly to the measures in the footprint view. If the service catalogue cannot state a performance expectation, the service is not yet defined clearly enough to be architecturally useful.

The catalogue is not an inventory of every activity the enterprise performs. It is a curated list of the services that matter for the architecture effort. A service that does not connect to a current goal or a current gap probably does not belong in the catalogue for this engagement.

In the London case, the footprint view places customer-facing service outcomes, planning responsibilities, external reporting duties, and resilience commitments on the same page, connected through goals, services, capabilities, and measures. This section walks through the London service catalogue and then shows how the footprint connects it to goals and measures.

London business service catalogue

The business service catalogue lists the services that London Grid Distribution provides to its stakeholders. Each service has a purpose, a consumer, and performance expectations.

1. Connection application service. Consumer: customers seeking new or modified connections. Purpose: receive, assess, and respond to connection applications within regulatory timescales. Performance expectation: average elapsed time from validated application to offer issued. Enabling capabilities: customer connections management, network planning visibility.

2. Network capacity information service. Consumer: local planning authorities, developers, generators. Purpose: provide accurate, accessible information about available network capacity for planning decisions. Performance expectation: data accuracy and publication timeliness against regulatory requirements. Enabling capabilities: network planning visibility, information publication.

3. LTDS publication service. Consumer: Ofgem, industry, public. Purpose: publish accurate Long Term Development Statement data as required by licence conditions. Performance expectation: percentage of records passing defined quality criteria within each publication cycle. Enabling capabilities: information publication, data quality management.

4. Connection delivery service. Consumer: customers with accepted connection offers. Purpose: deliver physical connection works safely, on time, and to specification. Performance expectation: percentage of connections delivered within agreed timescales. Enabling capabilities: connection design coordination, operational resilience governance.

5. Network operation service. Consumer: all connected customers. Purpose: maintain safe, reliable electricity distribution across the licence area. Performance expectation: network reliability metrics and incident response times. Enabling capabilities: operational resilience governance, SCADA operations, data quality management.

6. Regulatory reporting service. Consumer: Ofgem, NESO. Purpose: provide accurate, timely performance and compliance data to regulatory bodies. Performance expectation: reporting accuracy and submission timeliness. Enabling capabilities: data quality management, information publication.

7. Governance and assurance service. Consumer: internal leadership, Architecture Board. Purpose: provide evidence-based governance reviews for architecture and programme decisions. Performance expectation: review cycle time and evidence traceability. Enabling capabilities: evidence-backed decision-making, governance capability.

London goals

The London footprint connects the service catalogue to five architecture-driving goals.

1. Reduce average connection elapsed time to below 30 working days for standard domestic connections. Connected services: connection application service, connection delivery service.
2. Achieve 98% LTDS publication accuracy against defined quality criteria within each publication cycle. Connected services: LTDS publication service, network capacity information service.
3. Establish 95% planning data completeness for asset records in the integrated planning view. Connected services: network capacity information service, regulatory reporting service.
4. Reduce governance review cycle time so that urgent decisions are reviewed within 5 working days rather than waiting for the next monthly board meeting. Connected services: governance and assurance service.
5. Achieve traceable incident response with all critical incidents assessed and escalated within defined timescales, with evidence in the governance record. Connected services: network operation service, governance and assurance service.

London-specific measures

Each goal in the footprint view connects to specific, observable measures that satisfy the three rules from Section 22.3.

• Average connection elapsed time (from validated application to energisation). Target: below 30 working days for standard domestic connections. Observable: yes, measured from system timestamps. Challenging: the current average is approximately 65 working days.
• LTDS publication accuracy rate. Target: 98% data accuracy against defined quality criteria within each publication cycle. Observable: yes, measured by automated quality checks. Challenging: the current accuracy rate is estimated at 85%.
• Planning data completeness score. Target: 95% of asset records complete and current in the integrated planning view. Observable: yes, measured by record completeness audit. Challenging: the current completeness is estimated at 70%.
• Governance review cycle time. Target: urgent decisions reviewed within 5 working days. Observable: yes, measured from request-to-decision timestamps. Challenging: the current cycle is fixed at monthly regardless of urgency.
• Resilience incident response capability rating. Target: all critical incidents assessed and escalated within defined timescales, with traceable evidence in the governance record. Observable: yes, measured by incident-log audit. Challenging: the current evidence trail is incomplete for approximately 40% of incidents.

These measures make the London footprint view evaluable. Twelve months after the target business architecture is implemented, the enterprise can check each measure and determine whether the architecture delivered what it promised. If the measures are not met, the architecture team has a structured basis for investigating which capabilities, services, or governance arrangements fell short.