The authors, logistics officers with recent brigade experience, argue that GCSS-Army, LMP, and IPPS-A are centralized, SaaS-adjacent systems requiring persistent SATCOM connectivity to Army data centers. In a jammed peer-conflict environment, units cannot order parts, update maintenance records, or even verify their own rosters when the link drops — the 'glass backbone' looks robust in garrison but shatters on contact.
The authors prescribe decentralized state, local authoritative caches, offline write queues, and deterministic reconciliation when links restore — patterns identical to offline-first mobile app design. They implicitly acknowledge that these are not novel research problems but engineering practices the Army has failed to adopt.
Frames the essay as 'a distributed systems paper in defense clothing,' noting that Gmail Offline shipped in 2009, CouchDB replication dates to 2005, and Google Docs handles intermittent connectivity as table-stakes. The Army is losing an argument to itself that the local-first software movement resolved years ago.
A new essay at West Point's Modern War Institute, The Glass Backbone: Why the Army's Logistics Will Break in the Next War, made the front page of Hacker News with 224 points. The authors — logistics officers with recent brigade experience — argue that the US Army's enterprise logistics stack is a single point of failure that will not survive a peer conflict against a jamming-capable adversary.
The systems in question are familiar to anyone who's worked in DoD IT: GCSS-Army (Global Combat Support System) handles supply, maintenance, and property accountability for the entire active force. LMP (Logistics Modernization Program) runs depot-level sustainment on an SAP backbone. IPPS-A handles personnel. All three are centralized, SaaS-adjacent, and require persistent connectivity to Army data centers to do useful work. A tank battalion in a jammed environment can't order a repair part, can't update a maintenance record, and can't even confirm who's on its own roster if the SATCOM link drops for more than a few hours.
The authors' term of art is the *glass backbone*: infrastructure that looks robust in garrison, shatters on contact. Their prescription is bluntly familiar — decentralized state, local authoritative caches, offline write queues, deterministic reconciliation when the link comes back. If that sounds like every conference talk about offline-first mobile apps from 2013, it should.
The essay is worth reading not because military logistics is intrinsically interesting to most developers, but because it's a distributed systems paper in defense clothing — and the Army is losing the argument it's making to itself.
Every pathology the authors describe is a pattern developers have solved in production for a decade. Gmail Offline shipped in 2009. CouchDB's replication protocol dates to 2005. Google Docs collaborative editing under intermittent connectivity is table-stakes. The entire local-first software movement — Ink & Switch, Automerge, Yjs — is a mature research program with battle-tested CRDT implementations. Cloudflare Workers, Fly.io, and Deno Deploy have made edge compute a commodity. The Army's problem isn't that the technology doesn't exist. It's that acquisition contracts written in 2008 assumed a permissive electromagnetic environment that no longer exists, and nobody has the political capital to rip up an SAP install to fix it.
The HN commentary was pointed. Multiple threads noted the parallel to airline reservation systems (Sabre) and hospital EHRs (Epic) — critical infrastructure ossified around a single vendor's data model, unable to function when the WAN dies. One commenter with recent 4th ID experience described running platoon-level maintenance on Excel spreadsheets during a NTC rotation because GCSS-Army was slower than paper. Another pointed out that Ukrainian units famously coordinated fires through commercial messaging apps and homegrown Delta situational-awareness tools precisely because the equivalent Western enterprise systems couldn't tolerate jamming. That's the actual benchmark: a shoestring open-source stack outperforming a billion-dollar system of record because it was designed for degraded operations from day one.
There's also a governance point buried in the piece. The Army's authority-to-operate (ATO) process treats every deviation from the centralized system as a security risk, which structurally punishes exactly the kind of local caching and peer-to-peer sync the authors are advocating for. You can't accredit a distributed system when your accreditation framework only knows how to reason about a centralized one. That's a policy problem, not a technology problem, and it's the reason the essay reads as more useful to civilian architects than to the officers it's ostensibly addressed to.
If you build systems that need to survive an unreliable network — and if your customers include any tier-one bank, hospital, or utility, you do — the essay is worth reading as a stress test of your own assumptions.
The checklist is boring and it works. Local-first storage with a durable write-ahead log means the client-side app is authoritative for its own recent writes and can accept new input without a round trip. Idempotent, content-addressable operations mean a reconciliation pass after the partition heals can dedupe and merge deterministically. CRDTs or operational transforms where semantics allow — otherwise, last-write-wins with vector clocks and an explicit conflict UI. Explicit degraded-mode UX: not a spinner, not an error, but a clear indicator that the app is operating on cached state and what capabilities are reduced. Slack and Linear both do this well; most enterprise SaaS does not.
The uncomfortable question for anyone shipping B2B SaaS: what happens to your product during a two-hour AWS us-east-1 outage? If the answer is "our customers can't do their jobs," you've built the same glass backbone the Army built, on a compressed timescale. The Ukrainian counter-example is instructive here too — the winning pattern was not a bigger, more resilient central system. It was a smaller, dumber, replicable one that ran on whatever hardware was nearby. That's a hard sell to a CFO who wants a single throat to choke, but it's the architecture that survives.
For developers with clearance and any interest in defense tech, the essay is also a de facto job posting. Palantir, Anduril, and a handful of smaller Army Software Factory efforts (Kessel Run's model, ported) are actively trying to build the offline-tolerant replacement layer. The skills that transfer are not defense skills. They're the same distributed-systems fundamentals — Raft, gossip protocols, eventual consistency, edge compute — that FAANG interviews have been grinding on for a decade.
The Modern War Institute piece won't change acquisition policy on its own; the Army has been publishing versions of this critique in Military Review since roughly 2018. What's different this time is that the failure mode is no longer hypothetical — Ukraine has provided three years of continuous data on what happens to centralized enterprise IT under sustained electronic warfare. The next Army logistics RFP that fails to specify offline authoritative operation with cryptographically-verified reconciliation should be treated as professional malpractice, not a defensible tradeoff. Whether the acquisition system can actually produce that RFP is a separate question, and the honest answer is probably no. In the meantime, if you're the developer who's already solved this problem for consumer or fintech workloads, the government now has a very large budget and a very acute need. It just doesn't know how to spend it on you yet.
This is a pendulum I've now seen fully swing twice since I enlisted 30 years ago."We need more integrated logistics because the teeth can't fight without the tail!"Some years pass"Why do we have all these non-combat roles in the military? Shrink everything down and focus on
When Russia invaded Ukraine, nobody (even the Ukranians) imagined that 5 years later they would have their own missiles hammering Russia 2500kms in the rear. Americans need to start accepting that a) the Iran war will also probably still be going on in 5 years and b) Iran will probably in a better p
What I am really impressed by is that experts and the army itself is open to criticism and commentary (I am sure there are limits, and censoring will be happening on the more important parts), but coming from a country where the government seems to think that any critique is "anti-national"
These systems are antifragile. Just like what was exposed by the supply chain shock during covid. You optimize like crazy to squeeze every bit of efficiency (I know it's the military, so this is relative) out of a system when times are good / easy. Then the game changes a little and the en
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
A very insightful, and correct, piece.I'll quote in full the following, which I think gets to the heart of the matter. If you have no push, you can't apply pressure to the point.> The notion that amateurs talk tactics and professionals talk logistics is frequently discussed in military