Modular by Design: Building Utility Solutions One Step at a Time
January 2026
- Today’s utilities do not have the luxury of building their IT and OT environments from scratch. Shaped by decades of operational requirements, regulatory constraints, and vendor-driven implementation, the infrastructure already exists. While maintaining the systems, utilities face never-ending pressure to modernize, digitize, and integrate new capabilities across the enterprise.
- Large programs attempting to coordinate many systems at the same time often increase risk rather than reduce it. These efforts have significant upfront decisions and assume a level of alignment between systems which rarely stand the test of time. As systems continue to evolve independently, rework becomes commonplace and costly.
- Modernization does not require a single program dealing with every system at the same time. In this article, we introduce the concept of modularity and show how heterogeneous systems can evolve independently while allowing effective communication between these systems.
What Modularity Means in a Utility Context
- Depending on a person’s role at a utility, modularity can mean different things. To a software engineer, it may mean thinking about components in a service-oriented architecture or as microservices. To an architect or a business analyst, it could mean the ability to replace one component without a major disruption.
- The interpretations above describe implementation choices, but not the core principle of modularity. In the context of this article, modularity means a system or capability has:
- Clear boundaries of responsibility
- Well-defined data schemas and interfaces
- The ability to evolve without breaking changes to other systems.
Our goal is not to eliminate large systems, but to avoid having all-encompassing coordination which can lead to an entangled, highly dependent infrastructure in which one broken connection can lead to a dominos of effects.
Consider a utility replacing an outage management system (OMS). If systems feeding OMS and consuming data from OMS are tightly coupled to vendor-specific schemas and interfaces, the replacement becomes a major reintegration effort. Each providing and dependent system needs to take inventory of how data is structured and the semantics of how to map the old and new data to internal models.
By thinking modularity, that is, building against well-defined data and interfaces instead of vendor-specific implementations, the replacement becomes less disruptive.
Consider a utility replacing an outage management system (OMS). If systems feeding OMS and consuming data from OMS are tightly coupled to vendor-specific schemas and interfaces, the replacement becomes a major reintegration effort. Each providing and dependent system needs to take inventory of how data is structured and the semantics of how to map the old and new data to internal models.
By thinking modularity, that is, building against well-defined data and interfaces instead of vendor-specific implementations, the replacement becomes less disruptive.
Start by Taking Inventory, Not Replacing Systems
The first practical step toward modularity is understanding what already exists and their interconnections. Typical systems at a utility include:
- Geospatial Information System (GIS)
- SCADA
- EMS
- AMI
- Customer Information System (CIS)
- Work Management System (WMS)
- Asset Management System (AMS)
- Outage Management System (OMS)
Each of these systems may have been designed with integration in mind, but without consideration of the differing data schemas and interfaces each may have. This causes integration efforts to be point-to-point as needs arise.
Rather than continuing this pattern of integration, utilities can shift from integrating systems directly with each other to integrating through well-defined modules. This shifts the question of “how can a point-to-point integration” occur to “what does this system provide to the rest of the enterprise?”
First Steps Towards Modularization through Data
The safest place to start modularization at a utility is by looking at the data.
Even when systems were not designed for interoperability, their data can be mapped to a shared, commonly understood model. Standards such as the Common Information Model (CIM) can serve as an intermediary rather than a replace, as discussed in a previous article.
Mapping systems to a common data model allows utilities to:
- Incrementally align systems to a shared internal language.
- Reduce risk by decoupling data from system replacement.
- Enable teams to communicate using consistent concepts.
- Avoid remapping every integration during upgrades.
- Lower long-term integration costs by reusing integration mappings.
The mapping effort from a system-specific data model to a common data model can be done gradually without disrupting existing implementations. Over time, the shared model becomes a stable foundation which lives past the current and previous implementations.
Interfaces Matter More than Implementations
As systems are integrated, the contracts they expose matter more than the internal implementation. Utilities can define contracts reflecting their operational needs rather than vendor-specific designs. These contracts may include:
- Interfaces and APIs
- Event messages
- Required communication protocols
These contracts, not the implementations, become the long-lived assets that can span multiple implementations. Implementers only need to ensure the systems being implemented satisfy the contracts and need not rewrite integration code per system when an upgrade or a replacement occurs.
How Modularity Changes How Teams Work
Designing for modularity introduces a shift in mindset. Instead of asking how to integrate with another system, they now ask what their system can provide for other systems. This shift provides the following benefits:
- Domain experts and engineers can document what their systems provide upfront, reducing repeated discovery work later, from both new members joining their teams and to other teams
- Teams consuming data or capabilities can provide faster, more informed feedback
- New tools can be evaluated based on gaps and incremental value rather than wholesale replacement
- Audits and reviews become easier when data schemas and interfaces are documented from the start.
Moving Forward with Modularity
Utilities do not need to modularize everything at once. In fact, that may seem like what we were trying to avoid in the first place. A practical starting point is to choose a system that:
- Has a clear business value
- Currently integrates with multiple systems
- Can be extended incrementally without disrupting operations.
Measuring success can be done by looking at the following outcomes:
- Level of reuse for data schemas and interfaces
- Ease of integration with other systems
- Time reduced spent finding and reconciling information.
Utilities will continue to evolve, along with the systems supporting them. Modular design reduces the difficulties of evolution. By focusing on clear boundaries, shared data models, and interface contracts, utilities can modernize one step at a time instead of as one large monolithic solution.