"Modernising Defence" - a mini-review

MDP Headlines in full:

1) It’s a bad, bad world out there. In fact, it’s badder than we thought, and keeps getting badder.
2) Some of our stuff is a bit old and rubbish, so we need to modernise it. We’ll need to prioritise though, because we’re a bit skint.
3) Some guff about innovation, cutting-edge technology and investment
4) We’ve been thoroughly seen off by the Treasury, because we don’t deliver vote-grabbing headlines about hospitals. Because of this, there’s not much more to say - but we’ll get a bright fast-streamer to pad this out with lots of waffle and stock photos.
5) Oh look - a plastic prototype plane and a new lab at Porton Down! Quick, nick that, and write it up like this is really part of a new plan...


Sent from my iPhone using Tapatalk
 

Sarastro

LE
Kit Reviewer
Book Reviewer
The problem with our IT is that so much of it is so poor and unfit for purpose. If we want to be information agile, we really do need to sort our IT/ICS out. That WILL cost some serious money!
Disagree. Yes, of course I agree that the IT is (abysmally) poor and (totally) unfit for purpose. But sorting it out doesn't need to cost some serious money.

The primary problem that UK public sector IT has is the procurement and development model. It goes for bespoke proprietary software every time, for incredibly long and onerous contracts, and only hires huge organisations with strong records of failure behind them. This has been proven not to work, consistently, for decades. Moreover, it is based on three requirements which do not, at all, match the models of success in the external software industry, where software is increasingly: non-proprietary (e.g. has a large base or % of open source software), iterates every few years, and built by comparatively tiny groups or firms.

There was a US Defence procurement model in the 1960s-1980s, for experimental airframes and perhaps more, which was totally different. It tendered small contracts, regularly, for short periods of time, offered R&D money up front, and the contract was awarded to those who could produce working prototypes. The result was, long-term, that it got a range of rapidly evolving, groundbreaking technology that worked, managed to iterate it every 5-10 years, and got it at an incredibly low cost compared to (for example) mainstream fighter airframes from the 1980s onwards. Look into the history of Skunk Works and similar for the story.

That is what is needed for IT procurement today, simple. The external tech industry already exists to support it, it is (broadly) in our national sphere (if you count the US), and it is remarkably cost-efficient. It's the procurement process that is utterly unfit for purpose. As an example, there was a competitive tender notice that went out about a year and a half ago from DE&S that fit, almost perfectly, something I was working on. It was never going to be picked up by a small company because: a) the amount of initial investment offered was pitiful, and b) it demanded the rights to sell the IP worldwide. Those two demands, together, rule out 100% of the startup / small tech company world. Either you, the investor, need to stump up all the money (e.g. the angel model), or you need to accept that the company you are part-investing in will have to attract other investors: since their sole asset is their IP, no other investors will accept a partner investor being given IP rights. Therefore demanding that a software company surrender their IP rights is unworkable unless you completely fund them (even then it causes problems, as I've seen elsewhere). So you are back to writing a blank cheque for a bespoke product that doesn't exist yet.

I understand why those terms exist - they are a blanket contract designed for large joint venture contractors like BAE, so that the UK can sell Typhoons or whatever after investing heavily in the program. DE&S even point out this is their "standard" one-size-fits-all contract. It is totally misjudged for software procurement. As a result of it being designed for large contractors, the only companies it suits are large contractors. Thus every IT project ends up becoming ATLAS, because even though that is the precise opposite of what is required, they are the only people who can support the business model.

Additionally, I've heard various staff officers blather about how the projects need to be huge to ensure "compatibility". Horseshit. Pretty much every Defence system uses some form of OTS operating system. Pretty much every OTS operating system has one purpose, and that is to solve "compatibility" standards. It is a problem that was effectively solved twenty years ago by a range of different platforms, and is now a development and maintenance problem for developers, not system architects. Arguing, or accepting the argument, that "compatibility" requires a large single organisation to build all your software only demonstrates how technically ignorant most of the people in Defence procurement actually are.
 
The problem with our IT is that so much of it is so poor and unfit for purpose. If we want to be information agile, we really do need to sort our IT/ICS out. That WILL cost some serious money!
I think the biggest problem is having three or more systems on your desk. All GSC’d at a different level. Interoperability is difficult. ImpEx is often the only way due to air gaps. ImpEx up, normally not a problem. ImpEx down can and often does cause problems. All allied to the ‘need to know’ compared to the ‘need to share’. Add three or so phones, again at different GSC.

Add the training burden and a desk officers job can be a tad difficult imx :)
 
There was a US Defence procurement model in the 1960s-1980s, for experimental airframes and perhaps more, which was totally different. It tendered small contracts, regularly, for short periods of time, offered R&D money up front, and the contract was awarded to those who could produce working prototypes. The result was, long-term, that it got a range of rapidly evolving, groundbreaking technology that worked, managed to iterate it every 5-10 years, and got it at an incredibly low cost compared to (for example) mainstream fighter airframes from the 1980s onwards. Look into the history of Skunk Works and similar for the story.
Having started in defence avionics in the late 1980s, you're missing a rather significant detail. Namely, that it didn't work (at least not for software, which is rather the point). Half of all DoD software projects of the era you mention, failed to deliver anything near a working product. This was the driving force behind the Software Engineering Institute and the Capability Maturity Model; Project STEELMAN that gave us the ADA programming language; and DoD-STD-2167 (and successors). These initiatives were all launched in the late 70s / early 80s because of the weaknesses in the approach you propose - they had wasted billions on poorly-specified, poorly-designed, and poorly-managed projects.

Essentially, the DoD couldn't afford "uncontrolled agility" when it came to software - so they imposed a development standard that everyone chose to implement as "waterfall"...

...imagine someone standing up in Parliament and stating "We're about to spend a couple of billion on software, and we know that half of it will be wasted. We just don't know which half..."? Not really going to happen.
 
Last edited:
Uncle Sam's Misguided Children seems to be looking at procurement in a very different way for their new Armoured Recon vehicle - though jury is still out on whether it will work.
Marines Want Armored Recon Prototypes By 2023: F-35 On Wheels Or FCS Redux?

In essence they seem to have retained the ownership of the project and engaged a plethora of bidders, rather than go to a major prime and have whatever is ready on their store shelf sold to them as tweaked to what the client wants
 

New Posts

Latest Threads

Top