During the First World War, the British Army progressed tanks from concept in 1915, to combat employment in 1916, to 2,600 units having been manufactured in 1918. Just over a hundred years later, technology and threats are evolving even more rapidly, especially when it comes to military systems involving Command, Control, Communications and Computing (C4). So when recent C4 projects have taken over a decade to deliver such systems for use on operations, how confident can the Australian Defence Force (ADF) be that it will be able to sense, decide and act faster than its potential adversaries? And how could Defence do this better?

What do we need to do? The 2016 Defence White Paper (DWP16) says the ADF needs to be able to defeat and deter armed attacks on Australia and its interests. In the C4 space, it comes down to transporting and processing, command and control, situational awareness and targeting information faster and with better quality than the adversary.

Does the Capability Life Cycle give the flexibility required to deliver capability in an agile manner? A casual reader would contend that statements within the Capability Life Cycle (CLC) indicate an absolute ability to generate the flexibility required. Statements such as ‘highly flexible risk-based process which is tailored for each proposal’ do not; however, identify the cultural and organisational barriers that emerge from a system that has been process led for a number of years. There is also the question of accountability that must be addressed; this could mean more engagement early and often, but more routinely means more briefs, meetings and focus on committee gates. In order to generate the responsiveness required from the CLC, there needs to be close consultation with all stakeholders, including industry; our ability to build trust in delivery relies on delivering the effect promised to government, as a direct benefit of the investment made.

The existing CLC supports the introduction of new capabilities, but must be employed in a flexible manner. The four phases of the CLC are:

1. Strategy and Concepts,
2. Risk Mitigation and Requirements Setting,
3. Acquisition, and
4. In-Service and Disposal.

In a traditional project approach, each phase is conducted in sequence. The approach required to generate the flexibility required to maintain pace with emerging technology is programmatic in nature and at the completion of Phase 1 (Strategy and Concepts), there is an acknowledgement of the requirement to iterate from Phase 2 (Risk Mitigation and Requirements Setting) through Phase 3 (Acquisition) and Phase 4 (In Service and Disposal) for an undefined period of time. There should only be a requirement to return to Phase 1 when the strategic requirement, or concept by which the capability will be delivered, has changed. Fundamental to this approach is well-defined standards and architectures that deliver flexibility in product selection, not tied to a specific vendor solution.

How fast do we need to acquire new capabilities or refresh existing ones? It could be argued we currently focus on the technological life of type of our current systems, and move just fast enough to replace them before they are obsolete.  Is it more suitable to focus on our potential adversaries and try to outpace their adoption and adaptation to new technologies? There are two possibilities this could lead to. If adversaries cannot or do not adopt technologies quickly, we may not need to always keep pace with the latest technology – we just need to be faster than our competitors. Conversely, if emerging technologies can be adopted by state and non-state actors more rapidly than our current processes allow, does that mean we don’t have the C4 capabilities to meet the tasks mandated by DWP16? If the answer to this last question is ‘yes’, then we need to understand how to generate more tempo to acquire or refresh the ADF’s capabilities.

How could we do this? There are several requirements for generating the tempo required:

• Establishing an ‘open architecture’ framework. The foundation of the success of the mobile telecommunications industry is the establishment of the standards and protocols that are supported within their networking environment. Clearly defined requirements allow any vendor to produce a product that can establish itself as a point of presence on that network with a degree of assurance that it will not create integration or interoperability issues. These seamless data flows between varieties of end user devices are the foundation of the most connected generation in history. Nobody wonders if they will maintain the same level of connectivity if they move from one smart phone brand to another; can we say the same in the military context?

• Articulation of the Main Effort within the capability. Integration across platforms delays the progress of C4 projects, especially when project schedules are not aligned, requiring decisions to be made either prematurely or out of order. This could be mitigated through defining a main effort, and sequencing the acquisition of subordinate capabilities to come later. Using Army as an example and more specifically, the Combat Brigade as the capability, defining a main effort (e.g. dismounted combatant, tank or network) would allow the acquisition process for supporting capabilities to commence after the interfaces and standards for the main effort have been defined. If these interfaces and standards are supported by the open architecture framework, then a diversion from a specific vendor in future acquisition activities should not introduce significant integration issues.

• Threat awareness. Know who to we are trying to be faster than, what C4 technology they are adopting, how they would use it, and how quickly they can adapt their doctrine and training. We must be organisationally postured to advice on threats and risks to our systems. Current acquisition approaches do not necessarily support a dynamic change pre-delivery, so we must be smarter in the way we plan for software and hardware updates, including the use of Artificial Intelligence and Machine Learning algorithms that enable ‘self-protection’ from external and internal influences.

• Technological awareness. Know what technology the adversary, our allies, and our own forces might adopt, and how it could be used and how often does it evolve? Enduring partnerships with industry will allow Defence the ability to sense and respond to technology evolutions with more agility. The use of Australian Defence Industry as defined by the Defence Industrial Capability Plan may increase the trust Defence can put in the answers we get; sovereign industry may also be more responsive to our requirements to rapidly adopt emerging technologies when compared to foreign vendors.

• Military off the shelf. Procurement of developmental solutions, regardless of the context, introduces cost and schedule risk into projects. While pursuing “best of breed” solutions for military systems is common, a decision to pursue an 80% solution which is on time, on budget and proven by our coalition partners is worthy of serious consideration. Chase ‘good enough’ quickly rather than ‘gold-plated’ too slowly.

This article was co-authored with Major Matthew Penney and Major Nathan Jones.