Enterprise systems for a defence research organisation

Context

Delivering into a defence research environment inverts several assumptions that hold in commercial projects.

Fit-to-standard, the usual starting point, has limits here — a statutory approval chain is not a process inefficiency to be optimised away. Cloud deployment may be unavailable regardless of its technical merits. And the audit trail is not a by-product of good design but an explicit requirement that shapes the data model.

Why the constraints shape the architecture

In a commercial engagement, non-functional requirements are often negotiable — a latency target can soften if it costs too much to hit, an uptime figure can be relaxed in a long tail of edge-case hours. A defence-research mandate does not offer that flexibility. Data residency, classification handling, personnel clearance, segregation of duties and audit retention are set externally and are non-negotiable; the system either satisfies them or it does not exist.

That inversion changes where the engineering effort lands. More of it goes into the authorisation model, the audit trail and the documentation layer; less goes into optimising workflows that look inefficient but are actually codifying statutory process. The resulting system looks heavier than a comparable commercial build — and is that way on purpose.

How we worked

We treated the constraints as the architecture rather than as obstacles to it. Security and residency requirements were established before design, not reconciled with it afterwards.

Documentation received unusual weight. A system expected to run for fifteen years will be operated by people who have never met the team that built it, and the quality of the handover determines whether it remains maintainable or becomes something nobody dares change.

Authorisation and audit

The role-authorisation model was built around the segregation-of-duties matrix first and the functional organisation second — the opposite of the shortcut most commercial builds take. Every transaction that touches classified or regulated-sensitive data writes an immutable audit record; every configuration change goes through a documented review and sign-off before it reaches production. The audit layer is not a by-product; it is a top-level architectural component.

Procurement and approval chains in-system

Statutory procurement and approval workflows were encoded faithfully rather than simplified into a generic approval matrix. That means the system reflects the real process — including approval levels specific to classification bands, the distinct handling for indigenous versus foreign procurement routes, and the audit evidence those routes have to produce for later review. The operator sees the process they already know, delivered by the system rather than around it.

Documentation as deliverable

Every design decision, configuration rationale and workflow choice is documented in a form intended to be useful to a team that has not met the people who built the system. That scope of documentation is the practical bridge between a project team that is paid by the hour and a system that is expected to run for a decade and a half after handover.

What generalises

The pattern — constraints as architecture, authorisation and audit at the foundation level, documentation as a first-class deliverable, long-horizon maintainability as the test of success — generalises to any public-sector, defence, regulated-industry or long-horizon enterprise mandate. The specifics of DRDO’s procurement chain are particular; the engagement model that respects them is not.