An enterprise data platform is built. It's declared the single authoritative source. Leadership directs all programs to use it. The platform is technically capable, well-funded, and strategically sound.
The operators who need the data don't use it.
This isn't a technology failure. The platform works. It's an operating model failure — the economics of connecting to the platform are structured in a way that makes adoption cost-prohibitive for the programs that would benefit from it.
The pattern
The Space Force's Unified Data Library (UDL) is a cloud-based data repository designed to consolidate commercial and government space domain awareness data into a single, accessible source. In January 2021, the Chief of Space Operations declared UDL the single source for accessing and managing all data in support of Space Force operational systems.
Four years later, the GAO reported that staff who monitor objects in space are not using UDL in daily operations — because it is not integrated into their operational systems. The data exists in the platform. The operators who need it can't access it from the systems they actually use.
The Space Force has since requested $187 million to enhance UDL integration, released a multi-front action plan to address adoption, and is converting UDL into a formal Program of Record. The platform itself was never the problem. The gap between "the platform has the data" and "the operator's system can access the data" is where the adoption stalled.
Why enterprise platforms don't get adopted
The UDL illustrates a pattern that repeats across enterprise data initiatives. The platform is built and funded centrally. The integration cost is borne by the programs that need to connect to it. And that integration cost is high enough — in engineering effort, in authorization work, and often in fees charged by the platform operator — that individual programs can't justify it from their own budgets.
Integration engineering. Connecting an operational system to an enterprise data platform requires API development, data format alignment, authentication integration, error handling, and testing. For a weapon system with its own data architecture, this is a custom engineering effort — not a configuration change. If the platform doesn't publish well-documented, stable APIs that the program's existing systems can consume without significant modification, the integration becomes a software development project.
Authorization scope. Connecting a weapon system to an enterprise data platform changes the weapon system's authorization boundary. The data flows, the interconnect, the access controls, and the data handling requirements all need to be documented and assessed. This is authorization engineering work — and it requires SCA capacity from the AO's office, which is already constrained across the portfolio.
Cost structure. If the enterprise platform charges programs for data ingestion, storage, or access — and those charges are set by the platform's operating contract rather than by a published rate card the program office can plan against — the cost of adoption becomes unpredictable. A program office managing a tight sustainment budget can't absorb a data integration expense that isn't well-defined before the work begins.
Operational risk. The program's existing data sources work. They may be stovepiped, redundant, and expensive to maintain — but they're understood, authorized, and operational. Connecting to a new platform introduces a dependency the program didn't have before. If the platform has an outage, does the weapon system lose data access? If the platform changes its API, does the weapon system's integration break? These are reasonable concerns for a program office managing a high-availability system.
The operating model problem
Enterprise data platforms succeed when the cost of integration is lower than the cost of the alternative. They fail when the integration cost — in engineering, authorization, fees, and operational risk — exceeds what individual programs can justify from their own budgets.
This isn't a technology problem. The platform works. The data is there. The operators want it. The barrier is economic and structural:
When the platform operator's revenue model depends on integration fees, the operator has no incentive to make integration easy or cheap. Every dollar of integration complexity is a dollar of contract revenue for the operator. The platform becomes a revenue source rather than an enabler — and adoption stalls because the programs that need the data can't afford the connection.
When the platform doesn't publish stable, well-documented APIs, every integration is a custom engineering effort negotiated through the platform operator. The program office can't estimate the cost before engaging, can't execute the work independently, and can't predict the timeline. Programs that could integrate in weeks with a published API instead wait months for a contract-mediated engagement.
When the authorization cost of connecting isn't scoped upfront, program offices avoid the integration because they can't predict its impact on their existing ATO. A connection that changes the authorization boundary is a risk the ISSM has to manage, the SCA has to assess, and the AO has to accept — and if nobody has scoped that work before the program commits, the authorization uncertainty becomes a reason to defer.
What makes enterprise data platforms work
The enterprise data platforms that achieve adoption share a common trait: the integration cost is borne by the platform, not by the programs connecting to it.
Published, stable APIs. Programs can estimate integration effort from documentation, build the connection with their own engineering teams, and predict the cost before committing. The platform operator maintains the API contract, handles versioning, and absorbs the cost of backward compatibility.
No per-program integration fees. The platform is funded centrally — through appropriation, through enterprise assessment, or through the platform's own budget — and programs connect without transaction costs. The marginal cost of adding a new consumer is near zero, because the platform was designed for it.
Defined authorization impact. The platform publishes what changes when a program connects — the data flows, the interconnect requirements, the security controls — so the program's ISSM can scope the authorization work before the connection is built. The SCA assessment for the interconnect is bounded and predictable, not open-ended.
Graceful degradation. The platform is designed so that programs can use it as a supplementary data source without depending on it as a primary source. If the platform has an outage, the weapon system continues to operate with its existing data. The platform enhances capability without introducing a single point of failure.
The cost of non-adoption
When an enterprise data platform exists but programs can't afford to connect, the Department pays twice: once for the platform, and again for every program that maintains its own data infrastructure because the platform's integration cost was too high.
The UDL's $280 million contract with the platform operator funds a capable platform. But if the programs that need the data continue operating their own data pipelines because connecting to UDL costs more than maintaining the stovepipe, the platform investment doesn't deliver the return it was designed for.
This is the same economic logic from the weapon system IT infrastructure series, inverted. That series examines the cost of maintaining stovepiped infrastructure when enterprise platforms exist. This post examines why programs stay on stovepiped infrastructure even when the enterprise alternative is available — and the answer is usually that the enterprise alternative's operating model makes the connection more expensive than the status quo.
What program offices can do
If your program would benefit from an enterprise data platform but the integration cost is a barrier, the problem is worth surfacing rather than working around:
Scope the integration cost. Understand specifically what connecting to the platform requires — API development, authorization impact, fees, operational risk. If the cost is prohibitive, document why. A program office that can articulate "connecting to the enterprise platform costs $X and takes Y months because of Z" is providing information the platform's leadership needs to hear.
Engage the platform SPO. The platform operator's incentives are shaped by the contract. If the contract rewards integration complexity, only the program office with the requirement can surface that the operating model is preventing adoption. The platform's SPO needs to hear from the programs that aren't connecting and why.
Evaluate what's needed versus what's offered. Enterprise platforms often provide more capability than any single program needs. If the barrier is the cost of full integration, explore whether a narrower connection — read-only access to specific data types through a published API — meets the operational requirement at a fraction of the integration cost.
The contract is the architecture
Enterprise data platforms don't fail on technology. They fail on operating model — and the operating model is defined by the contract.
When a platform contract incentivizes integration complexity, adoption stalls regardless of how capable the platform is. When the contract requires programs to negotiate custom integrations through the platform operator rather than connect through published APIs, the operator becomes a tollbooth rather than an enabler. This isn't a criticism of the companies operating these platforms — they're performing the contract as written. The contract structure is where the adoption problem starts, and it's where the fix has to happen.
A program office planning an enterprise data platform — or trying to improve adoption of one that already exists — benefits from understanding this dynamic before the contract is awarded or recompeted. The questions that shape adoption aren't technical ("can the platform handle the data?") — they're structural: Who pays for integration? Who maintains the APIs? What does the authorization impact look like for a connecting program? Does the operating model reward adoption or create barriers to it?
These are answerable questions. And answering them before the contract structure is set is significantly cheaper than discovering the adoption problem after the platform is built.
Robert Burckner is the founder of Millabs Corporation, a Service-Disabled Veteran-Owned Small Business. He has served as ISSM and ISSE for weapon systems at the Air Force Lifecycle Management Center, and as Division Chief at the Space Warfighting Analysis Center (USSF/NRO).
If your program is building, recompeting, or trying to fix adoption of an enterprise data platform, understanding the contract structure's impact on adoption is the first step. If your program needs to connect to an existing platform and the integration cost is a barrier, scoping that cost — including the authorization impact — is the second. Contact Millabs. These assessments can be performed independently on behalf of the program office through existing government contract vehicles.