How to Build the Business Case for Open Data Infrastructure

A business case for open data infrastructure cannot sound like a love letter to open standards. Finance does not fund architecture vibes.

Start with business outcomes

The business case should start with outcomes the company already cares about: faster AI delivery, lower migration risk, fewer duplicate data products, safer data access, better auditability, and less dependency on one vendor roadmap.

That framing matters. If ODI is presented as a technology preference, it becomes optional. If it is presented as a way to protect strategic data assets and reduce future change cost, it becomes a business control.

The first slide should not say "Iceberg." It should say "we need more control over the data layer that AI and analytics now depend on."

Build the ROI model from avoided work

ODI ROI is often about avoided work. Count the cost of duplicated storage, repeated data movement, custom connectors, private metadata rewrites, manual governance reviews, and platform-specific migrations.

Then add the upside: faster onboarding of new engines, safer agent access, easier cross-domain data products, and a clearer exit path if a vendor or strategy changes.

• Baseline the current cost of moving, copying, and reconciling important data.
• Estimate the labor spent rebuilding metadata, lineage, and access controls across tools.
• Identify AI use cases blocked by governance, context, or data access problems.
• Map the first ODI pattern that reduces those costs without boiling the ocean.

The executive deck needs one architecture picture

Executives do not need every component. They need the control model.

Show the data plane, catalog/control plane, governance layer, compute engines, and AI context layer. Then mark where the organization has open contracts and where it depends on private behavior. The picture should make the tradeoff visible in 30 seconds.

Fund the pattern, not the platform rewrite

The safest funding ask is a pattern. Pick one valuable domain, publish one governed open table, register it in the catalog, attach lineage, document access, and prove another workload can use it without a custom copy.

That creates evidence. Evidence beats a 40-slide transformation deck every time.

If the first pattern works, expand it. If it does not, you learned where the architecture is lying.

Sources to start with

These are the primary sources I would start from when checking the claims in this piece.

• NIST AI Risk Management Framework
• OpenLineage documentation
• Apache Iceberg REST Catalog specification
• Apache Iceberg table specification