Government and regulated-sector reference models

Reference models can give the enterprise a shared vocabulary, a stable structural baseline, and a way to compare or align architecture thinking across programmes, institutions, or regulated domains. That can reduce needless argument and make interoperability or assurance work easier.

The benefit is structure, not substitution. A reference model is not the local architecture. It is reusable guidance that may or may not fit well enough to adopt directly. The Enterprise Continuum in TOGAF recognises this explicitly: it classifies architecture assets from very generic (useful anywhere) to very specific (useful only in your organisation). Reference models sit towards the generic end. Local architecture sits towards the specific end. The enterprise needs both.

Reference models are common in government, defence, utilities, healthcare, and financial services. In each setting, they serve a similar purpose: reducing the cost of argument about common structure so that the enterprise can focus on the local differences that actually matter.

G21D, "Using the TOGAF Framework in the Government Enterprise Architecture Context," is the primary TOGAF Series Guide for government and regulated-sector architecture. It provides guidance on how to apply the ADM in environments with strong accountability requirements, multi-organisation interoperability needs, and external assurance obligations.

Key recommendation 1: Reference models as accelerators, not replacements. G21D positions reference models as accelerators that reduce the cost of common structure but insists that local architecture reasoning must still happen. The enterprise should be able to explain its architecture in its own terms, not only in reference-model terms.

Key recommendation 2: Cross-organisation interoperability. Government and regulated-sector enterprises often need to share data, coordinate processes, and demonstrate assurance across organisational boundaries. Reference models help by providing shared vocabulary and structural patterns. But the interoperability must be tested in practice, not just mapped on paper.

Key recommendation 3: Accountability and evidence. In government and regulated settings, the architecture must support accountability to external bodies: regulators, audit committees, parliamentary scrutiny, or industry oversight. Reference models can provide a structure for that accountability, but the evidence must be local and specific.

Key recommendation 4: Multi-tier governance. Government enterprises often operate across multiple tiers: national strategy, departmental programmes, agency delivery, and local implementation. Reference models can provide consistency across tiers, but each tier must have enough architectural autonomy to address its own specific responsibilities.

The useful relationship with a reference model is not binary. The enterprise does not have to adopt it completely or ignore it entirely. Three positions are available, and the architecture team should make a deliberate choice for each element.

Adopt. Borrow structure or vocabulary with little change because the local context is close enough and the model genuinely helps. This works when the reference model was designed for a context similar to the enterprise's own. Adoption saves time and improves comparability. But adoption without assessment is copying, not architecture.

Adapt. Use the model as a starting point but translate it to local responsibilities, controls, and service realities. This is the most common useful position. The enterprise benefits from shared vocabulary without pretending that every category fits precisely. Adaptation requires the team to identify where the reference model fits, where it needs translation, and where local extensions are needed.

Resist. Choose not to force the model where it would add compliance theatre rather than better architecture understanding. This is the right choice when the reference model was designed for a fundamentally different context. Resistance is not rejection. It is an informed decision to develop local architecture rather than force-fit borrowed structure.

For each reference-model element, the architecture record should state which position was chosen and why. That record makes the reasoning visible to the Architecture Board and to external reviewers.

Regulated sectors share common architecture patterns that reference models can capture. Understanding these patterns helps the enterprise know what to look for in a reference model and where local translation will be needed.

Pattern 1: Regulatory reporting architecture. Regulated enterprises must produce regular, auditable reports for external bodies. The architecture must support data collection, validation, transformation, and submission with full audit trail. In energy, this includes LTDS publication. In water, it includes annual performance reporting to Ofwat. In transport, it includes safety reporting to the Office of Rail and Road.

Pattern 2: Multi-regulator environment. Many regulated enterprises report to more than one regulator. A distribution network operator in the UK may need to satisfy Ofgem (economic regulation), NCSC (cyber security), DESNZ (energy policy), and the HSE (health and safety). Each regulator has its own framework, vocabulary, and evidence requirements. The architecture must support all of them without creating a separate system for each.

Pattern 3: Operational technology governance. Regulated utilities operate safety-critical OT systems that have different governance requirements from enterprise IT. Reference models designed for enterprise IT rarely address OT governance adequately. The enterprise needs its own OT governance architecture, informed by but not copied from IT-focused reference models.

Pattern 4: Cross-sector data exchange. Utilities and regulated enterprises often need to exchange data with other organisations: other utilities, market operators, regulators, and national bodies. Reference models can provide shared data models and exchange standards (like the Common Information Model in energy), but the implementation must reflect local system realities.

Federal Enterprise Architecture Framework (FEAF). Used in US federal government. Defines performance, business, data, application, infrastructure, and security reference models. Useful for vocabulary and comparison in large government settings. Most directly applicable to US federal agencies but provides structural patterns that other governments adapt.

UK Government Digital Service (GDS) standards. The UK government publishes service standards, technology code of practice, and spending controls that function as de facto reference models for government digital services. These are less formally structured than FEAF but more practically influential in the UK context.

TOGAF government guidance (G21D). Explains how TOGAF applies in government and regulated contexts. It does not impose a single reference model but provides guidance on how to use reference-model thinking within the TOGAF framework.

DoDAF and NATO Architecture Framework (NAF). Defence-sector frameworks that define architecture viewpoints for operational, systems, and technical perspectives. Relevant to defence suppliers and organisations that interface with military systems.

Sector-specific models. Energy, water, transport, and healthcare sectors often produce their own reference architectures. In energy, the Smart Grid Architecture Model (SGAM) and the Common Information Model provide domain-specific reference structures. These tend to be more useful than cross-sector models because they address domain-specific responsibilities.

The key principle across all of them is the same: borrow structure, do local analysis, and record the translation decisions.

London Grid Distribution sits in a strongly governed environment, so reference-model thinking is useful. It can help with common structure, regulated vocabulary, and external comparison. But the London architecture still has to explain the real utility context.

What London should adopt. The Common Information Model for electricity network data exchange is a well-established, domain-specific reference model that London should adopt where it applies. The NCSC Cyber Assessment Framework provides a structure for cyber security assessment that London should adopt for its regulatory reporting.

What London should adapt. Cross-sector digital infrastructure reference models (like those published by government digital bodies) provide useful vocabulary for enterprise IT services but do not address OT, telecom, or field-communications specifics. London should adapt the IT categories and develop its own vocabulary for OT and telecom domains.

What London should resist. Generic enterprise architecture reference models designed for office-based organisations do not address the safety-critical, OT-heavy, field-operations-intensive reality of a distribution network operator. Forcing London's architecture into those categories would hide the most important local responsibilities.

• Regulated context increases the value of reference-model thinking but does not remove the need for local architecture.
• The London case should look informed by external structure, not replaced by it.
• OT, telecom, and field-communications domains are poorly served by most general-purpose reference models. London needs its own vocabulary for those layers.
• The adopt-adapt-resist decision should be recorded for each reference-model element so that external reviewers can see both the alignment and the local reasoning.