The Next SI is a Software Integrator
The Next SI is a Software Integrator
We must ship features at the speed of the mission
Software is eating ate the world. Future government programs won’t succeed with just a Systems Integrator (SI) but will also require a Lead Software Integrator. The F-35 is a flying computer. A Tesla car is a software-defined vehicle. Anduril is a software company, not a hardware company. Systems integration is a process dominated by hardware specifications, managing sustainment, and billable hours. Software integration is instead code to manage rapid iteration and abstract away complexity. The latter scales in a way the former never will.
The future fight necessitates scaled systems. There will be hundreds of thousands of distinct environments that require continuous software delivery, each with different constraints and dependencies. Beefy data centers, cloud, unclassified, top secret, SAP - anything goes. Every robot is an environment. Every node in the 1st and 2nd island chain is an environment, as is every ship, plane, and helicopter. Even a solider is a point of presence. It is the Software Integrator’s job to ensure this complexity doesn’t get in the way of winning.
Here’s how to tell if a company is performing the job of a Software Integrator or if they’re just a Systems Integrator in disguise: if headcount scales linearly with environments or nodes, they are a Systems Integrator who calls their billable hours “software engineering.” If headcount is relatively constant, the company is a Software Integrator using software to enable integration, enforce security, and absorb the shocks, stressors and volatility from operating in a complex environment. It is the difference between integration-as-billable-hours and integration-as-code.
Attempts by the military-industrial complex to transubstantiate the Primes into software-first companies have not succeeded. The legacy Systems Integrators don’t know how to sell software to the government, the government barely knows how to buy it, and Agile and DevSecOps have been poorly applied to old processes. The primacy of the Software Integrator is evident, and the commercial world provides a cautionary tale for what happens when there is a reluctance to embrace this role. Legacy conglomerates and manufacturers have hired hundreds of thousands of software engineers and committed hundreds of millions of lines of code with little to show for it. Take General Electric's digital transformation effort with Predix, or Toyota’s troubled Woven Planet software city. HSBC once proudly said they had more software developers than Oracle. Ford built a huge software engineering department. VW started CARIAD to build automotive software that would rival Tesla, but has been delayed in realizing results as they’ve worked to assemble the right team to execute on their mission.
Defining Systems Integrators vs Software Integrators
The traditional Systems Integrator optimizes for exact management of schedule, performance and cost with well-defined interfaces and processes. The Software Integrator optimizes for eliminating bottlenecks and ensuring the pebble is in the right shoe. The first line of defense for the Systems Integrator is people and processes. The first line of defense for the Software Integrator is - you guessed it - software, delivered via an organizational and technical architecture that scales to ensure every supplier (both hardware and software) moves at the speed of the mission.
The Software Integrator has two objectives:
Enable a diverse and competitive ecosystem of suppliers to compete and win at the speed of necessity, not requirements. The barrier to entry with software is lower than it is for systems, so new vendors can quickly be brought into a program to prove their mettle. Compare this with the multi-month (often multi-year) process to onboard new vendors to a program with a Systems Integrator. Software provides continuous competition, continuous integration, and continuous delivery.
Enable systematic visibility into performance for the government through software. Government Purpose Rights (GPR) interfaces and well-defined software primitives ensure MOSA compliance and application level interoperability by default. The most crucial aspect for all this to work is that each vendor must be Operationally Responsible.
The Software Integrator doesn’t build the program’s software. It builds and operates the infrastructure that runs and delivers the program’s software.
And it does so by enabling the underlying software providers in the program to be Operationally Responsible (OR). Under this OR framework, the group that builds the software is responsible for operating the software and supporting it as-a-service.
This incentive alignment is critical to serving the warfighter. When software doesn’t work, the OR developer gets paged, morning or night, weekend or weekday. The pebble is in the right shoe. In return for being responsive to bugs and suboptimal features, vendors are rewarded with maximum surface area to innovate in how they develop, manage, and deploy their software. Rather than wait for requirements from the DoD dictating how a problem must be solved, vendors send their team to the frontlines to incorporate warfighter feedback in real time. OR not-so-subtly shifts the focus from requirements to outcomes.
To illustrate, let’s walk through a notional example of how this works. A forward deployed engineer from one of the many vendors on a Software Integrator program is iterating with users at a Combined Air Operations Center (CAOC). The vendor has built a target-effector pairing application and is operationally responsible for its deployment at the CAOC. Users want the ability to create tactical support requests for engagements against targets (e.g., asking for additional assets, munitions, or effects). To implement this new feature, the engineer heads to their rental car in the CAOC parking lot, opens up her laptop, and works for an afternoon.
The typical Systems Integrator would take months to implement this feature. With a Software Integrator providing enabling infrastructure, the vendor with the target-effector pairing application will be able to deploy the newly coded feature to users within 24 hours.
The Software Integrator provides automated testing and validation to ensure continuous integration during development. For example, every code commit must be signed with a valid GPG token assigned to the developer, ensuring the code was authored directly by the signer of the commit.
Prior to deployment low-side, there is a tiered approach to reinforcing checks that ensures software is secure and complies with the pre-defined software supply chain specifications. There are automated deployment, update, and recall procedures in the Software Integrator’s continuous deployment pipeline. To avoid downtime, upgrades are rolled out incrementally. Any recalls through this process will immediately redirect traffic to the non-recalled versions, ensuring upgrade safety and continued quality of service.
A version of this process repeats when it is time to deploy the feature high-side. Service binaries are packaged on a 4-hour cadence and transferred to SIPR and JWICS after the service version upgraded healthy on the “stable” channel. Throughout this process, the Software Integrator’s infrastructure continuously monitors performance, stability, and security via real-time telemetry mechanics to advance the authored change to the warfighter in an automated fashion.
Later that same day, the software vendor rolls out the new feature to the CAOC. During an exercise, a user requests an advanced medium-range air-to-air missile (AMRAAM) to replenish depleted supplies and demonstrate a targeting of a notional electronic warfare site.
Implications for Hardware
Metal must still be bent. Production matters. Using up ten years of munition production in ten weeks in Ukraine underscores that point. But increasingly, production is itself software-defined and optimized. Despite earlier examples, there are plenty of commercial enterprises that have successfully leveraged software to improve production without undertaking in-house digital transformations:
Panasonic Energy of North America (PENA) makes its batteries in a jointly operated Tesla gigafactory.
When the A350 production was struggling to ramp, CEO Tom Enders turned to Palantir and our software to reduce defects, improve quality, increase yield, and improve subcomponent assembly performance — 1000 lead bullets fired through a software barrel by a Software Integrator.
bp optimizes hydrocarbon production with software, yielding $3bn/year of incremental production.
Eaton uses AI for a 25% increase in productivity and the ability to dynamically prioritize material shortages.
And Rio Tinto uses software to increase production efficiency in its mining operations.
The value of software extends to the Defense Industrial Base (DIB), where two primes use Palantir to optimize their own production. But this is the exception, not the rule. Government incentives play a big part. A U.S. shipbuilding company left improved productivity on the cutting room floor because it would adversely affect their revenue and profits in future recompetes for the contract, which they were confident they would win. Because of government-regulated margins, the shipbuilding company would be penalized for increased efficiency. This is exactly the wrong math to be doing when China’s shipbuilding capability is reportedly 200x greater than our own.
Nobody believes software companies can flip a switch and become hardware companies (Palantir doesn’t build radios for TITAN; we rely on world-class technology from L3H). Many industrial software companies sold the vision but fell short of becoming software companies. We still need our Primes, but we also need new Software Integrators.