In the past six months, UK Defence has demonstrated it can move fast: 10,000 small drones fielded by the Army, autonomous mine-hunting deployed to the Strait of Hormuz, loyal wingman contracts placed with British firms, and UKDI standing up with £400m to push drones and counter-drones into service at pace. The shift from exquisite, decade-long platform programmes to rapid, attritable and disposable systems is real. But making these systems interoperable, integrated, and fielded at scale still takes far too long, and it's not because the technology doesn't work.
Acquisition is accelerating. Integration and sustainment aren't
The DIP includes the right kind of investment to deliver on the vision: £7.5 billion for the Digital Backbone and Digital Targeting Web combined. This is money that should absolutely be spent on integration, interoperability, and data-sharing. But are the delays, overspend, or cancellations we routinely see in defence programme delivery the result of poor technology choice? I suspect not.
Why has MoD felt the need to create jHub, DASA, and Taskforce RAID as separate organisations, rather than fielding the work to delivery organisations like DE&S or Defence Digital (now NAD Materiel and Digital & Data)? You don't build parallel org structures unless you've accepted the existing machinery can't move at the tempo required. These innovation organisations are doing excellent work, but their creation is itself an admission: that the pace of innovation and change demanded by recent conflicts could not currently be delivered by MoD's existing teams. And to be clear, this is not a people problem. The problem is process: procurement, contracting, assurance, DLOD alignment, all inflating timelines and budgets beyond the value of the capability being delivered.
Three problems the DIP can't solve with money alone
Speed. The problem starts before a line of code is written. Acquisition itself can take months to years, with competition processes, evaluation boards, and commercial frameworks that are ripe for transformation. But even once a contract is in place, assurance and governance processes remain overwhelmingly manual, sequential, and committee-dependent, blocking progress from development through to fielding.
One innovation team we work with had to extend a contract with their supplier by 50% because the assurance process consumed the time allocated for actual development: not for production, but fourteen approvals required just to get authority to test (ATT), no board available for a month, user testing pushed back by two months. Assurance, Architecture, Defence Line of Development (DLOD) readiness all evidenced through document-heavy reviews. Nobody is saying these checks are unnecessary. But the way they're implemented creates huge bottlenecks in capability delivery, and this will only worsen as MoD looks to award more contracts to SMEs who may be unfamiliar with the process, putting increased strain on the small number of reviewers who can approve a solution.
Scale. When Operation Epic Fury kicked off earlier this year, US AI systems went from baseline to an estimated 20 billion tokens a day—a 4,425% surge overnight. Could UK infrastructure do the same? MoD has a credible plan for cloud at OFFICIAL and already runs many systems there. But those systems are not regularly tested for surge, and experimentation is rarely evaluated through the lens of exponential demand.
Cross-domain solutions remain hardware-based, deployed in tiny clusters, with limited throughput. Cloud hosting at higher classifications is constrained by UK datacentre capacity and CNI vulnerabilities. The question isn't whether we've adopted cloud. It's whether we've planned for what happens when demand explodes overnight. Hyperscalers are spending over $700 billion on infrastructure this year so their customers can scale without predicting demand in advance. We should be asking how to access that elasticity, not trying to replicate it ourselves.
Efficiency. We can't pre-build for wartime scale, and we can't sustain it in peacetime. So we have to get smarter: building minimal operating capability rapidly, with clear financial and procedural approaches to scale-up defined at requirements stage. But we also need to be honest about productivity. We write code for months that modern development tools could produce in days with proper governance built in. Documentation takes weeks that could take minutes. We spend millions on point-in-time security assessments when continuous automated testing would give better coverage for less money.
All of this exists today, and the barrier isn't the technology. It's an operating model and assurance culture that hasn't caught up. And the evidence is systemic, not anecdotal:
• Morpheus: over £828 million spent, contract terminated, nothing fielded.
• MODNet Evolve: rated RED by the IPA ("successful delivery appears to be unachievable").
• NSoIT contract: suspended in 2017 as a £900 million fiasco, now being unwound years later.
• Programme Cortisone: initiated around 2018, spent six years in assessment, and only began entering delivery in 2025.
• HR/payroll migration: a 21-month project that started in 2019 and still wasn't complete by mid-2023.
These aren't isolated failures. They're the predictable output of a delivery model that hasn't kept pace with modern digital system delivery approaches. The current system appears to incentivise compliance over pace, and process adherence over outcomes. This is not a matter of blame, but we must recognise where we are to move forwards.
What needs to change
The technology works. The system around it doesn't - not at the pace or scale the threat demands. Governance takes longer than the projects it governs. Infrastructure can't surge. Dependencies are unclear, and the PACE (Primary, Alternate, Contingency, Emergency) plan hasn't been written.
This isn't theoretical. Netflix regularly injects failure into production systems through chaos engineering, proving their ability to scale and continue operating through major global outages. Monzo's "stand-in" architecture provides a credible PACE model: graceful degradation to core services when primary systems are unavailable, designed and tested in advance rather than hoped for in crisis. These organisations build assurance, resilience, and scale-up into the pipeline, not around it. The same approach applies to defence.
At Digital Defence Leaders 2026, Stephen Quigg and I will set out what an alternative looks like, drawing on Amazon's own experience and the global enterprises we've supported through similar transformations: organisations that have learned to build security, sovereignty, and resilience into how teams actually work, rather than bolting them on afterwards. The parallels with Defence are closer than most people in the sector realise.
Speed, scale, and efficiency are achievable. But only if we change the operating model, not just the equipment.
Tim Lawrence
C4ISR Specialist, Amazon Web Services
