The integration tax: Where utility work loses time
Why the most expensive delays often happen between systems
A utility pole rarely belongs to just one workflow. Inspection teams record its condition. Vegetation management tracks clearance work. Maintenance manages repairs. Grid-hardening programs evaluate future investment. Attachment auditing, storm response, and customer care may all add information that affects what happens next.
The integration challenge is that each team can have accurate records and still leave the next team without enough information to act.
The time spent closing those gaps is the integration tax: the manual work, delays, and operational risk created when people have to reconstruct context as work moves between systems. Technical integrations may already connect many of those systems. The tax remains when the information that crosses those connections is not complete, consistent, or usable enough for the next decision.
One pole, several systems and a series of gaps
Consider an inspector who records damaged hardware on a utility pole. The inspection application captures the finding, photographs, and severity. The record now needs to inform maintenance planning.
A maintenance planner needs more than the finding. They need to know which pole it applies to, where the asset is located, whether the assessment is current, what work has already occurred, and whether other work is planned. Access requirements or vegetation conditions may affect the job. A grid-hardening program may already include the pole in a future project.
Each step creates an opportunity for the integration tax to appear.
The inspection application identifies the asset one way, while GIS uses another identifier. A spreadsheet maintained by the field team refers to the circuit rather than the pole. Before planning can continue, someone has to establish that the records describe the same asset.
Then comes context. A hardening project appears against the pole, but the planner needs to know whether the project is proposed or approved. An inspection finding shows damaged hardware, but is it the latest assessment? Maintenance history shows prior work, but did that work address the current condition?
Even a technically successful interface may leave those questions unanswered. Moving an inspection record from one system to another does not establish which identifier is authoritative, define what a status means, or determine which record takes precedence when information conflicts.
Someone still has to search, call, compare, and reconcile before the work can proceed. The data moved. The integration tax did not.
The cost extends beyond one delayed decision
Utilities often absorb that work as ordinary coordination. A planner spends 20 minutes checking a record. An analyst manually joins two extracts. A crew calls for missing information. A report gets delayed while someone verifies which value is current.
Individually, those tasks may appear small. Across thousands of assets, work orders, outages, and customer interactions, the same gaps create repeated manual effort and rework. More importantly, a gap that is resolved for one workflow can reappear in the next. If one team manually determines how asset identities align but that logic is not reusable, another team may have to solve the same problem again.
AI increases the stakes. Utilities are increasingly looking to AI tools to analyze information, prepare work, and automate parts of operational workflows. Experienced employees can compensate for integration gaps with institutional knowledge: they know which system to trust, whom to call, or what an ambiguous status really means. AI tools need that context to be consistently available in the data and rules they can access.
Moving data is not enough
Reducing the integration tax therefore requires more than adding interfaces between applications. The goal is to make the information that crosses system boundaries usable for the decisions on the other side.
That starts with identity. Assets, customers, locations, and events need consistent ways to be matched across systems. Shared definitions establish what important fields and statuses mean. Data-quality rules help identify missing, stale, or inconsistent information before it reaches the next workflow. Lineage shows where a value came from, while governance establishes who owns it and who can change it.
A shared data foundation can make those capabilities reusable without requiring utilities to replace the operational applications that teams depend on. Source systems can continue to own their records while governed pipelines, transformations, and data products bring the information together for use across workflows.
The distinction matters. A point-to-point integration may solve the immediate handoff between inspection and maintenance. A stronger foundation can make the identity, definitions, quality rules, and history established for that integration available when the same pole data is later needed for wildfire risk, regulatory reporting, asset planning, or an AI-enabled workflow.
The first integration solves a problem. The foundation helps prevent the utility from paying to solve the same problem again.
Reduce the tax one workflow at a time
Utilities do not need to address every integration gap at once. A practical starting point is one workflow where the tax is already visible.
Business and IT owners can identify a delayed decision and baseline what happens today. How much time is spent finding information, reconciling records, re-entering data, or waiting for clarification? Where does work return to an earlier team because something is incomplete? Which gaps repeatedly require employees to intervene?
From there, identify the smallest set of information the next decision actually requires. Determine the systems involved and the identities, definitions, quality constraints, and ownership rules that prevent that information from moving cleanly today. Then address those gaps in a way that can be reused rather than embedding another workaround in a single workflow.
The result should be measurable in the work itself. In one example, a utility needed to prepare required reports after PSPS events, when staff had to gather weather, outage, de-energization, field-operations, and event-decision data from separate systems. The utility brought those sources together in a single interface, allowing staff to generate content for key report sections and answer routine activation questions without tracking down internal experts.
The larger opportunity comes after the first workflow. Shared, governed data can support additional operational, regulatory, analytics, and AI use cases without rebuilding the foundation underneath each one.
Reducing the integration tax does not mean integrating everything. It means recognizing where work repeatedly slows between systems, correcting the gaps that cause that friction, and making the solution reusable. The goal is simple: when the next team or the next AI tool needs the same information, the utility should not have to pay the same tax again.
About the Author
Alexander Johnson is a Senior Solution Architect at Logic20/20 with more than a decade of experience across data science, data engineering, and cloud platforms. He helps utilities simplify complex data environments and improve decision-making through strong data foundations and applied analytics. His work spans risk modeling, operational analytics, modern data platforms, and machine learning across utility domains.
Third-Party Content Disclaimer
This content was authored by a third party and is published by the Utility Analytics Institute (UAI) for informational purposes. The views, opinions, data, analyses, and statements expressed are solely those of the author and, where applicable, the author’s organization, and do not necessarily reflect the views, positions, or opinions of UAI, its members, partners, or affiliates. UAI makes a good-faith effort to review sources and supporting information provided by third-party authors; however, UAI does not guarantee that the information presented is accurate, complete, or current and assumes no responsibility or liability for errors, omissions, or outcomes resulting from the use of this content. References to specific products, services, technologies, organizations, or entities are provided for informational purposes only and do not constitute an endorsement, recommendation, or implied association by UAI.
