Two connected learning models Explore the linear model at KillChains.com

Industry and acquisition

Why legacy procurement struggles to build kill webs

The acquisition system is optimized for bounded platforms. A kill web derives value from interactions among many independently managed platforms, networks, data services, applications, interfaces, and authorities.

Research basis KW-RPT-005 KW-RPT-010

The unit of accountability is misaligned

Program managers are usually accountable for cost, schedule, performance, certification, and readiness of a designated platform or system. No single program naturally owns the complete cross-service mission thread.

A locally rational platform decision can therefore externalize integration cost onto the joint force: proprietary data, closed interfaces, slow release cycles, separate classification rules, and unique test environments.

Platform model versus mission-network model

AttributeStandalone platformKill-web mission network
Primary valuePerformance and availability of one bounded productEnd-to-end mission outcome across heterogeneous systems
RequirementsRelatively stable thresholds assigned to one sponsorEvolving mission hypotheses, interfaces, data semantics, and cross-sponsor outcomes
DeliveryMajor blocks, lots, and baselinesFrequent software, data, adapter, and policy increments
FundingDevelopment, procurement, and sustainment phasesPersistent product teams spanning build, deploy, operate, secure, and refresh
AcceptanceCompliance with a platform specificationMission-thread performance in representative joint and coalition environments
Data rightsOperate and sustain the platformInterfaces, schemas, test harnesses, build artifacts, adapters, and recompete rights
SustainmentSpares, depots, modificationsContinuous software engineering, vulnerability remediation, API compatibility, and data evolution

Open architecture is a governance capability

An interface is not practically open merely because one vendor documents it. The government or portfolio authority needs implementable specifications, versioning rules, conformance tests, representative data, technical rights, waiver control, and mission-thread evidence.

MOSA can separate stable physical and safety-critical layers from rapidly evolving mission applications, data services, and adapters. Different layers should have different release cadences and certification paths.

Funding and contracts must support adaptation

  • Fund enduring cross-platform products such as identity, data fabrics, adapters, test environments, and integration services.
  • Use modular orders and recurring competitions where interfaces and acceptance evidence are common.
  • Do not confuse a fast prototype contract with an operational transition plan.
  • Price uncertainty honestly and preserve off-ramps, government product ownership, and short acceptance increments.
  • Align incentives so vendors can profit from stewardship, integration quality, and repeatable competition rather than lock-in.

Test the mission thread, sustain the software

Every participating component may meet its own specification while the end-to-end path still fails because of latency, semantic mismatch, security labels, unavailable authority, or release drift.

Kill-web acquisition therefore needs persistent joint test environments, automated evidence, authorization reciprocity where justified, digital twins, representative degraded networks, and teams that remain responsible after initial fielding.

Research basis: KW-RPT-005 and KW-RPT-010.

Answer-ready summary

Direct answers

What does Procurement & Open Architecture cover?

Understand why platform-centric requirements, budgets, contracts, data rights, testing, and sustainment struggle with software-defined mission networks.

Read the supporting page