[euler_angles]

ALIS. Jesus. What a disaster it was. We had to use it in flight testing and our instantiation was so poor that you literally couldn't use it to order a part. You had to send an email to order parts.

And for the engineering tasks I was doing, there were no good ways to categorize the task, so I eventually gave up and called all the data loads I was doing "LUBRICATION/OTHER". Hey, making the data flow better is a kind of lubrication, right?

I would say "maybe it's gotten better since I used it years ago" but from this article it looks like the answer is a solid "No".

[TheCondor]

What all is it supposed to do beyond parts orders?

[p_l]

In a system like that, ordering parts is one of the least important elements.

It covers things like tracking wear&tear of components so that you know when to replace parts, and more importantly, know when to schedule repairs - it's crucial that you have well-planned maintenance that ensures maximum availability of aircraft, so you need to stagger them - which is non-trivial to do. That's probably the "MVP" level, which to be practical might involve tons of other stuff.

On a predecessor to ALIS for a different plane, even planning a mission went through it - you had someone come to you with requirements, and you'd arrange which plane, which pilots, which technicians to prepare it for flight, where are the tools they need for it, generate a fueling chart, everything based on the availability and qualifications.

Once the plane returned from mission, you'd enter various flight data, including stuff like "how many rounds the autocannon fired" so that the underlying MRP system could calculate maintenance dates and the like.

The ultimate goal is that you have a squadron that has maximum possible availability so it can fulfill its job in the air, without surprise maintenance (or worse - stuff breaking down) foiling your mission plans, and where your stores contain enough of all materiel necessary.

ALIS covered, AFAIK, all elements of logistics for F-35, a giant integrated system. Great on paper as the top level idea, everything got worse the more you got into implementation of the goals. I heard of rebasing where the bringup of local ALIS node took longer than the whole rebased mission. Downloading flight records post-flight would take longer than the flight. Planes that won't fly unless connection with "cloud" part of ALIS (all hosted centrally in USA) was done at least once a month. Gigantic amounts of data you had to transfer between "cloud" and local instance, making it more than problematic to run on ships equipped with F-35B and F-35C.

And of course the fact that data packages describing the operation theater can be generated only by one or two labs in USA (good luck, export customers!)... which is part of the ALIS cloud (and now ODIN cloud), which also is hosted by Lockheed Martin in USA.

Now that I think of it, ALIS explains significant portion of the money USAF puts into Starlink as its only customer...

[euler_angles]

Ordering parts should be a fairly simple thing to get right in comparison to all the other things the system should do. And yet...it failed at that.

[p_l]

True, I think back with the unnamed project I mentioned, we had an idea to do basic automation for that, a button that would send a message on JMS to another system that would print it for the mechanics or in future pass it over to procurement directly.

But we were stuck moving what was supposed to be just deployment into "actually useful for something" state, including rewriting more and more of the code (because L-M license forbid us from modifying their code...)

[euler_angles]

Also as someone who has used the system, you're right about all the other functions it does. Or is supposed to do. So thank you for posting.

[jessriedel]

Your detailed comment is highly appreciated.

[2OEH8eoCRo0]

Can you imagine trying to deal with that crap in an actual hot war when things are happening?