Are Most Data Governance Problems Just Systems and Delivery Problems In Disguise?

Every enterprise has a data governance program. Most of them describe a world that no longer matches how the system actually runs. The policies get written, the data owners get assigned, the stewardship committees meet quarterly. Then a release goes out, a workflow shifts between teams, and the data starts drifting in ways the framework never accounted for. The governance structure stays in place. The data underneath it does not.

Rajesh Ramaswami is an Independent Advisor on enterprise platforms, cloud, and AI. He previously served as Director of Technology at Elevance Health, where he delivered $30M in digital value through AI-driven automation, and spent 14 years at Accenture leading global delivery programs for clients including Microsoft, Ford, and Bank of America. His career spans 28 years of building and running enterprise systems across healthcare, financial services, retail, and high tech.

"When something gets labeled as a data governance problem, it usually started earlier in the system," Ramaswami says. "Most of these systems were built to get the work done. They were not really set up to keep the data clean once it starts moving across teams and workflows." That distinction matters because it reframes where the intervention needs to happen. Governance programs typically layer controls on top of production systems after they are already running. But the inconsistency they are trying to correct was baked in during design and delivery, long before a governance committee ever convened.

• The structural root: Ramaswami traces the problem to how enterprise platforms are built. Systems are designed to move work, not to preserve data consistency as that work flows across teams and release cycles. "By the time governance comes in, it is dealing with something that is already part of how the system runs." The inconsistency is not a failure of oversight. It is an artifact of how the platform was constructed.

• Where intent breaks down: The gap between governance on paper and governance in practice opens at the boundaries between teams. "On paper, ownership looks clear," Ramaswami says. "In practice, a change gets made in one place and the effect shows up somewhere else. That connection is not always visible while people are working." Over time, the org chart says one thing. The data says another.

The consequences compound quietly until something forces them into the open. Reporting conflicts surface during planning cycles. Teams waste time reconciling numbers that should match but do not. Decision-making slows as people lose confidence in the data they are working with. None of these problems look like governance failures on the surface, but they trace back to the same structural gap.

• The AI accelerant: AI makes that gap impossible to ignore. "If the inputs are not consistent, people hesitate before using the output," Ramaswami says. "When they are, teams start using it without stopping to check it every time." The difference between an AI system that gets adopted and one that stalls is often whether the underlying data earns enough trust to act on. Organizations investing heavily in AI capabilities while ignoring the platform discipline underneath them are building on a foundation that will not hold.

• Governance inside the release cycle: Ramaswami's approach treats governance as an engineering practice, not a compliance exercise. "The teams running the system stay responsible for the data as it moves through it. When something changes, it goes through the same release cycle as everything else, so it gets planned, tested, and tracked along with the rest of the work. Nothing sits outside that." No separate process. No parallel structure. Governance moves with the code.

The pattern holds at every scale Ramaswami has worked in, from six-person startup teams to delivery organizations exceeding 1,000 engineers. Governance programs that operate as a layer applied after the system is running tend to decay. The ones that hold are embedded in the same delivery discipline that governs everything else in production.

"What I see people miss is this usually comes up too late," Ramaswami says. "By the time it becomes a governance discussion, the system has already been running for a while and the way data shows up is already set. Teams then spend time trying to deal with it once it is already there." The fix, he argues, is not better policies. It is better platforms, and the engineering discipline to keep them honest from the start.