The second AI use case should inherit the first one’s groundwork

Finance connects customer data for a margin review. Sales makes its own copy for account planning. Operations builds a third version for demand analysis. Each project delivers something useful.

Together, they’ve created three identities, three access models and three definitions for the same customer.

It’s a common pattern, and it gets expensive the moment a source system changes. Three teams investigate the same change, update three sets of transformations and explain three different results. Nobody decided the repetition was worth paying for. It just accumulated.

Reuse the meaning, not just the connection

A shared connection to a source is a good start, but it isn’t the hard part. Durable reuse also needs an identity model, agreed definitions, access rules, lineage and someone who owns the exceptions. Hand a team a dataset without that context and they still have weeks of work before it can support a serious decision.

Describe the reusable piece in business terms. An approved customer reference, for example, might include legal and trading identities, the relationships between accounts, how often it updates and how to request a correction. Different teams can then build very different analyses on top of the same maintained foundation.

Keep room for genuine local needs. Finance may need a legal-entity view while sales needs an account hierarchy. Sharing the identity underneath doesn’t mean pretending those views serve the same purpose. The foundation should explain how they relate.

Let the first project prove the demand

Shared platform programmes often fail by trying to anticipate every future requirement. Start instead with a use case that has a named business owner and a measurable finish line. Build only the reusable pieces that decision genuinely needs.

Then bring a second team onto the same foundation. That’s the real test. Can a new team understand the definitions, get the right access and use the maintained records without phoning the original project’s specialists? Reuse demonstrated by a new team beats reuse claimed on an architecture slide every time.

Google Cloud’s research on platform engineering argues for a user-centred approach to internal platforms. Here, the users are the teams building business decisions on shared data. Their waiting time, documentation and support experience belong in your measures of success.

Fund the maintainer, not just the builder

A reusable asset is a permanent obligation. Someone has to absorb source changes, approve definition changes, retire old versions and respond when a consumer finds a problem. Hand that to an unfunded central team and reuse turns into a queue.

Write down the service boundary: what the shared team maintains, what consuming teams can customise and which changes need consultation. Publish how to get support. It can be a short agreement, but people need a dependable way to resolve uncertainty.

Track whether reuse really reduces repeated work, or just moves it. A central service can look efficient while its consumers quietly absorb the delays. Ask both sides where the effort went.

Keep the foundation adaptable

Document the important dependencies and keep export paths practical. UK Government guidance on technical lock-in encourages an explicit balance between the benefits of integration and the cost of switching. Shared foundations deserve that scrutiny precisely because more teams depend on the same choices.

This is the idea behind Akashic: ingestion, entity resolution, modelling and governance as one foundation that many analytics and AI uses can share, with DHIRA’s delivery teams helping set up the responsibilities around it. The business case should still stay specific. Which repeated preparation will the next use case avoid?