Is there a way to bet that:
That ODIN will be shit too and quietly replaced by, say, the fair maiden GWENDOLIN!?
The US military is dumping its Autonomous Logistics Information System (ALIS) in favour of ODIN as it tries to break with the complex past of its ailing F-35 fighter jet maintenance IT suite. ALIS is the software suite that comes bundled with the F-35 fighter jet. A Lockheed Martin product, ALIS is intended to be a proactive …
So ODIN will give customers 50% visibility, or less once the USAF's realised they've retired the EF-111A and can't find HUGINN or MUGINN. Meanwhile, Russia and China commence a joint project to develop a new EWAR programme, Virtual Automated Logistics Kills Your Rival's Inventory Effectiveness. Which will then be cancelled as it's already obsoleted.
But such is IT. At some point, complexity becomes liability, and the trusty old A-10 looks ever more appealing.
The A-10 could easily outlive its intended replacement (USAF are now looking to keep A-10 for another 15-20 years) because the replacement just don't do the 'actually happening' job any where near as effectively. There is nothing as effective as an A-10 for close air support, ask any infantryman who's had to call in an airstrike during the last 3 decades.
I didn't mean to question the A-10's effectiveness or likely lifespan
Wasn't me. But sadly, I think the A-10's reaching the end of it's survivability. It's one thing fighting in asymmetric environment where it could fly mostly unchallenged.. But I guess the problem now is there are more MANPADs around from Libya, Syria, Yemen etc. And then if proxy wars continue to heat up, what else may be funnelled into Sunni v Shia v Western conflicts.. So although the A-10's a tough old hog, there's a lot of new threats for CAS aircraft to deal with.
"But sadly, I think the A-10's reaching the end of it's survivability. It's one thing fighting in asymmetric environment where it could fly mostly unchallenged"
It's the jet jockeys that have relied on asymetric environments - they believe the A-10 isn't requiredand that they can co-opt the A-10 budgets because it makes no sense in the wars they envisage.
In reality, the A-10 as ground support in difficult conditions against a variety of weapons/opposition forces with very high survivability. While drones can handle some of these missions, a number of questions remain over how the remaining missions would be covered in a post-A-10 world.
My money's on another A-10 refresh to give the USAF a chance to see what F-35's/drones can achieve over a period of time with the A-10 remaining as a fall back - its a relatively cheap option compared to any F-35 alternatives (~$45m vs ~$125m).
The biggest problem is that the role of the A-10 makes it inherently an Army (ground forces) weapon, with entirely different operational requirements and principles from the usual mission profiles flown by the air forces. Which means it's difficult for those in charge who grew in the organisation with fast jet experience to understand the complexities of close air support. It is strange the US armed forces seem to have forgotten the lessons learned from the Vietnam conflict, Gulf war and missions in the Balkans.
The power of the A10 is not just in directly supporting the enemy. Guided bombs from high altitude provide only a short " significant emotional event", the roar of a twin turbofan engine coming over a ridge line and the fart of the gods turning your armoured vehicle to dust leaves a much more lasting impression. Knowing that GAU-8 with wings is flying overhead just waiting to BRRRRRRRRRTTTttttt you out of existence provides much more of a deterrent and a morale boost for those on the other side.
Correction: "The power of the A10 is not just in directly supporting the enemy. "
Should ofcourse read "in directly supporting ground troops". If your planes are supporting the enemy something has Gone Wrong (tm).
I blame a lack of caffeine today. Coffee maker is on the fritz and percussive maintenance only made sure it was actually dead.
It is strange the US armed forces seem to have forgotten the lessons learned from the Vietnam conflict, Gulf war and missions in the Balkans.
Or even WW2 where CAS became a thing and gunships like the good'ol Mosquito were developed. But I guess there's always been politics around the roles (and budgets) for fighers v bombers v CAS v multirole compromises. And then there's stealth.
Knowing that GAU-8 with wings is flying overhead just waiting to BRRRRRRRRRTTTttttt you out of existence provides much more of a deterrent and a morale boost for those on the other side.
That's one of the strange isuses. As a kid I was introduced to the A-10 living near the 81st TFW. I was friends with pilots and crew chiefs who loved the thing. Easy to fly, easy to fix.. And then later events showed it's effectiveness. And it's psychological effects. I've heard reports out of Afghanistan that the enemy would rethink their life choices simply knowing A-10s were on station and ready to remove them from the gene pool.
But I also think some lessons learned helped steer doctrine towards stealth, eg the Package Q mission against Iraq's Tuwaitha nuclear site during GW1 which perhaps shifted strike planning away from conventional aircraft towards the F-117. But then the Balkans showed those aircraft weren't entirely immune to SAM threats. And the tech has moved on, both on offence and defence. I think past & current conflcts have shown a strong need for CAS, and the A-10, or maybe a new, CAS focused replacement. The F-35 seems to have struggled with trying to be all things to all services, with inevitable compromises to it's effectiveness. Some of that may also be political, eg Israel's strikes into Syria and Iraq seem to be conducted with their F-16 & F-15 rather than F-35s, possibly to avoid giving away secrets to Russian & Iranian intelligence.
I'm pretty sure that - maybe a couple of decades ago - anything described as 'Military Spec' was regarded with god-like levels of capability and reliability. These days 'military spec' seems to be about as trustworthy the bloatware pre-installed on a suspiciously cheap unbranded smartphone.
80's Action Film: "We got these from the military" - Cue some awesome special effects and epic stunts...
2010's Action Film: "We got these from the military" - Cue some Windows XP critical error noises...
More seriously, is there some sort of established basic relationship between software complexity and the scale of deployment required to ensure that it remains actively fit for purpose? Clearly military equipment software needs are now complex, but the deployment will always be, by definition, niche.
A couple of decades ago I spent 15 years w**king within the field of Logistic Support for military sytems. I w**ked on the first system that the UKs MOD farmed out to industry to support, followed by the first system that the USAs DoD farmed out to industry to support. I believe that a lot of the difference you've seen is down to the shift from doing the support inhouse, to outsourcing it to industry. But then they only did this because they were sold on the idea of reducing support costs by 80% to 90% ..... because industry could do the same job smarter!
I believe that a lot of the difference you've seen is down to the shift from doing the support inhouse, to outsourcing it to industry.
A while ago, I read the book about the Black Buck operation. In which ISTR a vital bit of a Vulcan's refuelling probe was rescued from a mess room where it was being used as an ashtray, cleaned up, and put back into it's intended service.
Which is probably something unsupported by ALIS.
Which I guess is the problem. It's all gotten horribly complicated with multiple operators, requirements, permissions and an ever changing set of requirements.. Versus an alternative system where stores folks can look up part numbers, then find in a box somewhere.. Possibly involving phone calls to other operators. No idea how many parts are in a typical F-35, but seems a mammoth task to try to log in & track every one, especially if stuff is being continually updated as it's improved or snags found.
I believe that a lot of the difference you've seen is down to the shift from doing the support inhouse
It wasn't just things like support. Back at the start of the 90s I was doing a lot with Unix workstations. HP's new 700 series was popular with the military. I tried taking one to bits once only to find that under the top plastic case was a sheet of metal thick enough to be held down with a huge number of countersunk screws. I asked someone why? Mil-Spec, if it looks like it's the right height for someone to stand on, they need to be able to cope with someone standing on them - In boots.
if it looks like it's the right height for someone to stand on, they need to be able to cope with someone standing on them - In boots.While that might have been the reason, it may have also been to do with TEMPEST (Telecommunications Electronics Materials Protected from Emanating Spurious Transmissions) shielding.
I.e. preventing someone parked outside with a surveillance van with sufficiently sensitive equipment from being able to read the screen and see exactly what's being typed on the keyboard or otherwise work out what was going on from the emitted electromagnetic radiation of operating electronic equipment.
Tanks don't tend to be locations that have HP 700 series workstations sitting in them as to need such solid construction (the workstation, not the tank). ;)
All of the computers (at least in the 80's and 90's) in sensitive miitary facilities (e.g. intelligence buildings) were required to be TEMPEST-rated, otherwise they weren't allowed in the building (speaking from personal experience here).
Er, yes, I know that. Indeed, my back has never fully recovered from when we finally got our new triple 8 inch floppy drive onto its rather substantial bench. It weighed quite a bit more than the CPU.
Advanced technology, those were the days. Compiler in one drive, job control language in the next, programs and data in the third. No disc swapping. We were lucky...
I don't think they were used in tanks, they were used in large numbers by the navy. Same argument, if it's a good height for a step someone will jump on it.
I don' think the TEMPEST rules would have resulted in the thickness of the plating, thicker metal isn't usually needed to make a Faraday cage. The pico amp measurement rig I built back in the 80s had much thinner walls. The front and back of the case had plenty of holes in them. The TEMPTEST spec kit I remember working on wasn't allowed any externals wiring, everything was fibre in and out, even the 9600 baud serial connections.
" need to be able to cope with someone standing on them - In boots"
And then some grunt uses it as a stepladder in boots and a full load of combat equipment on his back, and the spec gets amended once again. Next thing you know the next generation of high tech electronic tank traps goes into service. --> We all know where mil-spec will one day lead us.
Sad to relate but this is nothing new. Back when various countries went into Afghanistan (how many years ago was it?) the UK military was eqipped with a tactical communications system known as BOWMAN. This apparently didn't work too well because the acronym started to mean "Better Off With Map And Nokia" (so that shows how old it is -- back when Nokia was mobile phones). This was when I realized that the resources for the development of a global communications system far outweighed the relatively puny resources one MOD contractor could muster.
As for all singing, all dancing software architecture screwups they've been with us since the mid-1950s, the earliest attempt to build a large piece of software (US air traffic control system) that went belly up. The problem here is that softwre doesn't scale that well -- its riddled with NP-complete problems lying in wait for the careless software designer. We have been able to use hardware performance gains to disguise this over the years but it doesn't make the problem go away, it just means when you do fall into a hole that hole is more like a bottomless pit.
It's amazing just how they manage to beep up these kind of systems, at the core it's really not complicated at all. Keep track of flight hours, part durability and flag up what needs to be done. This base functionality could be cobbled together by mostly anyone in a few days, of course it would not be a fit for release, and adding on preemptive parts ordering could add a few more days, but the basics are really simple, how they manage to bloat it to such a degree it entirely fails is beyond me.
Step 1: Company develops basic system
Step 2: Company attempts to sell system to US military
Step 3: US military requires significant enhancements
Step 4: Company charges extortionate amounts for significant enhancements
Step 5: Sales people complete deal and make enormous bonuses
Step 6: Sales people invest significant revenue in strippers and cocaine
Step 7: Company delivers basic system to military with special stickers on packaging indicating it is now military spec
Step 8: Military wait for significant enhancements to be delivered
Step 9: Goto step 8
No - the military gets a little more careful with spending at this point. Plus the sales people have succumbed to either heart attacks or prison from their lifestyle choices at this point.
The only way to escape the loop is to jump onto another military procurement process and restart from step 1...
Usually, 'Step 6' happens a bit earlier, during the pre-qualification phase - where the vendors invites the military procurement people to various seminars and to observe the pre-qualification vignettes.
Certainly, the only person I know who had a Black Mastercard (and liked to wave it around so I would know that he had it) was our 'Senior Defence Sales Consultant'. This project almost killed the entire team by alcohol poisoning before TG-0 because a Senior Defence Sales Manager' from The Competition had an Amex Gold Card and those two Silverbacks just had to compare dicks, virtualised as spending limits, at the bar and with the strippers!
I think you might be thinking this is a logistics software development issue. If you change your state of mind and think of it more as a government money acquisition system, then it all makes more sense.
Can't you see
It all makes perfect sense
Expressed in dollars and cents
Pounds shillings and pence...
Yeah that sounds about right...
It's a military grade gravely train, with virtually eff all public overnight..
To quote D Rumsfield... *still can't find that $6 trillion*...
Military grade is roughly 15 times more, as evidenced some years later when that figure was reported to be $21 trillion... Although who they're "defending" themselves from is unclear...
So line 4 should be company charge extortionate amount for upgrades to hidden hidden military company front which will disappear 6 weeks after deal is over... But hey just minor details
Icon slightly relevant....
I always fall into the same pit of not being jaded enough. When seen from this perspective it's obvious!
1. Put intern on cobbling together basic functionality time taken 2 weeks, cost ~$0
2. Let jaded developer make sure the software is no longer fir for purpose time taken between 200 and infinity weeks, cost giga$.
3. goto 1
Not only that, the military usually require a lifecycle of 25 years, sometimes longer. The military also requires that the whole production facility is qualified to MIL-HDBK-520 or similar. ISO-9001 will NOT cut it. The military tends to buy all of their needed product ONCE. Then services and upgrades comes in drips and drabs. Maybe.
Basically, the supplier has to price their offers for 2 Golden Years followed by 10 years of Drought - and keeping the documentation, the tooling and those MIL-HDBK-520 certifications 'alive' for the 25 years contractual lifecycle. THAT costs Money!
Ellen Lord, the US Department of Defense's chief arms buyer, told Reuters that ODIN (also an LM product) would be produced "with the voice of the maintainer and the pilots at the forefront of the requirements list."
Will ODIN be any better though? or will get share the same fate as it's predecessor.
Jörmungandr will swallow it whole ... or in half while Fenrir chews its half ...
Of course, ODIN will be replaced by BALDR - Backwardscompatible Autonomous Logistics Defense Requirement, which will in turn be replaced by BALDERDASH - Backwardscompatible Autonomous Logistics Defense Enterprise Requisitioning Database And Security (Holistic). Later, when we are just about to expire from anticipation, it will in turn be replaced by BALDRICK or LORD SLACKBLADDER ... DARLING is too busy, and QUEEN BESS threw it out the window ...
In 1970 the UK military introduced a new set of paperwork that supplemented the original aircraft servicing books.
This actually made sense because in the section for problems (unserviceable, to use the proper term), the size of the corresponding 'here is what we did to fix this' writing area (yes, we actually used pens!) was large enough for about 3 lines of small text; hardly sufficient for the newer (and therefore more complex) aircraft and associated systems.
Some items did not require this new paperwork (an aircraft was declared unserviceable if the toolbox associated with it was checked out and the only response necessary was that the toolbox and all its tools had been checked back in - there were many such types of entry *)
All this was eventually sent off (the forms were multi-page - one page for aircraft records, one page for stores, one page for analysis and so on) to a RAF base in East Anglia where it was manually put into a large and power hungry mainframe to crunch all that information.
Some reasonable usage and spares predictions did indeed flow out of this (although it took a few years for those to become both available and reasonably accurate).
While inefficient, it was somewhat better than what had been done before, but it used up a lot of manhours and doing this properly should (in theory) be a massive time saver (I know - in theory - we are dealing with JPO - the JSF project office - and LM here).
One of the problems now that did not exist in those times is that most failed equipment could be fixed locally in one of the various workshops which is not a viable option today for a lot of reasons; being able to repair equipment on the same base meant that there was usually a stock of spare operational kit available. The concept of having a reasonable prediction of what and how many spares should be on hand is quite reasonable.
Many failed units today are sent back to the manufacturer(s) for repair and the turnaround times can be quite long. (I am not going into the reasons for this as books could - and probably have - been written on this subject).
One type of response is a key item to track - 'No Fault Found' - this costs a lot of time and money and if only those could be resolved it would save a lot of money; the problem here is that the system is trying to be everything to everybody and failing spectacularly at just about everything.
So the concept is great; the execution - well, not so much.
* Everything that was done to an aircraft was (well, was supposed to be - there were some exceptions that got people into quite a lot of trouble) recorded to the point there was a poster on the wall that featured a small child sitting on a potty (I know - that would not be politically correct in these days) with the caption "The job's not finished until the paperwork is done".
Oh lord. We are being asked to make our product 'fedramp' certified. Quite a metric ton of paperwork and books of nit-picking stuff about where debugging logs may be written to and what may be written into them. 100% we are going to charge 100% more for this, and 100% the product will probably not work entirely right as a result of all of these fine changes.
Biting the hand that feeds IT © 1998–2022