Business models in TOGAF practice

TOGAF does not prescribe a single business-model canvas or template. Instead, it treats business-model thinking as a framing activity that belongs early in Phase B and connects the Architecture Vision to the detailed business-architecture work that follows.

Two TOGAF publications provide the primary guidance. The G203 Business Architecture Guide describes how business architecture fits within the ADM and why understanding the enterprise's operating logic is essential before capability and process modelling begins. The G18A Business Models guide provides more specific guidance on how to capture and use business-model information in architecture work.

G18A describes a business model as a structured description of how an enterprise creates, delivers, and captures value. That description is deliberately broad enough to cover commercial enterprises, regulated utilities, public-sector bodies, and hybrid organisations.

G203 adds that business architecture should provide a structured view of the enterprise from a business perspective. That structured view begins with the business model because the model defines the context in which capabilities, services, and value flows make sense. A capability map produced without a business-model anchor risks becoming a taxonomy exercise disconnected from the enterprise's actual purpose.

G18A and the broader business-model literature identify four components that together describe the enterprise's operating logic. Each component answers a different question, and each one matters for architecture work.

Value proposition

What outcome or value does the enterprise deliver, and to whom? For a commercial enterprise, this is the product or service that customers pay for. For a regulated utility, it is the safe, reliable, affordable delivery of an essential service under licence conditions. For a public body, it may be a public good that nobody directly purchases but that society depends on.

The value proposition is the starting point for architecture framing because it defines what the enterprise is fundamentally trying to achieve. If the architecture team cannot state the value proposition clearly, every subsequent design choice lacks a reference point.

Value creation

How does the enterprise produce the value it promises? This includes the capabilities, resources, partnerships, and activities that make the value proposition possible. For a DNO, value creation involves network planning, asset management, fault response, connections delivery, and data management. For a digital platform, it involves software development, data analytics, and user-experience design.

Value creation is where business-model thinking connects most directly to capability work. The capabilities the enterprise needs are determined by its value-creation logic, not by its current application portfolio.

Value delivery

How does value reach the stakeholder? This covers channels, customer relationships, service interactions, and the mechanisms through which the enterprise fulfils its promises. For a DNO, value delivery includes the physical electricity network, customer service interactions, regulatory reporting, data publication, and community engagement.

Value delivery is where business-model thinking connects to value-stream analysis. The value stream traces the journey from the stakeholder's need to the outcome they receive, and value delivery describes the mechanisms that make that journey work.

Value capture

How does the enterprise sustain itself? For a commercial enterprise, this is revenue and profit. For a regulated utility, it is the allowed revenue determined by the price control mechanism, supplemented by incentive income for performance and innovation. For a public body, it may be government funding, grants, or levies.

Value capture matters for architecture because it determines the funding model for change. An enterprise funded through a five-year price control cycle has different investment constraints from one funded through quarterly revenue. Architecture that ignores the funding model will propose changes that the enterprise cannot finance.

Before the architecture work begins restructuring capabilities, redrawing processes, or selecting platforms, six questions deserve answers. These questions translate the four business-model components into practical architecture inputs.

1. What outcome or public value is the enterprise fundamentally trying to deliver? For a regulated utility, this is not about profit maximisation. It is about safe, reliable, affordable service with increasingly transparent information publication. The answer to this question becomes the value-proposition anchor for all later architecture work.

2. Who experiences the value, the cost, or the risk when the current model performs badly? Customers waiting months for a connection. Local authorities unable to plan infrastructure. The regulator assessing compliance. Internal teams whose operational effectiveness depends on accurate planning data. Each of these stakeholders has different concerns, and the business model must account for all of them.

3. Which regulatory or institutional duties shape the operating logic? Licence obligations, price control mechanisms, safety standards, data-publication requirements, and network-access rules all constrain the design space in ways that a pure commercial model would not. Architecture that ignores these constraints will propose solutions the enterprise cannot legally implement.

4. How is the enterprise funded, and what does that mean for investment timing? A DNO funded through a five-year price control (RIIO) has investment commitments determined years in advance. Changes proposed by the architecture must fit within that funding envelope or be justified through uncertainty mechanisms or reopener provisions.

5. Which enabling capabilities or information assets are becoming more important than they used to be? Data quality, planning transparency, and digital service responsiveness are shifting from secondary concerns to primary obligations. The business model is evolving, and the architecture must reflect that evolution.

6. What partnerships, dependencies, or external relationships shape how value is created and delivered? A DNO depends on independent connection providers, metering agents, the DSO transition programme, and the system operator. Architecture that treats the enterprise as a closed system will miss critical integration and coordination needs.

Business-model thinking is valuable precisely because it is not the same thing as the modelling that comes later. Confusing it with other Phase B activities weakens both.

Not a capability map. Capabilities describe what the enterprise must be able to do. The business model explains why those abilities matter. A capability map without a business-model anchor risks becoming a taxonomy exercise. G211 Business Capabilities explicitly recommends understanding the enterprise context before defining capabilities.

Not a process catalogue. Processes describe flow and execution detail. The business model describes the enterprise logic beneath them. Jumping straight to process without understanding the value logic produces optimisation of the wrong thing.

Not a solution brief. A business model should help frame architecture choices before any platform or application is privileged. If the business-model conversation ends with a vendor name, it has collapsed into procurement.

Not a one-off exercise. The business model evolves as the enterprise's operating context changes. The transition from DNO to DSO, for example, is a fundamental business-model change that will reshape capabilities, services, information needs, and governance structures over a decade or more. Architecture teams need to revisit the business model periodically, not treat it as a document produced once and filed.

A DNO business model does not look like a Silicon Valley startup pitch. It is shaped by licence conditions, price control mechanisms, safety obligations, and the physical reality of an electricity network that was built over a century. Understanding this model is essential for anyone doing architecture work in the energy sector.

Value proposition

The DNO delivers safe, reliable, and affordable electricity distribution to homes and businesses within its licence area. It connects new customers and generators to the network. It publishes network data for planning purposes through the Long Term Development Statement. It maintains and operates the physical infrastructure. And increasingly, it manages two-way power flows as distributed energy resources like solar panels and batteries connect to the network.

Value creation

The DNO creates value through several interrelated capabilities. Network planning ensures the infrastructure can meet current and future demand. Asset management keeps equipment operational and safe. Connections management processes new connection requests from application through to energisation. Data management ensures that network models, asset records, and planning data are accurate. Operational control, through SCADA and the distribution management system, monitors the network in real time and responds to faults.

Value delivery

Value reaches stakeholders through several channels. Customers interact through connection application portals, customer service teams, and increasingly through digital self-service interfaces. The regulator (Ofgem) receives performance data, compliance reports, and business plan submissions. Local planning authorities receive network capacity information. The system operator (NESO) receives operational data for system balancing. And the general public receives published network data through the LTDS and other transparency mechanisms.

Value capture

The DNO is funded through the RIIO price control mechanism set by Ofgem. Allowed revenue is determined for a multi-year period (currently transitioning from ED2 to ED3) based on the DNO's business plan, efficiency performance, and incentive outcomes. Additional income comes from connection charges (for new connections that require reinforcement), innovation funding, and incentive payments for exceeding performance targets. This funding model means that major investment decisions are made years in advance and must be justified within the regulatory framework.

The DNO business model constrains the architecture design space in specific ways that a general-purpose commercial model would not.

Investment timing is externally determined. The price control cycle means the enterprise cannot simply decide to invest when it wants to. Major technology programmes must be justified within the regulatory business plan or funded through uncertainty mechanisms. Architecture that proposes a three-year transformation starting immediately may conflict with a price control period that has already allocated its funding.

Service obligations are legally binding. Connections timescales, data publication requirements, and network reliability standards are not aspirational targets. They are licence conditions with regulatory consequences for failure. Architecture that treats these as optional risks proposing a target state that is non-compliant.

Information is becoming a primary operating asset. The transition to DSO and the growth of distributed energy resources mean that the DNO's business model increasingly depends on information quality. Network planning, flexibility procurement, and regulatory reporting all require accurate, timely data. Architecture work that treats data as secondary to applications misunderstands the evolving business model.

The operating model is changing fundamentally. The transition from passive DNO (electricity flows one way, from grid to customer) to active DSO (electricity flows both ways, and the operator must balance local supply and demand) is a business-model transformation, not merely a technology upgrade. Architecture that does not account for this transition will produce a target state that is already obsolete.

Consider the difference between framing a transformation as "replace the connections portal" versus framing it as "improve the enterprise's ability to deliver timely, transparent, evidence-backed connections outcomes under regulatory scrutiny, within the ED3 funding envelope, as the business model evolves toward DSO." The first framing leads to an application project. The second leads to business architecture work that touches capabilities, accountability, information quality, governance, and funding alignment.

The London Grid business model combines all the elements described above. Applying the six framing questions from Section 17.3 produces a clear business-model anchor for the connections modernisation.

Outcome and public value. London Grid exists to deliver safe, reliable electricity distribution across Greater London. The connections modernisation must improve the enterprise's ability to connect new demand and generation in a timely, transparent, and evidence-backed manner.

Who experiences the value or the failure. Customers waiting for connections. Local planning authorities coordinating infrastructure development. Ofgem assessing regulatory compliance. NESO managing system-level coordination. Internal teams whose effectiveness depends on accurate planning data and clear accountability.

Regulatory duties. Licence conditions for connections timescales. LTDS publication accuracy requirements. ED3 price control commitments. Connections reform expectations from NESO. Cyber resilience standards from the National Cyber Security Centre. Data protection obligations under UK GDPR.

Funding model. Allowed revenue through RIIO-ED2 (and soon ED3). Connection charges for reinforcement work. Innovation funding for targeted improvement projects. The architecture must fit within these funding mechanisms or propose changes to them through the regulatory process.

What is becoming more important. Information quality for planning and publication. Digital service responsiveness for customer interactions. Transparency and evidence quality for regulatory reporting. Flexibility management for network operation with increasing DER penetration.

External dependencies. Independent connection providers who deliver physical works. Metering agents who install and manage meters. NESO for system-level coordination and connections reform. Ofgem for regulatory framework and price control. Technology vendors for specialist network management systems.

This business-model frame is what prevents the London connections transformation from collapsing into a portal conversation. Every later architectural choice should be traceable to one or more elements of this frame.