Around a decade ago, there was a big push by some acquisition leaders to Own the Technical Baseline (OTB). OTB was the process of maintaining deep, independent understanding and control of a system’s design, performance, interfaces, risks, and evolution so informed decisions can be made throughout its lifecycle. The goal was noble and understandably reactionary after the disastrous TSPR period. The problem was that the prescription is wrong in light of expanded opportunities from new industry players and improved digital processes to ease complex integration activities. A better approach today is to Own the Supply Chain (OSC).
Problem
The overall problem with the OTB concept was that it placed way too much emphasis on the government understanding every intricate design detail that it drove PMs to become too focused on the process (endless design reviews and CDRL monitoring) and less on the outcomes. In essence, they started missing the forest for the trees. The results showed too as program outcomes did not improve following the period that OTB was implemented. PMs were also on a doomed mission with OTB because most acquisition teams do not have equitable knowledge with industry to challenge them on detailed engineering points especially not in emerging tech areas.
New Approach
The good news is that PMs today don’t need to own the baseline, they just need to understand their options for the piece parts that comprise a capability. When paired with an intelligently applied MOSA framework, this approach can relax some of the focus that PMs and Chief Engineers had placed on laborious design reviews and instead focus on technology scouting to identify the next candidates for an upgrade. This can include major subsystems or even components that add new functionality or resiliency to an existing system.
Collectively, the OSC mindset and supporting processes helps move the acquisition process from being a siloed program (single capability) viewpoint to a broader horizon of supply chain opportunities that can drive the fielding of faster capabilities.
This also gets us closer to an adaptive acquisition system that can handle the dynamic threat changes like we’ve seen in Ukraine and that we will likely face against a peer adversary. It provides the structure to stay ahead of the technology curve that DoD has in the past usually been at least a generation behind on. It also gives DoW a rare opportunity to start leveraging the talent of small businesses who do not have the resources to build an entire system but might be able to revolutionize a piece of it.
To implement this approach, there are a few key concepts that have to be recognized.
1. Understanding the System as a Supply Chain
Modern defense systems are really not a specific product, rather a supply chain. Primes, from legacy to non-traditionals, rely on components from a range of different sub-tier vendors. They oftentimes pull from many of the same suppliers.
Sensors, compute, software, power systems, communications, materials all evolve on their own timelines, often driven by commercial markets outside the defense ecosystem. The system itself is just a temporary integration of those parts.
2. Control Comes from Substitution
The real question is not who owns the system design, but rather how quickly any part of it can be replaced. If a component cannot be swapped without triggering a major integration effort, then the system is not adaptive and new strategy is needed. For legacy systems, this can be challenging but not impossible. The problem in the past was incentives (both industry and the government have a bias for stability). This is why Collaborative Capability Development strategies can provide greater flexibility to the government even in leanly manned offices and why the transition to open architectures needs to happen even for older systems.
Control under OSC comes from knowing what can be swapped, knowing what should be swapped and having the right mechanisms to do it.
While the initial phases of adoption will be challenging given the incentives, once key components are mapped and the government gains insight on the technology cycles for those capabilities, it will build the muscle memory to become more adaptive.
3. Program Manager as Portfolio Orchestrator
This shift changes the role of the program manager. Instead of managing a single system, they begin managing a portfolio of components.
Their job shifts from tracking EVM details and holding dozens of status reviews (although some of that is still needed of course) to:
tracking the state of the art across each subsystem
informing vendors looking for guidance on new needs
identifying when a better, mature option becomes available
planning upgrades for integrating new components
This is closer to how leading commercial companies (and F1 teams) operate. They don’t redesign entire systems every cycle, they upgrade pieces and parts continuously.
4. Tech Scouting as a Core Program Function
If there is a lack of clarity about the progress of the underlying technology, a program will be unable to make good upgrade decisions. That makes tech scouting a core program function. PAEs should make sure there are focused teams working to gather and refine this information…as an expanded version of market research. These teams should ask questions like:
What is the next iteration of a key sensor that can add more functionality?
Who is building a better autonomy stack? What are the differentiators and when will it be available for experimentation?
What C2 improvements are being pursued and how are the different companies progressing?
The goal is not to chase every new concept pitched by a SBIR company but to gather enough intel from multiple sources to compile a clear view of where the technology and component maturity for the respective portfolio is heading so upgrades can be timed deliberately. Providing key vendors with insights on the government’s needs can help serve as a demand signal to accelerate the availability of certain upgrades.
5. Improve System Resilience
Understanding the supply chain is not just about capability but also readiness. Single-source suppliers, fragile sub-tier dependencies, and long-lead materials present operational risks both to production scaling (or mobilization) and to maintaining the system. In the past, PMs rarely focused on this problem as part of initial development or upgrade modifications but with OSC it becomes a central consideration.
Having a better understanding of the supply chain allows PMs to characterize potential supply chain bottlenecks, understand the health of different suppliers (and where they need help), recognize the scaling capacity of new components, assess any FOCI issues and proactively address concerns.
6. Next Increment Starts with Components
The future acquisition system is characterized by steady incremental improvements that provide warfighters with new capability on a reliable cadence in peacetime and that has the flexibility to move even faster in a conflict. This is why future upgrades should not start with a blank sheet but be driven by the state of the supply chain.
It should start with a clear view of how each component or subsystem is evolving and using those trends to design the next increment. In the past, more massive redesigns were usually planned that took too long to execute and install. With OSC, the goal is a series of targeted upgrades to ensure systems keep pace with change.
Foundational Elements
To effectively execute OSC, program managers need to build a map of their system by understanding the following:
components
suppliers
dependencies
tech roadmaps
As part of building this map, PMs will also need to:
Leverage modular architectures. Having a government reference architecture, commercial standard or common data layer/broker (depending on the system) is key to executing OSC since integration processes should well understood to ease that part of the upgrade process. This will require involvement and verification by government engineers initially, but OSC will give greater opportunity to validate those enduring architectures given the envisioned faster upgrade cycles.
Address legacy system constraints. Programs should establish a roadmap for breaking apart legacy systems (if the lifecycle justifies it) to begin executing OSC even if there are constraints (maybe only sensors can be upgraded initially) that must be accepted during the interim.
Gain access to BOMs on their existing systems. This might require some negotiation and cajoling with many vendors, but it is key insights that is needed to successfully own the supply chain. In the past, program offices usually had little visibility into the supply chain. This lack of transparency was due to primes not being incentivized to share and contracts not requiring it. With the push for supply chain risk management, this has become easier to obtain and now can be used for other purposes.
Build the infrastructure and tools to manage the data. This data will include inputs from vendors, tech assessments, performance in exercises and other informative details from multiple sources. At the most mature stage, mission engineering analysis should be incorporated to articulate the impacts of a change specifically against certain mission threads / kill chains.
Assemble a team. It might need to be a mix of military, civilians, contractors and consultants to get the right composition depending on the complexity of the system, but this team is critical to being able to have the conversations at the various conferences and working level sessions with industry.
Have strong user feedback loops. While the supply chain will drive the available upgrade decisions, with strong user feedback loops, PMs will be better positioned to advise industry that is looking for a demand signal to ensure that investments made are focused on the highest operational priorities.
These foundational elements are key to plan tech-driven upgrades, adapt to new threats, and scale production.
Early Use Cases
—The Army and Interceptors—
The Army is launching a new program to develop affordable interceptors by building one from scratch by identifying the best subsystems to construct one (using contract manufacturers) that meets its different performance parameters.
“If you took what a PAC-3 does and divide it into like, five or six subsegments, what do you actually need? One of the sub segments is a seeker, one is propulsion. We’re breaking apart this problem. We want you to bring us all of the solutions.” Secretary Driscoll
—The Air Force and CCA—
The Air Force has instituted different government reference architectures in its Collaborative Combat Aircraft program that allowed different autonomy stacks to be substituted mid-flight. That is an extreme version of OSC that shows the potential for all systems.
—Drone Dominance—
Drone Dominance’s Supply Chain Framework has 13 different component breakdowns from comms to GNSS modules to imaging sensors. The program is adopting a cycle of continuous design, manufacturing and updates to stay operationally relevant.
Next Steps
PMs should assess their programs and build a plan for implementing OSC where it makes sense. If the user only requires an update every 3 years on a low volume, highly specialized system then OSC might not be a right fit. If however, you have users with a backlog of additional capabilities they think are important for a platform fielded in large quantities, then this approach should be considered.
Join over 15,000 defense and industry subscribers to get our weekly recaps and thought pieces. Paid subscribers also get budget and legislative analysis and are valued supporters of our work.
Interesting approach that has some potential value, as long as a couple things are addressed:
1. This model is predicated on the operational needs (the big "R" Requirements) being properly understood and articulated. This does not mean (as it often does now) a specific material solution (e.g. "120mm main gun") but an actual Required Capability, so PMs can focus on material solutions to meet the Requirement. This remains THE shortfall in any process changes.
2. There will need to be greater transparency across businesses, at least WRT the government's access to information, so that PM know what is available and are able to adequately assess the value and/or risk of particular elements.
3. Government will likely require a viable AI capability to manage the large scale data that this approach makes available, not just to ensure the ability to "see everything" but to understand when more than one PM is building a dependency on a single, or small number of, suppliers.
It really comes down to two things. First, it’s about delegating down to the lowest decision maker. Second, if you do that, then you can actually have a marketplace. The article mentioned Ukraine, and that's kind of exactly what they're doing right now. They aren't centralized, and that's why they can adapt so fast. We need that same kind of philosophy and marketplace ecosystem so we can just buy and swap stuff quickly.