Picture a single infrastructure project. A stretch of national highway, somewhere in India, under construction. In the physical world, it exists exactly once: one alignment, one contractor, one budget, one timeline.
Inside government, it does not exist once.
It exists at least three times: once inside the ministry that sanctioned and is building it, once inside the platform that presents it to investors and the public, and once inside the office that monitors it against every other infrastructure project in the country. Each version is accurate. Each system is fully operational. And each one describes the project slightly differently — different field names, different identifiers, different classifications, different assumptions about what "current status" even means.
The technology is working. The data exists. The systems are live, funded, and actively used. And yet, left alone, they still cannot fully understand each other.
That is the quiet, unglamorous problem sitting underneath most GovTech integration work, and it is the one this article is about. Not "digital transformation" in the abstract. Not another platform launch. A narrower, harder question: if the data already exists, why is connecting it still so difficult?
The data was there. The common language wasn't.
The problem behind the platforms
The government is rarely short of data. Departments log applications, track budgets, monitor projects, and maintain registries that go back decades. What the government is short of is agreement — on what a field means, which system owns the truth about it, and how a value recorded in one place should be read in another.
This is the real story behind the integration linking the Ministry of Road Transport and Highways (MoRTH), the India Investment Grid (IIG), and the Ministry of Statistics and Programme Implementation (MoSPI). On paper, it reads as a straightforward pipeline: highway project data flows from MoRTH into IIG, where it becomes visible for centralised infrastructure monitoring, and onward into the calculations MoSPI runs to track project performance nationally. In practice, moving that data across an ecosystem covering more than 4,000 projects — the same scale reflected in our MoRTH Dashboard work — meant confronting almost every dimension of interoperability at once: structure, meaning, quality, legacy history, and the business rules each downstream system depended on.
None of this was a failure of any single platform. It was the ordinary condition of government technology: strong systems, built for different purposes, at different times, by different teams, now being asked to speak to one another — the same challenge the World Bank frames as central to a data-driven public sector.
That summary view is what ministry leadership needs: physical progress against target, project counts at a glance, and a weekly report that rolls NHAI, Road Wing, and NHIDCL into one frame. Slice the same stack by agency, and the picture narrows — yearly progress for NHAI alone, regional office achievement, and an issues summary that already hints at how many different clearance systems sit behind a single kilometre of highway.
One project, multiple representations
Here is where the idea becomes concrete. Take one highway project. Inside MoRTH's own ecosystem, it is represented the way an implementing ministry needs it — structured around execution: contractors, stretches, sanctioned cost, physical progress, the operational detail an engineering department accumulates over the life of a project.
Move the same project into IIG, and it needs a different shape. IIG exists to present infrastructure projects for monitoring and visibility at a national level, alongside thousands of others, in a structure built for comparability rather than execution detail.
Move it again into MoSPI's world, and the requirements shift once more. MoSPI is not asking "where does this project stand." It is asking "how does this project's cost and schedule performance compare against its own baseline, and against every other monitored project in the country" — a question that depends on specific, consistently defined inputs.
01
MoRTH
Execution detail: contractors, stretches, sanctioned cost, and physical progress — the record an implementing ministry actually runs on.
02
India Investment Grid
National visibility: a comparable shape beside thousands of other projects, built for monitoring rather than day-to-day engineering.
03
MoSPI
Performance against baseline: cost and schedule inputs defined tightly enough to compare one project with every other monitored one.
Same project. Three legitimate representations. None of them are wrong. None of them are automatically compatible with the others.
Even inside MoRTH, one project does not collapse into a single row. The issues register can surface the same UPC across land acquisition, electricity, and a dozen other blockers — each issue its own record, each one still belonging to the same stretch of road.
Open any one of those rows and the detail panel stacks comments, issue IDs, and related blockers for that package. The project is singular. The data model around it is not.
Interoperability failures rarely come from bad data. They come from good data that was never asked to mean the same thing twice.
Integration is not the same as interoperability
It is tempting to think that once System A can send data to System B, the problem is solved. It isn't. A successful data transfer only proves that a pipe exists. It says nothing about whether the receiving system understood what came through it.
Real interoperability requires more than connectivity. The receiving system has to interpret the structure correctly. Identifiers have to align, so that "this project" in one system is unambiguously "the same project" in another. Master data — the categories, codes, and classifications underneath the values — has to be compatible. Definitions have to be shared, not assumed. Business rules have to survive the journey intact. And any transformation applied along the way has to preserve meaning rather than quietly distort it.
An API can carry a number from one place to another. It cannot decide, on its own, what that number is supposed to mean once it arrives.
That distinction sat at the centre of the MoRTH–IIG–MoSPI work. APIs, scheduled synchronisation, and transformation scripts made the movement of data possible. But movement was never the hard part. The hard part was making sure that once a value crossed from one system into another, it still meant the same thing it meant where it started.
Why data mapping is harder than it looks
On paper, mapping two systems looks like a simple exercise: identify the source field, identify the destination field, draw a line between them. In practice, the difficult question is rarely the line itself. It's what has to be decided between the two columns.
A field that looks identical across two platforms can still represent something different underneath. Does this field hold a current value or a historical one? Which system should be treated as the authoritative source when the two disagree? What should happen when the value is simply missing — is that "zero," "not applicable," or "not yet known"? Are the units the same? Are the classifications the same, or do they only look similar? Does the destination system expect the value in the form it arrives, or does it need to be reshaped before it's usable? And does this value quietly feed a downstream calculation that will amplify any inconsistency several steps later?
01
Same field, different meaning
A column that looks identical across platforms can still mean current vs historical, optional vs mandatory, or a different unit entirely.
02
Whose truth wins
When two systems disagree, mapping has to decide which source is authoritative — and what “missing” is allowed to mean.
03
History that still has to travel
Legacy records carry older classifications and conventions. Migrating them is easy; preserving what they meant is not.
None of these questions show up in a source-to-target spreadsheet. All of them showed up, repeatedly, in mapping MoRTH's project data into structures that IIG and MoSPI could use meaningfully — not because any one field was unusually complicated, but because at the scale of thousands of projects, ambiguity that would be trivial in a single case becomes systemic across the whole dataset.
Legacy records make that harder still. They carry the history of how an organisation used to work — classifications that made sense under an earlier process, fields added or redefined as requirements changed, entries made by different people under different conventions over different years. Migrating a legacy record is a technical task. Preserving what that record actually meant, while reshaping it to fit a new structure, is a much harder one.
Source data rarely arrives ready for the system that needs it next. It has to move through a sequence: mapping, transformation, validation, and only then integration into the target structure, where business rules can be applied and monitoring outputs can be trusted.
Map
Fields correspond in meaning, not just by name.
Transform
Values reshape to the structure the destination expects.
Validate
Master data and gaps are checked before anything lands.
Integrate
Business rules and monitoring outputs can finally be trusted.
Skip any one of those steps, and the integration still "works" in the narrowest sense — data moves while quietly producing outputs nobody should trust.
Why calculations depend on data meaning
MoSPI's project-monitoring work includes calculating indicators such as cost overrun — comparing a project's original sanctioned cost against its current or revised cost. As a formula, this is not complicated. As a number that anyone should rely on, it is only as good as everything that fed it.
A cost overrun calculation depends on a clear, shared definition of "original cost." It depends on "revised cost" meaning the same thing for every project being compared, not a different thing depending on which ministry submitted it. It depends on the underlying project records being consistent enough that the comparison is actually apples-to-apples across a portfolio of thousands.
A formula can be mathematically correct and still produce a misleading result, if the data feeding it was never standardised in the first place.
That is not a MoRTH, IIG, or MoSPI-specific lesson. It is a general one for any GovTech system that calculates something meant to inform a decision: the formula is rarely where the risk lives. The risk lives one layer earlier, in whether the inputs mean what everyone assumes they mean.
The human layer of interoperability
None of the preceding sections happen without people, and this is where GovTech work stops being purely technical. Different departments can read the same requirement differently. A field that one team assumes is optional, another assumes is mandatory. A status value that means "completed" in one office's workflow can mean something narrower or broader in another's.
Resolving that isn't a data cleaning exercise. It's coordination: sitting with stakeholders to understand how a workflow actually runs day to day, clarifying requirements that look settled on paper but aren't in practice, identifying gaps before they surface as broken records downstream, and working across business and technical teams who are, quite reasonably, each optimising for their own system's needs.
That is where the Business Analyst becomes less about documentation and more about translation. The questions that actually determine success are rarely technical in the narrow sense. What does this field actually represent, to the people who fill it in? Which system should be treated as the source of truth when two disagree? How should a value be transformed without losing what it originally meant? What happens to historical records that don't fit the new structure cleanly? Which business rule governs a calculation when two departments have different conventions? How should an ambiguity be resolved, and who has the authority to resolve it?
None of these questions have a purely technical answer. They require someone who can move between the requirement as a government stakeholder understands it, the meaning that requirement carries in practice, the structure a data model can actually hold, and the technical implementation that has to make all of it work — then validate that what was built actually reflects what was intended.
That is the job: translator between people, process, data, and technology, in that order — not just the last two.
Beyond APIs: what real interoperability requires
It helps to separate what "interoperability" is actually made of, because APIs are only one layer of a much taller stack.
Can the platforms technically communicate at all?
Can information arrive in a form the receiving system can parse and store?
Does the receiver understand what the data represents, not just where to put it?
Can data be reshaped between systems without distorting what it means?
Do the calculations and business rules that depend on the data survive the journey?
Is ownership clear — and does that clarity hold as the underlying data keeps changing?
APIs solve the first layer. Most GovTech integration effort, if it's honest with itself, actually lives in layers three through six — the same stack India's Enterprise Architecture (IndEA) guidance treats as foundational for whole-of-government systems that have to share more than endpoints.
When platforms finally understand each other
Go back to where this started: one project, existing in three systems, each one right in its own terms and unable, on its own, to fully understand the other two.
That is not a MoRTH problem, or an India-specific one. It is the default condition of any government that has built more than one working system over more than one decade — which is to say, nearly every government.
The next phase of GovTech will not be defined by how many new platforms get built. It will be defined by whether the platforms governments already have can finally understand one another — not just exchange files, but agree, reliably, on what those files mean.
Interoperability isn't achieved when systems can send data back and forth. It's achieved when what arrives means the same thing it meant when it left.
Further reading
- World Bank — Interoperability: Towards a Data-Driven Public Sector
- World Bank — GovTech: Interoperability Working Group
- OECD — The OECD Digital Government Policy Framework
- OECD — Digital Government Outlook 2026
- UN DESA — E-Government Knowledgebase
- MeitY / NeGD — India Enterprise Architecture (IndEA)
- NITI Aayog (DMEO) — Data Governance Quality Index
- Government of India — India Investment Grid
- Ministry of Statistics and Programme Implementation
