Open Data Infrastructure
Open Data Infrastructure Readiness Reviews
How readiness reviews inspect table ownership, catalog control, policy portability, lineage coverage, workload exit paths, and AI consumption risks.
A platform can have modern components and still be unready for open data infrastructure.
Readiness is not maturity theater
Readiness reviews are useful only when they inspect real control points. The review should not become a workshop where every team scores itself as almost done. It should examine evidence.
Open Data Infrastructure readiness means the organization can prove who owns the data, which table formats and catalogs control access, how policy moves, where lineage is captured, what exit paths exist, and how AI systems consume context.
The review should inspect control
A practical review covers table ownership, open table format posture, catalog authority, policy portability, lineage coverage, workload isolation, cost visibility, data product contracts, and AI consumption paths. Each area should have evidence, gaps, and a next action.
The review should also separate readiness from ambition. A team may want open infrastructure. That does not mean its current metadata, policy, and workload evidence can support it.
Core idea: ODI readiness is the ability to prove control before modernization pressure arrives.
ODI readiness needs proof
The review should use primary evidence from catalogs, table metadata, policy systems, lineage tools, logs, and workload inventories. Apache Iceberg documents open table metadata. Polaris and OPA show catalog and policy control patterns. OpenLineage can capture dataset and job relationships.
For adjacent context, read the ODI maturity model, the ODI scorecard, and ODI exit tests for platform mergers.
What breaks first
- The review counts tools instead of inspecting evidence.
- Ownership exists in an org chart but not in catalog metadata.
- Policy is portable in theory but tied to one platform identity model.
- AI consumption is reviewed after data products have already become agent dependencies.
Questions to ask
Ask what the organization can prove today, what would fail during a platform move, and which AI workloads depend on fragile data assumptions. Ask which gaps block action and which are acceptable risks.
Sources to start with
These primary sources anchor the technical claims in this guide.
- Apache Iceberg table specification
- Apache Polaris access control documentation
- Open Policy Agent policy language documentation
- OpenLineage object model documentation
Readiness is not what the roadmap promises. It is what the evidence can prove today.