Open Data Infrastructure
Open Data Infrastructure Procurement Scorecards
A buyer scorecard for open data claims across table formats, catalogs, metadata portability, policy controls, workload mobility, and exit evidence.
Every vendor can say "open." Buyers need a way to score what the word costs after the contract is signed.
Buyers need proof, not slogans
Open data infrastructure procurement should evaluate control. Can another engine read the tables? Can another catalog understand the metadata? Can lineage leave the platform? Can policies be expressed outside one product? Can workloads move without losing meaning?
The scorecard should not ask whether a product mentions open standards. It should ask which standard, which version, which API, which export path, which metadata fields, and which operational proof the vendor will commit to.
Score the control surfaces
Start with table format, catalog protocol, metadata portability, policy control, lineage, workload mobility, cost transparency, and exit testing. Apache Iceberg provides an open table specification. The Iceberg REST Catalog specification defines a catalog API boundary. Polaris shows how an Iceberg REST catalog implementation can organize catalogs, namespaces, access, and storage configuration.
That does not mean every buyer needs the same architecture. It means the buyer should be able to ask precise questions and compare evidence instead of comparing adjectives.
Core idea: an ODI procurement scorecard turns "open" from a vendor claim into testable buyer evidence.
Exit evidence matters before exit
For related ODI guidance, read the ODI buyers guide, data infrastructure exit strategy, and ODI exit tests for platform mergers.
The scorecard should require a sample exit. Export a table. Move a workload. Preserve lineage. Recreate a policy. Prove the catalog boundary. If the vendor cannot demonstrate that path during procurement, the buyer should assume the path will be expensive under pressure.
What breaks first
- The platform stores data in an open format but keeps metadata in a closed model.
- Catalog access works only through vendor-specific extensions.
- Lineage can be viewed but not exported in a useful structure.
- Policy controls depend on a proprietary identity and rule engine with no migration story.
Scorecard questions
Ask for the table spec, catalog API, metadata export, policy model, lineage export, supported engines, workload migration proof, and exit test. Good vendors can answer with documentation and demos. Weak answers arrive as roadmap language.
Sources to start with
These primary sources anchor the technical claims in this guide.
- Apache Iceberg table specification
- Apache Iceberg REST catalog specification
- Apache Polaris documentation
- OpenLineage object model documentation
The best procurement question is not "Is it open?" It is "Show me what I can still control when I leave."