So, how can this data be taken from silos and truly shared across services? The answer is a federated but integrated data platform built on a reference architecture. Here are some key steps to implement this structure:
Start with a reference architecture based on modular open systems architectures. This reference architecture establishes standards for data discovery, curation, and profiling; metadata management; data security. Across the Department of Defense (DOD) there will never be a single set of tools that make up the data platform, but with a single reference architecture, the government can easily connect disparate systems and have them talk to each other to create an integrated, federated data platform.
By making compliance with a reference architecture a requirement in the acquisition process, the government also has a pathway to reducing vendor lock and incorporating innovative new data manipulation tools into these platforms down the line.
Compliance with the reference architecture allows the system to be built with security as a primary consideration, allowing for a more complete understanding of the lineage of data within the system and how it can be appropriately used and by whom.
Create a data governance structure with a data product-centered approach. JADC2 requirements and varied classified use cases make it critically important to implement a proactive approach to data governance. This approach must be data product-centric and provide automated visibility into what data is being stored in federated data systems.
As Graham Evans, a digital transformation leader at Booz Allen, says, “The focus should be on the glue that holds an architecture together rather than on the tools it hosts.” That glue? A strong data governance structure that addresses three key elements:
- Implementing guidelines on selecting data
- Modeling the data to be available to the enterprise
- Providing methods for how data is linked, secured, and made available through access control
Insist on government-owned APIs that enable both data ingestion and sharing. These APIs are a critical element of the data fabric and orchestrate data sharing. Coupled with this, a data analytics pipeline is needed to rapidly generate algorithms and mature and deploy them in operational environments.
Build with the edge in mind. Data products and analytics results are meaningless if they cannot reach the warfighter in real-time in contested and disconnected, intermittent, limited environments. While it is equally important for curation and analysis to occur in cloud or on-premises environments, analytics capabilities must be available on platforms and within the individual unit or warfighter.
Incorporate specific data tools with the overarching user experience in mind. The number of tools that can empower the data pipeline are vast, but unless these tools are acquired with an understanding of how they can work together, the value and data freedom they provide is limited. DOD should be cautious of tools that will ingest data and lock it in proprietary data jails, limiting the ability of other users or tools to perform novel operations. By acquiring tools strategically, they can more easily be swapped in and out while the data and analytics remain consistent and owned by the government.
Establish compliance checkpoints. Compliance with a governance structure and common taxonomy for data will be critical to maintaining a mutual understanding of how data is classified and leveraged. To secure these processes, compliance checkpoints can be embedded within the reference architecture. These checkpoints can ensure data continues to follow established taxonomy so it can be discovered and leveraged for insights following secure methods.
Update policies to reduce limitations to data access. At the highest levels, data and intelligence is rarely shared between different services’ networks. While much of the data the warfighter needs exists, there may be laws or policies that do not enable this sharing.
With the ability to use DevSecOps as well as containerize and securely push code across domains and classifications, policy must also evolve to enable this technology. One such policy could be redefining the role of the Authorizing Officer to own the entire mission thread instead of one service, capability, or domain.