A military IT system is not just an IT system. But it is not necessarily as exotic as we sometimes make it out to be.
Much of the technology will be entirely familiar to anyone working in enterprise IT: servers, networks, compute, storage, identities, applications and communications. In other respects, military IT may have more in common with operational technology (OT), particularly familiar from the energy sector, critical infrastructure and manufacturing.
Military technology must support a physical, operational capability that may remain in service for decades. It does not just have to work in a data centre. It has to work as part of a tank, an aircraft, a headquarters or a deployed unit. And that changes some of the assumptions, including those associated with conventional IT and OT.
It has to work even when parts of it do not
A system may, for example, need to operate somewhere that had no infrastructure half an hour earlier. It may need to provide a usable core function even when the connection back to the rest of the organisation is lost. It may need to withstand failures in parts of the system.
And unlike most conventional enterprise environments, we must also account for an intelligent adversary actively trying to detect, disrupt or destroy our ability to communicate and operate.
In other words, it has to work even when parts of it do not. That has consequences for the architecture.
For me, it always starts with the operation
What are we actually trying to achieve?
It sounds obvious. It should also be the starting point for any good enterprise architecture. But in defence projects, it becomes particularly important because the consequences of optimising for the wrong thing can be significant.
Users may describe the solution they already know rather than the effect they need. Conversely, technical specialists may build a technically excellent solution without fully understanding the operational reality in which it must function, or the constraints imposed by other legacy solutions with which it must integrate.
Both can lead to an architecture that solves the wrong problem or fails to deliver the intended effect.
That is why I am far more interested in effects than features. What must the soldier, staff or unit be able to do? Under what conditions? How quickly? And what must keep working when something else does not?
Only then should we discuss the technology.
More is not necessarily better
Every additional function and technical dependency can come at a cost in terms of training, spare parts, troubleshooting, logistics, specialists or external support.
Complexity may well be necessary. But it should be justified by the operational effect it delivers.
Security must be part of the overall capability
The same applies to security. The most secure system on paper is not necessarily the best military system.
If security controls make a solution so difficult to use, or so dependent on other systems, that users cannot carry out their task, we have not necessarily created a better capability.
That does not, of course, mean security is secondary. Quite the opposite. It means security, accreditation, interoperability, logistics, resilience and operational usability must be designed as parts of the same capability. Not as separate problems to be addressed afterwards.
That may not be an unfamiliar idea, particularly for security professionals. But logistics, supply and mobility are probably considered less often. And perhaps that is precisely where the difference lies.
Military IT is not just about building a good IT system. It is about building a military capability in which IT is an integral part of the solution.