Why C2 at the Edge Demands a Different Kind of Software Company
By Danny McGuan | Follow on LinkedIn
There’s a comfortable fiction making the rounds in defense tech right now, and I hear some version of it almost daily: the same enterprise software giants that modernized the Fortune 500 and are trying to modernize government will modernize command and control. Take the cloud platforms and licensing models that transformed enterprise IT, stamp them “defense-grade,” and deploy.
I’ve spent enough time on this problem to tell you plainly: that story falls apart the moment it leaves the data center. And I would know, having spent years working on cloud-to-edge capabilities for spacecraft on programs at JPL and Lockheed Space, as well as on Army and Navy programs.
The Edge Is Not a Smaller Cloud
Enterprise software was built on a set of assumptions. Persistent connectivity. Effectively unlimited compute. Centralized administration. Users who can wait for the next quarterly release. At the tactical edge, not one of those assumptions holds.
Command and control in a contested environment means DDIL conditions: denied, degraded, intermittent, limited bandwidth. Out there, the “cloud” is a ruggedized compute module bolted inside an airframe or a ground vehicle. There is no autoscaling group at the forward edge of the battle area. There is the hardware you brought, the software you fielded, and the mission in front of you.
When an enterprise platform tries to meet those conditions, the seams show fast. Architectures that assume a distant control plane become single points of failure. License servers that phone home become mission stoppers. Update models built on continuous connectivity turn into sustainment nightmares. I’ve watched it happen, and every time, the person who pays the price isn’t the vendor. It’s the operator.
The Incentive Problem Nobody Wants to Talk About
Here’s the part that frustrates me most, because the deeper issue isn’t technical. It’s structural.
Large enterprise software companies exist to maximize the value of their platforms. Their lock-in, their interfaces, their recurring revenue per seat or per core. I don’t say that as an insult. It’s literally their fiduciary duty. But it puts them in direct tension with what the Department of War actually needs: modular open systems and the freedom to swap in best-of-breed capability as the threat evolves.
MOSA isn’t a compliance checkbox. It’s a survival strategy. The force that integrates new capability fastest wins, full stop. A closed platform, or a platform that requires they live at every layer, however polished, caps that speed at whatever the vendor’s roadmap allows.
Ask any platform vendor a question I ask all the time: if a small company builds a better sensor-fusion algorithm next year, how fast can the warfighter get it, and who has to say yes? If the answer runs through one company’s product organization, the mission has a dependency it can’t afford.
What Meeting the Mission Actually Takes
You don’t enter this market with a rebranding exercise claiming to be MOSA aligned (I literally saw a vendor do this in a blog post recently). You earn your way in by building things most enterprise players have never had to build.
It starts with software optimized for specific hardware. Edge C2 lives at the intersection of airworthiness, safety certification, and size, weight, and power. Software that wasn’t engineered alongside the compute it runs on will underperform or fail. This is systems integration, not just software deployment.
It means cloud-native patterns adapted for the edge, not transplanted onto it. Lightweight orchestration that runs headless and disconnected. Deployments that scale from a single module up to a distributed mesh. Virtualization that lets legacy mission software live alongside modern microservices instead of forcing a rip-and-replace nobody can afford.
And it means treating sustainment as a design problem from day one. In enterprise software, sustainment is a support contract. In defense, it’s the majority of lifecycle cost and the difference between a fielded capability and a hangar queen. Software at the edge needs a sustainment model built for how programs actually buy: multi-year structures, predictable cost curves, support tiers mapped to mission criticality.
Add airworthiness releases, Authority to Operate in disconnected enclaves, and cybersecurity that assumes nation-state adversaries, and you start to see the price of admission. None of it shows up on a product roadmap. You learn it by doing the work alongside program offices, year after year.
The Companies Built for This
So what does solving this actually look like?
At Parry Labs we built our mission software the way the edge demands, not the way the data center permits. It runs fully disconnected on the SWaP-constrained compute already flying, floating and rolling in the force today. No console to phone home to, no license server to stall the mission, no control plane eating half the module. And it’s open by design, so when that small company builds the better sensor-fusion algorithm, the program office can integrate it in weeks without asking our permission. Yes, I mean that literally. The next fight will be decided by whoever closes the sensor-to-decision loop fastest in an environment built to break it, and the architecture you pick today is either the thing that closes that loop or the thing your adversary targets to keep it open.
This is the work we get to do at Parry Labs, and honestly, it’s why I love this job. We grew up inside the defense mission. We treat open architecture as both product principle and company philosophy, not a procurement concession we grudgingly accept. We measure success in capability fielded, not seats licensed or cores counted. When the architecture is open, competition happens at the level of capability, and the best capability wins. I’ll take that fight every day of the week, because that’s the fight that serves the warfighter.
The mission doesn’t wait for a data center. It shouldn’t have to wait for a vendor’s roadmap either.