Open Data Infrastructure
A 12-Month Roadmap to Open Data Infrastructure
A quarter-by-quarter plan that maps ODI adoption to measurable platform control, not vague modernization goals.
An ODI roadmap is not a list of tools to buy. It is a sequence of contracts to own, and the operational habits that keep those contracts durable.
Roadmap principles
Most ODI programs fail for predictable reasons: they start too broad, they treat governance as committee work, or they confuse “open” with “lots of open source.”
Use three principles instead:
- Own the contract layer first: table formats, catalog boundaries, and governance enforcement points.
- Earn trust with one domain: ship one end-to-end slice that people use.
- Make evidence a requirement: lineage, auditability, and ownership metadata are not optional in production paths.
Core idea: ODI adoption is a control program, not a modernization program.
Quarter 1: define contracts and pick a pilot
- Define what “open” means for your organization using the ODI scorecard.
- Pick one domain with clear value and manageable risk.
- Choose the contract layer: open table format, catalog boundary, and a minimum governance model.
- Establish a repeatable validation routine for correctness and governance coverage.
Quarter 1 ends when the pilot domain has a credible contract definition, not when a vendor demo looks good.
Quarter 2: operationalize governance and metadata
- Make ownership, classification, and access policy part of normal dataset onboarding.
- Put policy enforcement in the query path for the pilot domain.
- Capture lineage events for critical pipelines.
- Document and test runbooks for incident response and rollback.
Quarter 2 ends when teams trust the pilot path and can audit it.
Quarter 3: expand domains and portability
- Add two to three additional domains using the same contract and onboarding model.
- Introduce a second engine or compute path to prove portability.
- Formalize maintenance ownership for compaction, retention, and table health.
- Track unit economics for storage, compute, and movement, and review them with FinOps discipline.
Quarter 3 ends when portability is demonstrated in practice, not in slide form.
Quarter 4: make ODI the default
- Make the open contract path the default for new durable datasets.
- Set exit requirements for new platform commitments and enforce them.
- Scale governance automation so compliance does not require heroics.
- Introduce “exit drills” for one critical domain to prove the architecture stays movable.
Quarter 4 ends when ODI is normal behavior, and teams feel the pain of violating it.
Sources to start with
This roadmap is an operating model, but ODI depends on durable specs and evidence standards.