• Technical Architecture Not Aligned With Business Value: It is often unclear how architectural decisions connect to utility business outcomes (e.g. grid reliability, regulatory compliance).
• Legacy Technology Results in Architectural Complexity: Utilities often operate on decade-old systems, and defining future-state architecture while maintaining current operations is challenging.
• Disconnected IT and OT Domains: IT and OT have different environments and requirements. Without convergence, data remains siloed and real-time coordination is limited.

• Lack of Architectural Governance and Ownership:
  Not having a formal architectural review board or clear accountability for maintaining standards leads to inconsistent technology choices.
• Resource and Skill Gaps in Enterprise Architecture: Architecture, cyber, cloud, and integration expertise are scarce, leading to slow adoption of the technical architecture and difficulty sustaining it.
• Limited Data and Integration Standards: Inconsistent use of standardized frameworks (e.g. CIM, IEC61968/61970, NIST) makes interoperability and analytics difficult.

1. Create or Assess the Utility Business Reference Architecture (BRA): This architecture outlines the business objectives and capabilities that your technical reference architecture should support.
2. Design the Target Technical Architecture: Align your business capabilities with suitable technical solutions across various technical domains (e.g. application, integration, data, security).
3. Implement the Technical Reference Architecture (TRA): Address the key technical gaps by conducting value stream mapping and prioritizing technical projects accordingly.

• Technical designs that are not traced back to business capabilities and outcomes become technology-centric exercises and face elevated risk of underutilization.
• Investments in new systems that don’t map to business KPIs deliver few measurable benefits (e.g. optimize for uptime rather than outage reduction, customer satisfaction).

• Many utility companies still operate on legacy systems incompatible with modern IT infrastructure, with the average cost of maintenance estimated at $56 million per year (IT Pro, 2025).
• Beyond the cost of upgrading technology and considerations about downtime, employee retraining, and disruptions to services, utilities must balance short-term costs with long-term benefits.

• IT and OT technology systems are deeply interwoven; however, the ways of working are disjointed. OT’s fear of interrupting services often leads to a “don’t fix it if it’s not broken” mentality.
• IT and OT systems evolved separately; converging them for real-time operations and analytics requires secure, governed patterns for integration.

• Architectural drift: Without adequate governance, projects sidestep TRA standards, leading to inconsistent systems and higher integration cost (e.g. increasing IT/OT divergence).
• A TRA becomes operational only when a governance model enforces it – without one, the TRA becomes just another underutilized tool.

• The demand for specialized skills and resources is increasing as technology advances (e.g. OT cyber, IT/ICS skills). These resources are scarce, and they take time to develop.
• TRA requires people, processes, and technology to all be functional. Without people and skills, the TRA becomes aspirational rather than executable.

• The TRA assumes a baseline level of modernization and interoperability that legacy environments often can’t support because of the technical debt accumulated over years.
• Existing systems, integrations, and data models are so rigid that implementing new architectural principles can uncover additional need to resolve technical debt.

• The business reference architecture (BRA) decomposes strategic goals into business capabilities. Align the TRA to the BRA to ensure it is business-led and not technology-led.
• Derive architectural principles that reflect organizational priorities from the BRA (e.g. zero trust, interoperability). These principles act as design guardrails throughout the TRA development.

• For both the BRA and the TRA, individuals in your organization must be able to point to a business or technical capability that is part of their role’s responsibility.
• Identify and catalog both existing and aspirational technical capabilities to expose gaps, redundancies, and technical debt. This provides a factual baseline to design an achievable TRA.

• Embed the same governance, ownership, and continuous improvement processes for both BRA and TRA to ensure they are not static documents but rather living operating models.
• Activate the TRA and use it to make strategic decisions about the organization’s investment priorities and risk profile, etc. This ensures every dollar invested in technology directly contributes to business outcomes.

Use the business reference architecture to define the organization’s value streams and supporting capabilities. This is a prerequisite to mapping the technical capabilities of your organization.

Develop the technical reference architecture by mapping all technical capabilities, both existing and aspirational, supporting the applicable business capabilities outlined in Phase 1.

Activate the TRA as a tool to make informed decisions across various areas of technology (e.g. risk and resilience, AI investments, standards and policies).

1. Build or review the BRA, noting where the TRA resides.
2. Define the architectural principles that reflect your organizational priorities.

1. Map current-state technical capabilities within IT and OT teams.
2. Note existing gaps and consider aspirational capabilities to include in the TRA.

1. Walk through potential use cases for the TRA (e.g. AI heat map).
2. Embed governance processes aligned with BRA.

Clear line of sight to the organization’s value stream, goals, and business capabilities. The BRA determines what capabilities the business needs, while the TRA provides how technology achieves those needs.

Documented tool indicating current-state technical capabilities, existing gaps, and areas of redundancy to support the organization’s technological roadmap

List of use cases that can be leveraged by the TRA to ensure it is not a static document but rather a tool embedded in the technology decision-making process.

Describes what the organization does and why through business functions, capabilities, and value streams.

Describes how the organization’s technology environment is structured to support those business capabilities.

Align business operations, capabilities, and strategy across the organization.

Support the definition of consistent technology standards, integration patterns, and deployment models across IT/OT.

Executives, business architects, planners, operations leaders

Solution architects, IT architects, infrastructure, security and data teams

Enterprise-wide business model

Technology landscape

• Business capability maps
• Value stream diagrams
• Stakeholder and process models

• Logical and physical architecture diagrams
• Technology standards catalog
• Integration and data flow patterns

Defines how Planning & Engineering supports reliability and regulatory goals with capabilities like Asset and Work Management.

Defines what systems (EAM, GIS) and integration patterns (APIs, ESBs) are required to enable those capabilities.

Provides a starting point for you to develop a unique TRA for your organization. Technical capabilities assigned to each layer are captured for a mature utility organization, allowing for customization.

Prepopulated heat maps that operationalize the TRA to support technical decision-making. Heat maps for IT/OT ownership and market AI investment trends are provided as starting points. Develop other views unique to your organization.

A TRA benefits IT in the following areas:

• Standardization of Technology Landscape: Reduce system sprawl and more easily manage diverse technologies (SCADA, OMS, CIS, GIS, etc.).
• Support Technology Investment Planning: Prioritize investment and resource allocation aligned to value streams.
• Increased Risk Awareness: Identify capabilities where technical service delivery is lacking and improvements are needed.
• System Standardization: Outline areas where standards and policies can reduce the need for custom solutions.

Advantages created across the business include:

• Business-Aligned Technology Investments: Ensure investments directly support business capabilities.
• Improved Operational Efficiency: Streamline data and process flows across departments through standardization.
• Enhance Regulatory and Compliance Readiness: Technical capabilities (e.g. cyber) comply with regulatory frameworks such as NERC CIP.
• Long-Term Cost Optimization: Use strategic architecture to avoid duplication and unmanaged complexity across layers.

Call #1:
Review your organization’s goals and value stream.

Call #2:
Review the BRA and discuss where the technical and business capabilities align.

Call #3:
Identify current and aspirational technical capabilities across each layer.

Call #4:
Assess any gaps, redundancies, and technical debts to consider for initiatives.

Call #5:
Walk through key use cases for the TRA.

Call #6:
Embed architectural governance processes – leveraging the BRA processes.

Review Business Reference Architecture

Design Technical Reference Architecture

Assess Gaps, Redundancy, and Technical Debt

Embed TRA Into Existing Workflows

1.1 Review organizational value streams, goals, and sources of value.

1.2 Assess BRA and the connection to technical capabilities.

1.3 Establish a set of architectural principles to guide the TRA development.

2.1 Identify existing technical capabilities (Level 1 and Level 2).

2.2 Explore aspirational capabilities to enable in the future.

3.1 Determine where there are capability gaps, highlighting at-risk capabilities.

3.2 Identify redundancies in business and technical capabilities, revising the TRA and BRA if necessary.

3.3 Chart initiatives to reduce technical debt in the future.

4.1 Operationalize the TRA by embedding it in existing workflows and use cases (where applicable).

4.2 Integrate TRA in existing architectural governance processes.

1. Organizational value stream mapping
2. Revised/updated BRA

1. Draft of TRA

1. Heat map of technical risk profile
2. Roadmap of technical initiatives to activate

1. Use case identification and integration
2. Actionable plan to execute roadmap

The electric energy sector faces a significant challenge in achieving consistent and robust cybersecurity across its operational technology (OT) and industrial control systems (ICSs). Even though there are over 60 cybersecurity standards applicable to the electrical grid, there are still gaps corresponding to various areas of the grid that may not be addressed. Key challenges include:

• Standards may offer different or contradictory guidance.
• Grid operations struggle to determine which standards to adopt.
• Rapid technology advancements (e.g. automation, DERs) blur the boundary between OT and IT.

The Department of Energy proposed a reference architecture for OT that would establish a common architecture communication platform to guide and constrain the customization of multiple architectures and solutions. The reference architecture:

• Introduces conceptual elements critical for security evaluation.
• Incorporates domain-specific applications derived from the baseline architecture.
• Highlights the cybersecurity process flow, where the architecture can be leveraged to design an organization’s OT security program.

The reference architecture is used to:

• Identify gaps in OT security design and solutions.
• Reveal gaps in the 60+ applicable cybersecurity standards.
• Accelerate the process design, and it tends to produce better results.
• Reduce duplicative efforts and provide a mechanism for building consensus.

Duke Energy faced mounting operational and planning complexity due to:

• Rapid demand growth from electric vehicles, electrification, and population expansion.
• Growing need for integration of distributed energy resources (DERs) such as solar, edge storage, and microgrids, which increases variability and bidirectional grid flows.
• Fragmented data architecture with siloed legacy systems (e.g. SCADA, AMI, GIS, OMS) hindering holistic visibility and slowing analytics delivery.

Duke Energy implemented a layered TRA (built on AWS), connecting operational and enterprise systems through standardized data, integration, and analytic patterns. Key layers captured in the TRA included:

• Edge and field systems (e.g. IoT gateways, telemetry devices, edge compute nodes).
• Data integration and ingestion – AWS IoT core, standardized data model.
• Security layer – IAM, encryption, aligned with NIST and utility standards.
• The architectural principle “build once, use many times” ensures new use cases can reuse common components.

The reference architecture became a foundational document to support Duke Energy’s journey to grid distribution through:

• Improved data latency from days to minutes for planning use cases.
• Enabled optimization of grid investments – targeting areas of highest need.
• Reusable platform extended to multiple planning domains.
• Enhanced regulatory compliance and cybersecurity posture.