Why should Utilities avoid Point-to-Point (P2P) Integration?

Historically, many utilities use Point-to-Point (P2P) and often batch-style integrations as main pattern to exchange data between systems. One of the reasons for that is the fact that many utilities make the integration of meter data the responsibility of - for example - the vendor of the Meter Data Management solution (MDM). Typical examples are

  • Exchange of meter readings from Headend System (HES) to MDM
  • Forwarding of billing data from MDM to Customer Care & Billing (CC&B)
  • Synchronization of device or asset information between MDM, HES, Asset Management System, Geographical Information System (GIS) and even SCADA or Distribution Management System (DMS, ADMS)


In the long run, those Point-to-Point (P2P) integrations create a lot of challenges, limitations and they slow down utilities' transformation towards a data-driven organization:

  • Reduced adaptability and flexibility: Point-to-Point integrations create significant dependencies between systems and the systems' data formats and lead to tightly coupled systems. P2P integrations create a "Spaghetti Architecture" that makes adaptions or changes to the application landscape painful and costly.
    Example: Many utilities need to enhance or completely exchange their first generation MDM solution in order to handle the ever-increasing amount of smart metering data and create value from the investment in their Advanced Metering Infrastructure (AMI). A tight coupling between HES and MDM or MDM and CC&B using P2P integration makes it difficult and costly to modernize or exchange the MDM.

  • Reduced re-use of data: Point-to-Point integration moves data between System A to System B using either System A's data format or System B's data format. This makes it almost impossible to re-use data in another system, System C. Instead, a new P2P integration between System A and System C is developed that adds more Spaghetti to the integration architecture and increases operational complexity significantly.
    Example: Many utilities could benefit from leveraging alarm & event data and grid measurements to build or improve intelligent grid operations. Using a P2P integration between HES and MDM makes it impossible to "intercept" AMI data and make it available to other systems such as ADMS, analytics systems or predictive services (e.g. last-gasp messages).

  • Broken processes: Point-to-Point integrations often exchange information in batch mode. To enable intelligent grid and business operations, utilities need to implement seamless and boundary-less automatic processes. P2P integrations in batch mode lead to broken processes with many manual steps and make it impossible for utilities to drive their digital transformation.
    Example: Many utilities want to drive customer engagement by providing a close to real-time user experience. This requires for instance that each customer's information is instantly and uniformly available across the various applications for the different contact points (portal, mobile app, CRM, CC&B, etc.). Using P2P integrations makes it almost impossible for utilities to provide excellent user experience for today's modern consumers

  • Monitoring & Error Handling: Especially with chained integration scenarios - meaning scenarios where data must be moved between several systems - point-to-point integrations are put together of many autonomous steps to move data from A to B, B to C, C to D, etc. Monitoring, potentially identifying problems and handling errors is quite hard and challenging.
    Example: The AMI provisioning and commissioning process is failing and the utility has implemented P2P integrations. In that case, the utility will struggle to identify whether the error is caused by a failure in the workorder / field service integration to MDM, or whether there was a problem with the factory file upload to the HES or maybe the integration between MDM and HES failed.


Those and most probably even more limitations and challenges are the reason future-oriented utilities should avoid Point-to-Point integrations and favour loosely coupled and event driven integration architectures with the help of a suitable integration platform / integration platform as-a-service (iPaaS).

Related stories