Why Your Defence Product Must Work With Other Systems

Your product works. It meets the requirement. It may even pass security vetting.

But can it work with equipment made by another company?

In Part 16, Brigadier N. P. Singh (Retd) examined the Ministry of Defence’s framework for testing security vulnerabilities in drones, explaining why cybersecurity, component traceability and ongoing security compliance are essential to defence procurement.

In Part 17 of Defence Procurement: A Practitioner’s Perspective, the discussion moves from security to interoperability — the ability of different systems and components to work together.

Across the earlier episodes, we have explored how the Indian defence ecosystem operates: identifying the actual customer, understanding operational requirements, navigating military planning, choosing development and procurement pathways, understanding financial powers, finding the right entry point for start-ups, and learning from field experience.

This episode addresses an important question for defence technology companies: when the Army asks for an “open system”, what exactly does it mean?

Open interfaces, open-source software, open data formats and modular architecture are four different concepts. Confusing them can lead to costly design and integration decisions.

Using examples ranging from rifle-mounted sights and drone payloads to decision-support applications and military radios, the episode explains why common interfaces matter — and why compatibility alone does not guarantee operational performance.

It also examines five approaches to achieving interoperability:

– Published technical standards

– Practical integration events

– Common software baselines

– Buyer-defined interface specifications

– Problem statements that invite industry to develop solutions

The discussion then turns to Indian defence technology, including efforts to standardise drone ground control stations and reported requirements for integrating existing swarm-drone systems.

For start-ups and established defence companies alike, the implications are significant. A product may need to exchange data with existing systems, accommodate equipment from other manufacturers, comply with software licensing obligations and remain maintainable without complete dependence on its original developer.

The episode also explores a crucial distinction: an open interface does not automatically mean giving away your proprietary source code or intellectual property. Companies need to understand the buyer’s intended meaning, the applicable technical specification and the obligations attached to any open-source software they use.

The practical takeaway is to ask six questions before committing to an integration approach:

– What does the buyer mean by “open”?

– Which interface or specification applies, and who controls it?

– Can other systems use the data your product generates?

– Which open-source licences govern your software?

– Can the user inspect, maintain and support the product?

– Who decides what happens when the interface changes?

Build as if your product will be one of several. In an increasingly interconnected military environment, integration is part of the capability itself.