Open Data Infrastructure
Governance Is Infrastructure, Not Compliance Theater
Governance works when policy, lineage, access, quality, and auditability become normal platform behavior.
Most governance programs fail quietly. Not because the policies are wrong, but because the policies live in a place the actual data systems don't have to obey.
The Problem
Governance often starts as documentation. A policy is written. A catalog entry is created. A review process exists. Everyone agrees the data should be trusted, controlled, and explainable.
Then the real platform starts moving. Pipelines ship. Tables change. Access grants get copied. Agents need context. A new engine enters the stack. Suddenly governance is a meeting, not a mechanism.
That is the wrong shape. Governance has to move into the infrastructure that reads, writes, shares, discovers, and explains data.
What Infrastructure Means
Governance as infrastructure means the system can do the work without relying on tribal memory.
- Access rules are evaluated where data is retrieved.
- Catalogs expose ownership, schema, policy, and table state.
- Lineage is captured from jobs and transformations, not reconstructed by hand after something breaks.
- Quality signals are available to systems that need to decide whether data is safe to use.
- Audit records show who accessed what, through which path, and under which policy.
The goal is boring, in the best possible way. The right behavior should be the default path.
The ODI Angle
Open data infrastructure changes governance because data doesn't stay inside one clean product boundary. It moves across storage, catalogs, engines, AI tools, data products, and external sharing patterns.
Core idea: governance only scales when the control layer is portable enough to follow the data across tools.
This is where ODI gets practical. Open table formats help preserve data meaning outside one engine. Catalogs coordinate metadata and permissions. Lineage standards help capture what happened across jobs. Metadata platforms make ownership and context queryable.
Failure Modes
The weak version of governance looks fine until the platform gets real traffic.
- A policy exists, but only one application enforces it.
- A catalog has descriptions, but the runtime path never reads them.
- Lineage exists for pipelines, but not for AI answers or downstream decisions.
- Quality checks create dashboards, but agents can't use the signals.
- Data sharing bypasses the controls that made the data safe in the first place.
These aren't governance failures in the abstract. They're architecture failures.
The Operating Model
Use a simple split. Platform teams own shared controls: catalogs, identity integration, policy enforcement points, lineage capture, and audit paths. Domain teams own meaning: definitions, owners, quality expectations, and acceptable use. Governance teams own the rules and the evidence required to prove those rules are working.
That structure keeps governance close to the work. It also makes the platform easier to inspect when something goes wrong.
Sources to Start With
These primary sources are useful starting points for the standards and systems behind governance as infrastructure.