The integration of GIS across the utility has evolved significantly over the last two decades. GIS is no longer a siloed system in the utility enterprise landscape. Instead, it has become the central system that aggregates data from multiple systems and enriches it with geospatial intelligence and network context to deliver meaningful insights.
In previous blog posts in this series, we explored evolving the architectural landscape to support new application environments to selecting a data model implementation pattern that provides immediate Commercial Off-the-Shelf value to reimagining business process and customization requirements. In this blog article, we will dive deeper into the changing Integration Landscapes and the adoption of new integration patterns, such as the Service-Oriented Approach, leveraging the core capabilities of Middleware platforms, and modern approaches to integrating apps.
ArcGIS is designed to sit in the middle of an enterprise landscape, taking data from “upstream” systems (sources) and feeding results and services to “downstream” systems (consumers) through web services, APIs, and connectors. Integrating GIS systems with upstream sources and downstream consumers has become a central focus of grid modernization and a key consideration in the migration to the ArcGIS Utility Network. In this article, we will explore where traditional patterns of integration fell short and how modern patterns, especially those adopted by the next-generation ArcFM Solution XI Series, are enabling utilities to maximize their use of GIS as a foundational enterprise system.
Understanding systems “upstream” and “downstream” of GIS
To understand a utility’s GIS integration needs, it’s important to clarify the differences between upstream and downstream systems. Upstream systems typically provide core business, asset, sensor, or transactional data into ArcGIS, such as ERP, EAM, SCADA/IoT platforms, CRM, and data warehouses. When ERP/EAM, SCADA/IoT, CRM, and warehouse data are brought into GIS, planners and engineers can see where assets are, how they connect, and what conditions surround them, instead of working with isolated tables. Spatial context lets utilities answer questions like “Which critical assets are in a flood zone?” or “Which customers and circuits are affected if this transformer fails?”, improving planning, risk management, and investment decisions.
Downstream systems typically consume location-enriched data and services from ArcGIS, such as customer portals, field mobility apps, analytics platforms, grid operations software, and other lines of business applications. These systems are critical to integrate with the GIS because they use GIS data as the accurate, real-world basis for the network.
Traditional integration patterns
Traditional GIS integration patterns offered an important starting point to enable utilities to maximize their GIS data; however, traditional patterns suffer from significant limitations or high complexity to provide scalability and real-time operations. Let’s take a moment to unpack the patterns most utilities are moving from and explore their limitations.
Batch integration pattern
With a batch ETL into feature classes integration pattern, upstream asset, work, or design systems (e.g., ERP, EAM, CAD) typically push data into the underlying feature classes using ETL tools or database-level loading. The geometric network was then rebuilt, or connectivity repaired as needed, to update the logical network. Unfortunately, batch ETL processes introduce complexities, latency, and risks to the geometric network integrity, making updates slow and error prone.
Spatial data interoperability
CAD or modeling tools export line and point data that is imported into network feature classes, after which snapping, topology cleanup, and geometric network build/repair tools are used to enforce valid connectivity rules. However, design-to-GIS migrations demand manual snapping and topology cleanup, adding complexity and delays.
GIS enhancements
In desktop extensions, ArcFM or custom tools operate directly on geometric network feature classes and logical network tables to provide tracing, editing rules, and domain-specific tools, while still using standard ArcGIS editing and tracing APIs. Desktop extensions such as ArcFM remain client-centric and difficult to integrate with modern web or cloud systems.
Custom tools and scripts query the logical network tables indirectly via ArcObjects, or geoprocessing tools, or SQL queries to derive connectivity, upstream/downstream selection, or flow paths that can then be passed on to other systems as outputs. Custom scripts and tools are fragile, costly to maintain, and prone to breaking with schema changes.
Geodatabase or database replicas
Downstream analysis, modeling, or reporting tools (e.g., network planning tools or outage management systems) consume exported feature classes or network edges/junctions as GIS layers, often via file/enterprise geodatabase replicas or formal exports, without requiring an understanding of the geometric network internals. Downstream analysis relies on static exports, losing network intelligence, and creating data duplication.
Overall, these approaches are labor-intensive, not cloud-ready, and fail to deliver real-time, API-driven integration needed for modern utility networks.
Transition to new integration patterns for advanced performance and scalability
The ArcGIS Utility Network (UN) model addresses the limitations of traditional GIS integration patterns by introducing a modern, service-oriented, and rules-driven architecture. Modern patterns now include several options that ensure scalability and performance. Let’s discuss these patterns and their benefits.
Service-oriented architecture
First, the ArcGIS Utility Network utilizes real-time, service-based access as a core integration pattern. Instead of batch ETL or static exports, the UN exposes network capabilities through web services and REST APIs, enabling real-time integration with OMS, DMS, and planning tools. ArcGIS exposes feature, map, image, routing, and geoprocessing services over REST, which other applications call directly to read/write data or run analytics.
Network exports
ArcGIS Utility Network also supports data sharing with downstream systems, enabling them to pull network data via REST calls to meet their needs. The shift from traditional replication technology is the primary advantage, as it places the data consumer in the driver’s seat.
To complement this, ArcFM Feeder Services XI provides capabilities for managing feeder extraction, triggered by configurable change events, and for sharing it in a standard, easy-to-consume format with downstream systems such as ADMS, OMS, Network, or Structure Analysis software. ArcFM Feeder Services XI extracts the “Export Subnetwork” data from the GIS database, adds meaningful information from the Equipment Catalog, and produces an output that can be easily transformed into the Common Information Model (CIM). The ArcFM output is then readily accepted by the third-party software that conforms to the CIM specifications. ArcFM Feeder Services XI provides a mechanism for tracking feeder changes throughout the day and processing them only in accordance with the defined schedule.
Enterprise system integration
Modern patterns also utilize middleware platforms. Middleware acts as gateways that translate utility network feature data and connectivity information into forms consumable by newer service-oriented systems (e.g., normalizing network elements into simple asset tables with connectivity attributes) to support modern web or mobile applications without modifying the legacy core.
ArcFM, as a hybrid-cloud, services-based solution, supports use cases that utilities continue to evolve. One of the key features of this pattern is the use of the Azure Service Bus (ASB), a fully managed message broker that decouples applications and enables reliable, scalable integration among systems such as the Work Management System, the Asset Management System, Scheduling, and others.
ASB provides queues and topics/subscriptions (publish–subscribe) with durable messaging, transactions, dead lettering, and ordered delivery options. It works well for real-time or near-real-time integration, where producers and consumers do not need to be online simultaneously, thereby improving resilience and scalability.
This pattern allows many utilities to leverage the core capabilities of the Enterprise Service Bus/Middleware software they have already implemented. Many middleware and iPaaS platforms (such as Azure Integration Services, Oracle Integration, Boomi, etc.) provide prebuilt connectors/adapters for standard systems and protocols, as well as mapping and routing tools. This pattern allows the integrations configured as flows: trigger on an event, transform the message, then send/receive via Service Bus queues or topics.
Use Service Bus as the central, reliable message hub; use middleware connectors to integrate specific applications (WMS, ERP, GIS) without each system talking directly to all others.
App to app integration
App and UI embedding is another common pattern. ArcGIS web maps, apps, and dashboards can be embedded in portals, CRMs, or custom web applications, enabling users to interact with GIS content within non-GIS systems. App-to-app integration using URI schemes allows one app to launch another and deep-link to a specific screen or action via a custom URL (e.g., myapp://entity/123). The target app registers its unique scheme with the operating system, which then routes the URI and passes the parameters to the receiving app so it can navigate to the proper context. This lightweight pattern is well-suited to point-to-point workflows on the same device. A couple of use cases for utility are:
- Getting turn-by-turn directions to the Work Location from the current location on the ArcFM Mobile.
- Invoking the field data collection app from ArcFM Mobile in the context of the pole and passing the attributes from the ArcFM Mobile
In addition to the above-defined patterns, the Service-Oriented Architecture (SOA) is the preferred approach for designing integration as a collection of independent, reusable services that communicate over a network via well-defined interfaces. Each service encapsulates a specific business capability, hides its internal implementation, and can be discovered and invoked by other services or applications, often via standard protocols such as HTTP and message formats such as XML or JSON.
In short, the ArcGIS Utility Network, along with purpose-built solutions such as ArcFM, replaces brittle, desktop-centric workflows with a centralized, API-driven, rules-based system that supports real-time operations, scalability, and integration with modern enterprise and cloud ecosystems.
While the migration effort is time- and cost-intensive, leveraging modern integration patterns will deliver lasting benefits to utilities, resulting in a more resilient and interoperable grid.
If you would like to discuss modernizing your utility’s integration landscape, please contact your SE account manager to learn more about our ArcFM Utility Network professional services.
As we’ve said before, success in this journey demands more than just technology. It requires leadership, clarity, and a commitment to building on solid ground.
Read our previous blogs in the series to learn more about how to navigate the many complex decisions in the transition to the ArcGIS Utiity Network with ArcFM:
- Evolving the Architectural Landscape to Support Application Environments Needed for Grid Modernization
- Get Flexibility Without the Price Tag Through Smarter Utility Network Data Conversions
- Reimagining Customizations in favor of Extensible Commercial-Off-the-Self (COTS) Solutions in the Move to the ArcGIS Utility Network
Add a comment