The Cost of Fragmented Data Formats in Indian Defence

In 2018 the Indian Army shut down its Battlefield Management System. The Army had approved it back in 2007 to give every frontline unit a shared digital picture of the battle. Two Indian consortia built prototypes. Then the Army priced equipping its 800-plus combat units at Rs 50,000 to 60,000 crore, and the money went to rifles instead.

So the problem wasn’t the technology. It was the bill.

Why it got expensive

BMS was the bottom layer of a bigger plan. In 2004 the Army started Tac C3I: a hub called CIDSS in the middle, with separate systems for artillery, air defence, surveillance and frontline units hanging off it. There was no common data model, so every vendor built against the hub on its own terms, and nothing could go into service until the hub did. Thirteen years later the surveillance system was still waiting, and the only one fielded was the artillery system. Each new sensor meant another custom integration. Each one added years, and years cost money.

How software solved it

Google hit a version of this early. Its 2010 Dapper paper describes tracing a single request across thousands of services, and the authors admit it was easier for them because Google’s environment was “blessed with a certain degree of homogeneity”. Most companies don’t get that luxury. They run tools from multiple vendors, and each tracing vendor used to pass context between services its own way, so the picture broke wherever two vendors met. The Army has the same problem, with Indian, Russian and Israeli kit running side by side. The people behind OpenTelemetry called hand-instrumenting every service a non-starter. When two open standards showed up to fix it, the bigger problem turned out to be that there were two. They merged in 2019.

Once there’s a standard, you integrate a new service once, not once for every system it talks to. That’s what makes observability cheap enough to be normal.

Defence is catching up

Defence is heading the same way. In December 2024 Anduril published the Lattice SDK, the data model and APIs you’d need to plug your own hardware into its platform. This June the US Army chose Anduril to lead the common data baseline for NGC2. There’s a catch, though. Anduril owns Lattice. Nobody owns OpenTelemetry. If India writes a standard, its services should own it.

India has already seen what fusion buys you. The Army plugged Akashteer into the IAF’s IACCS a few months before Operation Sindoor, and air defenders worked off one recognised air picture. That was one integration between two systems, done by hand. A standard is what lets you do it a hundred times. The surveillance system from the 2004 plan was finally flagged off in January 2025, 21 years on, as Sanjay.

What a standard won’t fix

A standard won’t fix fusion on its own. A web request carries its trace ID. An enemy truck doesn’t, and the enemy will jam your radios. That’s real engineering. It doesn’t change the maths on cost.

What brings the cost down

You need two things. A data model for sensors, weapons and tasks that the services own and every vendor has to speak. And adapters for the systems the Army already fields, whoever built them. After that, adding a radar is just another purchase.

The Army has prototyped a fused view before. It couldn’t afford to field it. A standard is how you make it cheap.