Why is IT-OT architecture governance different in energy compared to other industries?

Energy and utilities operate physical infrastructure where operational technology has direct physical consequences if it fails. OT lifecycle timescales of 20–40 years and safety-case constraints make OT architecture fundamentally different from IT architecture governance. Energy organizations are also subject to mandatory cybersecurity standards (NERC CIP, NIS2) that specifically target OT systems connected to critical infrastructure. This combination of physical consequence, long lifecycle, and regulatory obligation means energy EA governance must be purpose-designed for OT, not just adapted from IT practice.

How do we get OT engineers to engage with the EA repository?

OT engineers engage when the repository solves their problems — not when they are required to feed a governance process. Start with a use case they care about: the IT-OT interface inventory they are responsible for securing, the CIP-002 BES Cyber System inventory they must maintain for compliance, or predictive-maintenance integration architecture they are investing in. Build the repository around those use cases and demonstrate value before asking for data-maintenance effort. Engineers who see the interface inventory simplify their change management will maintain it; engineers who see administrative burden will not.

How does the EA repository support NERC CIP compliance in practice?

The OT Architecture package serves as the authoritative BES Cyber System inventory — the foundational CIP-002 artifact. Assets carry CIP impact classification tagged values, ESP membership, and EACMS flags. The Governance package maps CIP control requirements to assets, tracking implementation status and evidence. When an auditor requests the BES Cyber System list, it is exported from Sparx EA rather than assembled from spreadsheets, and CIP-010 baselines are extracted from Configuration Item elements linked to the relevant systems.

How do we handle the ISA-62443 standard in our OT EA governance?

ISA-62443 defines Security Levels (SL 1–4) for industrial automation and control systems and the zones-and-conduits model for OT network security. In Sparx EA, you model OT security zones (analogous to NERC CIP Electronic Security Perimeters) with conduits representing communication paths. Security-level requirements are tagged on zone elements; security-level capability is tagged on systems within zones. Where requirements exceed capability, the model surfaces a gap that drives investment planning — mapping directly to the ISA-62443 SL-T (target) versus SL-A (achieved) construct.

What does the NIS2 Directive require from an EA governance perspective?

NIS2 requires essential entities, including electricity and gas operators above thresholds, to implement cybersecurity risk-management measures: asset identification and classification, supply-chain security, incident handling, and business continuity. From an EA governance perspective, NIS2 requires a maintained, classified system inventory — which the Sparx EA repository provides — with risk ratings and supply-chain assessments linked to system elements. The Interface Architecture package documents the IT-OT integration points specifically in scope for NIS2 supply-chain security.

How small can a functional EA team be in an energy organization?

A functional EA capability in a moderate-size energy organization (single country, single network type) needs a minimum of three people: an EA Lead who manages governance and stakeholder engagement; a generalist IT architect who manages the IT portfolio; and an OT specialist who manages OT architecture and the IT-OT interface layer. Below three, the team typically cannot maintain governance rigor, manage the OT domain credibly, and stay engaged with delivery at the same time. Larger or multi-network organizations need proportionally larger teams, but rarely the 15–20-person functions seen in large banks or telcos.

Insight · Governance

Enterprise Architecture Governance for Energy and Utilities: OT Meets IT

Q: Should OT architecture use ArchiMate or SysML?

Both have appropriate use cases. ArchiMate is better for operational technology at the enterprise level — system topology, integration architecture, capability mapping, regulatory-compliance mapping. SysML is better for engineering-level design: the functional architecture of a protection relay, the control logic of a substation automation system, or physical interface specifications for field devices. Large utilities with both EA and systems-engineering practices typically use ArchiMate in the EA team and SysML in the engineering team, hosted in the same Sparx EA repository with cross-links.

By Sparx Services · November 9, 2025

The short version: Enterprise architecture governance in energy and utilities has to do something most frameworks were never designed for: govern operational technology with 20–40-year lifecycles alongside IT that refreshes every 3–7 years. A governance model built for a corporate IT portfolio does not translate to a SCADA system installed in 2005 that must run until 2040. Effective energy EA governance needs separate-but-connected IT and OT domains, a repository structure that reflects that separation, and a shared interface layer where they meet — all sized to a team that is typically smaller and more specialist than its financial-services or telco equivalent.

The unique governance challenge in energy and utilities

The lifecycle tension

The fundamental tension is lifecycle. Enterprise IT systems — ERP, CRM, HR, collaboration — are typically replaced or significantly refreshed every 3–7 years, and cloud migration accelerates that further. IT EA governance is designed around this pace: portfolio reviews assess technology currency, architecture principles drive cloud adoption, and investment criteria favor modern, supportable platforms.

Operational technology runs on entirely different timescales. A digital relay installed at a transmission substation in 2005 may have a 35-year life. A SCADA master station may run for 25 years with incremental upgrades but no wholesale replacement. Gas distribution control systems operate under stringent safety cases that make change slow and careful. And capital cycles in regulated network businesses are determined by regulatory control periods that can lock spending into 5–8 year windows. So an energy EA team must simultaneously manage:

An IT portfolio refreshing on a 3–7 year cycle with cloud-native options
An OT portfolio on a 20–40 year replacement cycle with safety-case constraints
A growing integration layer where IT and OT increasingly interoperate — smart metering, demand response, DER management, predictive maintenance

A single governance model that applies identical standards and timescales to both domains fails both.

Why standard EA frameworks need adaptation

TOGAF and ArchiMate were developed primarily in enterprise IT contexts. The TOGAF ADM suits IT architecture work well, and its timescales assume significant change is achievable within 1–5 year horizons. For OT, the ADM needs real adaptation: Business Architecture phases must engage safety-case owners and operational engineers, not just analysts; Technology Architecture must accommodate IEC/ISA standards (ISA-62443, IEC 61511) that IT architects rarely meet; migration planning must account for safety-case change processes that can take years; and investment phases must align to regulatory control periods. The organizations that build effective energy EA practices adapt the standard frameworks to the OT context rather than applying them unchanged.

The governance model: separate but connected domains

Govern the IT domain with standard patterns

The IT EA domain governs the enterprise portfolio using standard Sparx EA patterns: ArchiMate notation, TOGAF-aligned ADM phases, an Architecture Review Board for IT change, a technology standards register, and application portfolio management. In the repository it sits as an IT Architecture package with sub-packages for Capability, Application, Data, and Technology Infrastructure, governed by standard tagged values and review workflows.

Give OT its own conventions and lifecycle states

The OT/automation domain governs SCADA, DCS, protection relays, substation automation, field instrumentation, and the industrial networks between them. It needs different modeling conventions (SysML or ISA-62443-aligned notation; IEC CIM for electrical assets), different lifecycle states (in-service, life-extended, approaching end-of-supportable-life, subject to safety case), and change management that accommodates safety-case constraints. Structure it as an OT Architecture package with asset-domain sub-packages — Generation, Transmission, Distribution, Gas Network OT — integrated with the asset-management framework (often ISO 55000).

Build the shared interface domain where IT and OT meet

As utilities deploy smart metering, demand response, and DER management, IT-OT interfaces multiply. A dedicated governance layer holds an IT-OT interface inventory (a shared package visible to both teams), interface-standards governance (IEC CIM, IEC 61968, ISA-95), security governance (NERC CIP, ISA-62443 security levels, segmentation), and joint change management requiring approval from both domains and often the operational safety authority.

Make the regulatory obligation the governance hook

NERC CIP, NIS2, and the UK CAF create an external driver for governance rigor that is often more persuasive internally than the architectural case alone. A Governance package mapping each regulatory framework to the system inventory turns compliance into the reason the rest of the governance model gets adopted.

Repository structure for energy organizations

The Sparx EA repository for an energy organization is structured to reflect these domains — IT Architecture, OT Architecture, Interface Architecture, and Governance — each maintaining its own conventions while the Interface Architecture package creates the connective tissue. Elements in different packages can be linked: an OT SCADA system in the OT package can be related to an IT historian in the IT Application package, with the relationship modeled through the Interface Architecture package. This is what keeps the two governance regimes coherent without forcing one to adopt the other's pace.

Regulatory considerations

NERC CIP (North America)

NERC CIP requires that BES Cyber Systems be identified, classified, and secured, with documented evidence. Governance meets this by keeping the OT package as the authoritative CIP-002 inventory and the control mappings in the Governance package, with the ARB process including a CIP impact assessment for any OT change that might affect classification or ESP boundaries.

NIS2 Directive (Europe)

The EU NIS2 Directive (which replaced NIS1 from 2024) applies to essential entities including electricity, gas, oil, district heating, and hydrogen operators, requiring cybersecurity risk management, supply-chain security, incident reporting, and business continuity. Governance meets it with a risk-mapped OT and IT inventory carrying security classification and reporting obligations as tagged values, and the Interface Architecture package documenting the integration points scrutinized under NIS2 supply-chain provisions.

UK CNI requirements

UK Critical National Infrastructure cybersecurity requirements for energy are governed by the National Cyber Security Centre and Ofgem, with sector-specific CAF (Cyber Assessment Framework) obligations for network-licensed operators. Governance supports CAF compliance by mapping the system inventory to the CAF objectives (A–D), documenting the contributing systems for each, and identifying gaps against the framework.

Right-sizing the EA team for energy

Realistic team sizes

Energy and utilities run smaller EA teams than equivalently complex financial-services or telecommunications organizations. The business is capital-intensive (investment is dominated by physical infrastructure, not software), OT change is slower, and the historically engineering-led culture has not always embraced EA as a practice. A typical mature energy EA practice looks like:

Organization Size	Typical EA Team
Regional DSO/TSO (medium)	3–5 architects: 1 EA Lead, 2 IT architects, 1 OT specialist, 0.5 data architect
Large integrated utility	6–12 architects: IT EA team (4–6), OT specialist (1–2), shared data/security architects
National TSO or large generator	8–15 architects, potentially with domain architects per business unit

Governance that works at small scale

Small teams cannot run governance designed for 20-person functions. Practical right-sizing:

Lightweight ARB — a 3–4 person board that meets fortnightly, applies a proportionate standard (significant investment or interface changes get full review; routine changes get a lightweight checklist), and uses the repository as the evidence base rather than separate submission documents.
Embedded OT specialist — at least one architect with genuine OT knowledge (SCADA, ISA-62443, IEC CIM, asset-management standards). Often the hardest role to fill and the most critical for OT credibility.
Standards-driven governance — a maintained Technology Standards Register and Architecture Principles set so standard-compliant decisions can be made without an ARB review for each one. The standards do the heavy lifting between meetings.
Regulatory hook — make the link between EA governance and NERC CIP, NIS2, or CAF compliance explicit; the external obligation drives rigor more persuasively than the architectural case alone.

Frequently asked questions

Why is IT-OT governance different in energy?

Energy operates physical infrastructure where OT failure has direct physical consequences. OT lifecycles of 20–40 years and safety-case constraints make OT architecture fundamentally different from IT, and mandatory standards (NERC CIP, NIS2) specifically target OT connected to critical infrastructure. That combination means energy EA governance must be purpose-designed for OT, not adapted from IT practice.

How do we get OT engineers to engage with the repository?

Solve their problems first. Start with the IT-OT interface inventory they must secure, the CIP-002 inventory they must maintain, or the predictive-maintenance architecture they are investing in. Demonstrate value before asking for data-maintenance effort — engineers who see their change management get simpler will maintain the model.

Should OT architecture use ArchiMate or SysML?

Both. ArchiMate suits enterprise-level OT — topology, integration, capability and compliance mapping. SysML suits engineering-level design — protection-relay functional architecture, substation control logic, field-device interface specs. Large utilities use both in one shared Sparx EA repository with cross-links.

How does the repository support NERC CIP compliance in practice?

The OT package is the authoritative CIP-002 inventory, with impact classifications, ESP membership, and EACMS flags as tagged values. The Governance package maps controls to assets and tracks status and evidence. Auditor requests are answered by export from the repository, not by reassembling spreadsheets.

How do we handle ISA-62443 in OT governance?

Model OT security zones (analogous to CIP Electronic Security Perimeters) with conduits for communication paths. Tag security-level requirements on zones and security-level capability on systems; where requirement exceeds capability the model surfaces a gap, mapping directly to the SL-T versus SL-A construct.

What does NIS2 require from an EA governance perspective?

A maintained, classified system inventory with risk ratings and supply-chain assessments linked to system elements — which the repository provides — plus documented IT-OT integration points, which are specifically in scope for NIS2 supply-chain security. Governance processes must include a NIS2 impact assessment for changes affecting in-scope systems.

How small can a functional energy EA team be?

Three people at minimum for a moderate-size organization: an EA Lead, a generalist IT architect, and an OT specialist. Below three, the team cannot maintain governance rigor, manage OT credibly, and stay engaged with delivery simultaneously.

Assess your energy EA governance readiness

Energy organizations face governance challenges generic EA programs are not designed for. Getting the model right — particularly the IT-OT boundary — is the foundation for everything else: smart grid architecture, regulatory compliance, digital-twin programs, and investment optimization. Paralysis to a Plan from Sparx Services delivers an energy-sector governance design tailored to your context, regulatory obligations, and OT estate. When you are ready to move beyond assessment, Configure the Solution establishes the model and trains the team to run it sustainably. For the platform underneath it, see why Sparx EA.

Where does your IT-OT boundary leak governance?

Talk to a practitioner about a right-sized energy EA governance model — separate-but-connected IT and OT, mapped to your regulatory obligations.

Book a call →

Keep reading