The Hidden Cost of Fragmented Data: A Conversation with Thirupathi Reddy Anneda

Every large enterprise runs on data that lives in too many places at once. Forecasting pulls from one source, planning from another, finance from a third, and each connection gets built by hand, one interface at a time. The result is a web of point-to-point links that nobody fully understands and everybody depends on. The market for fixing this is large and growing fast, climbing from $17.58 billion in 2025 toward $33.24 billion by 2030. Most of that money goes toward connecting systems rather than simplifying them, which leaves the harder question unanswered: can a company shrink its data plumbing and get faster at the same time?

Thirupathi Reddy Anneda has spent his career inside that web. He is a Senior Technology Lead with more than 18 years in enterprise data engineering, currently responsible for the data platforms behind a Fortune 500 technology company's global supply chain. He is also a Senior Member of the IEEE, a distinction recognizing experienced engineers who have demonstrated significant professional accomplishments. Anneda has also served as a judge for the Globee Awards for Achievement, evaluating enterprise technology work across industries. For years his focus has stayed on a problem most organizations would rather not look at directly: the slow accumulation of redundant pipelines that quietly raise costs and erode trust in the numbers everyone reports against. 

We spoke with Thirupathi about why point-to-point integration breaks at scale, how he consolidated more than 1,000 interfaces into a single governed hub, and what still keeps enterprise data harder than it should be.

Most companies treat data integration as a plumbing problem. Why does that framing fail at enterprise scale?

Because plumbing implies the pipes are the point. They are not. The point is trust. When 20 or 30 applications each pull the same data from the same upstream systems, you do not have integration. You have duplication wearing a costume. Every team builds its own feed because that is the fastest way to ship, and for a while it works. Then you wake up one day with a thousand interfaces, six copies of the same master data, and nobody who can tell you which copy is correct.

That is the real failure. The same fact now has multiple versions, and people start making decisions off whichever one they happen to query. I have watched two planning teams argue for an hour about whose number was right when both numbers came from the same source three hops back. Point-to-point integration does not scale because trust does not scale that way. You cannot bolt confidence onto a system after it is built. You have to design for one version of the truth from the start.

You led a project to consolidate that sprawl. What did you actually build?

A central data mart. The idea was simple to say and hard to do. Stop letting every application subscribe to upstream systems on its own, and put one governed layer in the middle that everyone draws from. We went from more than 1,000 point-to-point interfaces down to around 300, reducing the number of maintained interfaces by more than two-thirds.

The shape was hub-and-spoke. One inbound subscription layer, owned by a single team, pulling granular data once and then publishing pre-aggregated views out to each downstream application. Before that, every team ingested raw data and ran its own roll-ups, so the same aggregation executed 20 times across 20 systems. We did it once, centrally, and served the result. Storage across the landscape dropped 30 to 40% because we stopped keeping identical records in 6 different places. None of that is glamorous work. It is the kind of thing that only gets noticed when it is missing.

Walk me through the hard architectural decisions. What did you have to get right?

Two things, mainly. The aggregation standard and the migration sequence. Defining the aggregation standard was the harder challenge, because more than twenty applications all wanted the data at slightly different grains. Pick the wrong normalized level and you either store too much and lose the savings, or you aggregate too early and break an application that needed the detail. We settled on a granular base layer with a pre-rolled layer on top, so the systems that needed raw detail kept it while everyone else consumed the lighter version.

The reason this matters is cost, and not the cost people expect. Poor data quality costs the average organization $12.9 million a year, and most of that is not dramatic failure. It is quiet inconsistency. Two reports that disagree. A planner who hedges because the system burned them last quarter. A forecast built on a stale copy. When you collapse everything to one governed source, the storage savings are the smallest part of it. The real gain is that those disagreements stop happening before they reach a decision.

What nearly broke? Migrating live production systems is not forgiving.

The cutover was the part that kept me up. You are replacing the data backbone underneath 20 applications that are running in production, serving a global supply chain, and cannot go dark. There is no maintenance window large enough to do it all at once, so doing it all at once was never on the table.

So we phased it. The enterprise warehouse feeds first, then the secondary interfaces, then the application-to-application feeds last, because those were the most entangled. We built the retention and purge logic before the forward pipelines, which feels backwards until you realize that granular data accumulates fast, and if you have not decided up front how long you keep it, you drown in your own success. The other hard part was human. Five delivery tracks, each with its own timeline, and a cutover decision that needed all of them aligned on the same day. The technology was solvable. Keeping five teams moving in step was the actual work.

Outside your day job, you spend time judging early-stage AI builders. What does evaluating work at that stage teach you?

It is a useful corrective. Judging the Builders of Tomorrow AI Super Hackathon, you see a lot of teams reaching for the most advanced model they can find before they have defined the problem they are solving. The strongest teams were almost never the ones with the fanciest architecture. They were the ones who could tell you, in a single sentence, exactly what inefficiency they were removing and for whom.

That maps directly onto the data work. The instinct in any technical field is to add. Add a model. Add a layer. The harder and more valuable instinct is to remove, and to treat subtraction as a feature rather than a compromise. The best engineering I have seen, in a hackathon or in production, comes from people who get satisfaction out of deleting a system nobody needs anymore. Most teams skip that step, and it costs them later.

You’ve evaluated technical work across a lot of teams and industries. What separates the projects that hold up from the ones that do not?

The ones that hold up are honest about their constraints. I have read plenty of project write-ups that describe a perfect outcome and quietly skip the tradeoffs. I trust the ones that tell me what they gave up. Every real system is a set of compromises, and the teams that can name theirs are usually the teams that actually built something.

The other pattern is ownership. There is a difference between a team that connected some systems and a team that took responsibility for what the data means. The second kind is rarer than it should be. Across industries, the projects that age well are the ones where somebody decided that being the single source of truth was a job worth owning, not a byproduct of the architecture they happened to inherit.

Where does enterprise data integration go from here?

Toward fewer and smarter connections, not more. The pressure now is AI readiness, and every team that wants to put a model on top of its data is discovering the thing I spent years on. The model is the easy part. The hard part is whether the data underneath it is consistent enough to trust. Operations and supply chain are among the fastest-growing segments of the integration market right now, expanding at about 15.74% a year, and that is no accident. It is the area where bad data shows up immediately, as a wrong delivery promise or a missed allocation.

So my focus stays unglamorous and specific. Keep collapsing redundancy so there is one version of every number that matters, and make the governed layer good enough that the next team building an AI feature never has to ask where the data came from, because it is already correct. The companies that win the next decade will not be the ones with the most data. They will be the ones whose data does not argue with itself.