Executive summary: Reusable data products can accelerate delivery while creating dependencies across applications. Shared definitions, tested changes, and clear maintenance ownership help teams manage those dependencies. The practical test is the effort required to deliver another trusted answer and support it in production.
The data behind a successful analytical solution often has uses beyond the application it was built to support. Ingestion pipelines, standardized entities and relationships, curated datasets, business metrics, and semantic models may all support additional applications. Each new use case calls for a selective approach to data reuse. Shared components should reduce repeated engineering and improve consistency, with application-specific logic retained where needed.
When teams independently reconstruct entity relationships, transformation rules, and calculation logic for each application, development effort grows and interpretations may diverge. Reconciling conflicting answers becomes another maintenance obligation. AI applications and agents add further demands, requiring reliable inputs and explicit definitions of the data and calculations they consume.
Treating shared datasets and models as data products means maintaining their definitions, quality, and usability for multiple consumers. Validation across data layers, documented dependencies, and explicit maintenance responsibilities support consistent analysis and efficient delivery as requirements evolve.
Align data platform investments with operational priorities
Download our white paper to explore how utilities can establish trusted data foundations, integrate analytics into daily operations, and measure the benefits of data platform investments.
We will never sell your data. View our privacy policy here.
Standardize the relationships. Preserve the analytical context.
Shared entity definitions and relationships give applications a consistent basis for analysis. Consider a utility using asset and geographic data for operations, regulatory reporting, and planning. Each application needs consistent associations between assets, locations, and service territories. Establishing those relationships in a governed data model supports exposure analysis, territory-level reporting, and mitigation planning through common spatial joins.
Shared relationships do not require every calculation to reside in the same layer. Two considerations help guide placement decisions:
- The metric’s business definition
- Its dependence on application-specific filters or analytical context
A work-completion percentage, for example, may change as users filter a report by team, location, or time period. Defining the calculation as a measure in a shared semantic model lets multiple reports use the same logic, with results reflecting each report’s filters and drill-through selections.
Document each metric’s business definition, formula, dependencies, and implementation layer, including the reason for choosing that layer. Developers can then reuse the measure, adapt it for another context, or extend the shared model.
Rebuilding resilience: A data-first approach to risk management
Explore how a utility integrated operational data and analytics to improve reporting, risk visibility, and decision-making across its service territory.
Keep upstream changes from becoming downstream surprises
A source-system replacement tests the assumptions embedded in shared data models. New field names, revised asset identifiers, or changes in record structure may affect several applications through a single upstream dependency. The engineering effort extends from updating ingestion connections to verifying the resulting data across downstream models.
Layered architecture provides boundaries for managing that work. Connection or format changes may be addressed upstream while preserving the structures consumed downstream. Changes to entity definitions or source relationships may require revised mappings and transformations across multiple layers.
Validation at each transition helps identify omissions or unintended changes before they reach consuming applications.
- Completeness: Expected records and required fields survive ingestion and transformation.
- Relationships: Entity mappings remain valid, with missing associations or unexpected duplicates identified.
- Transformation results: Derived values and aggregations conform to documented rules.
- Business reasonableness: Changes in key measures are reviewed against prior results and known business changes. An unexplained shift in territory assignments or high-risk asset totals warrants investigation even after technical checks pass.
Record counts alone offer limited assurance. Matching totals may conceal incorrect associations, while a changed total may reflect a legitimate source correction. An asset-count change in a regulatory report, for example, could originate in a revised inventory, a mapping error, or a different reporting scope. Lineage and calculation dependencies help engineers locate the cause. Validation at each layer provides evidence linking source records to the final report, giving business users a basis for trusting the revised results.
Don’t let reuse become a support bottleneck
A change to shared transformation logic may affect several applications with different reporting cycles and release schedules. Teams need named owners to assess the effects, coordinate releases, and resolve issues.
Ownership needs to cover the handoffs between teams:
- Source owners communicate changes to production data, including revised structures, definitions, and refresh schedules.
- Platform teams maintain ingestion and transformation processes, assess downstream dependencies, and validate technical changes.
- Consuming teams define application requirements and validate outputs against their business use.
Those responsibilities need a repeatable delivery process:
- Define the business purpose and expected data behavior.
- Implement and test the change.
- Validate the outputs with the business.
Documentation and quality checks form part of the release criteria, keeping definitions and dependencies current with the deployed service.
An additional application may need little new transformation code but require stricter refresh requirements, extra validation, or support on a different schedule. Before onboarding it, teams need to agree on escalation paths, assign responsibility for investigating issues, and estimate the support capacity required.
Is every new use case adding to your engineering backlog?
Identify opportunities to reuse data models, reduce reconciliation work, and establish ownership as more applications depend on shared data.
Give AI the context behind the numbers
AI introduces additional consumers of shared data, with distinct requirements for structure, granularity, and interpretation. A foundation designed for applications and reports may need further preparation to support machine learning, natural-language analysis, or agentic workflows.
A reporting model may aggregate information that a machine learning workload needs at the record level. Model development may therefore draw from standardized, granular datasets or curated analytical models, depending on the task.
Similar column names can conceal important differences between measures. On a utility project, similarly named “tree count” fields represented contract quantities, actual counts, averages, and regional estimates. An AI application could select a plausible field yet answer a different question from the one intended.
Metric documentation needs to distinguish actual, estimated, and forecast values, along with their time periods, sources, and calculation rules. That context helps the application select the appropriate measure. Testing sample questions against expected results helps verify response accuracy.
Agentic workflows extend the design question from interpreting data to using it within a sequence of tasks. An agent preparing an analysis and an agent initiating an operational action may require different data freshness, permissions, and review arrangements. Shared services supply governed inputs and definitions; the intended workflow determines the additional controls required.
Build organizational capabilities in data science
Learn how technology alignment, standardized development practices, and a data science center of excellence can support analytics delivery across teams.
Make the next use case part of the investment case
Shared models, validation, documentation, and ongoing support require investment that may exceed an individual application’s budget. Securing sponsorship requires a business case that connects those capabilities to reduced delivery effort, fewer reconciliation demands, and reliable service across multiple applications.
Start with a business process that has a measurable data problem. A reporting team’s recurring reconciliation work, for example, provides a baseline for estimating potential savings. Related use cases can help identify worthwhile shared capabilities before sponsors commit to a broader implementation.
To estimate potential savings, account for repeated effort in three areas:
- Data preparation: Time spent recreating mappings, joins, and transformations for related applications
- Reconciliation: Effort required to investigate conflicting definitions and results
- Troubleshooting: Time spent tracing dependencies and diagnosing source or processing issues
Potential savings need comparison with the cost of developing and sustaining the shared service, including testing, monitoring, release coordination, and consumer support. Existing effort provides evidence for an estimate; reductions remain projections until demonstrated in use.
Measured changes in delivery time, reconciliation effort, and support demand give sponsors evidence for subsequent investment. Confirmed requirements from additional consumers then guide the scope and capacity needed for expansion.
Do you need more AI use cases ... or a better starting point?
Find out why starting with existing operational workflows helps organizations prioritize investments and turn data and AI capabilities into measurable outcomes.
Reused pipelines are only part of the equation
Reusing existing pipelines can leave teams with substantial reconciliation and support work. Measuring the engineering effort saved across development and maintenance gives a more complete assessment of the benefits of data reuse.
Differences in application scope matter. A complex operational application may require more engineering than a report, even with a well-designed shared foundation. Rebuilding equivalent mappings, definitions, or validation rules is a clearer indication of avoidable effort.
For data architects and engineering leads, the distinction guides investment: recurring requirements make a stronger case for shared capabilities, while specialized needs may justify separate implementations. Successful reuse delivers another trusted answer with less repeated engineering and a support commitment the team can sustain.
Ready to support more use cases without multiplying engineering effort?
Let’s explore opportunities to strengthen your shared data foundation, reduce repeated development, and plan for ongoing support as demand grows.
Learn more about reusable data products and data foundations
The year AI breaks through: 3 trends data leaders can’t ignore
Why data quality, clear ownership, and scalable governance are essential to building durable data foundations that support AI and long-term business value
End-to-end data strategy: A guide for decision makers
How data architecture, governance, operating models, and business priorities work together to sustain shared data capabilities across applications
Essential elements of a successful data strategy
How quality management, clear ownership, and measurable business outcomes help organizations sustain the value of their data investments
Matt Kieffer is a Manager in Logic20/20’s Advanced Analytics practice. He has over 10 years of experience turning complex data into actionable business insights, with a background spanning energy, technology, and government sectors. Matt holds an MBA in business analytics and specializes in cost modeling, regulatory reporting, and strategic decision support.
Alistair Nevell is a Manager in Logic20/20’s Advanced Analytics practice, where he specializes in automation, process optimization, and digital transformation. He brings deep expertise in cost modeling and data-driven decision-making, with experience designing scalable AI and automation solutions for both government and commercial organizations.