Data Strategy at the Department of Defense

As director of information policy for the Department of Defense, Michael E. Krieger assists the CIO in managing, directing, executing and implementing information policy across the DoD. He is responsible for providing policy and guidance for implementing its Net-Centric Data Strategy and enabling the transition to an enterprise service-oriented architecture (SOA). He has broad experience in information technology and command-and-control Systems. Krieger served as a U.S. Army officer for 25 years with operational assignments in communications and command and control. He commanded the 121st Signal Battalion, 1st Infantry Division at Fort Riley, Kan. He also served in the Joint Staff J-6 and OASD-C3I. He holds a BA from the United States Military Academy, an MS in physics from Georgia Institute of Technology, and an MS in national security strategy from the National Defense University. Writer Ben Bradley talked with Krieger about the challenges of implementing the DoD’s data strategy, which calls for separating data from applications. Ben Bradley: I’ve reviewed the DoD’s Net-Centric Services Strategy. The promise of transformation depends on “un-isolating” systems and making information available to the people who need it most. At the center of this promise is the idea of interoperability and data sharing. It seems the Achilles’ heel is data consistency. There must be thousands of different data standards in thousands of different applications in an organization as large as the DoD. How are you dealing with this?

Michael E. Krieger:

In the past, the DoD tried to standardize data definitions across the entire organization. This didn’t work because the DoD is a large and extremely complex enterprise. The fact that there are many different data sets is not our weakness, it is our strength. Our weakness is that we build systems that are too tightly coupled to the data. To get that data into different systems, we have to pay integrators to move it out of one system and into another. We do this as a point solution. So we end up with a bunch of point-to-point solutions. This is what we’re fixing.

We’re starting to see programs build capabilities that anticipate unanticipated use by decoupling data from applications. That means data is available as a service, and applications are independent of the data. Applications should be able to discover and pick the data assets they need. We can’t anticipate what local problem a 19-year-old soldier on the night shift wants to solve. But making data available as a service pushes problem solving out the edge of the network where it is needed.

The data strategy gives priority to visibility, accessibility and understandability over standardization. We’re more concerned about interoperability between applications without a reliance on hard-coded, tightly coupled point-to-point interfaces between systems. The objective is for many applications to leverage the same data without forcing the developers to anticipate how the data, services or applications will be leveraged.

Understandability is addressed by communities of interest (COIs), a collaborative group of users that must exchange information in pursuit of shared goals, interests, missions or business processes. To do this, they must have a shared vocabulary for the information exchange.

The DISA (Defense Information Systems Agency) Net-Centric Enterprise Services program includes a suite of security, messaging and content discovery enterprise services. The availability of these services means each organization does not need to reinvent capabilities. Common services also ensure data visibility, accessibility and understandability. Bradley: So what is the Achilles’ heel?

Krieger:

Previous approaches tried to standardize and control data structures across the DoD. The intent was interoperability via standardization. The DoD is a large enterprise with many different communities of users—warfighters, intelligence community members and business users. This approach was our Achilles’ heel. I think our new Achilles’ heel is the transformation and change required to get communities together to address information-sharing challenges by agreeing on shared vocabularies and exposing and sharing data as a service. Bradley: How is the data paradigm changing?

Krieger:

Industry understands the agility and power that separating data from applications represents. Consider the Google Maps service and the Google Earth application. It is based on a community vocabulary for modeling and storing geographic data called KML (keyhole markup language). By publishing data as a service in KML, the Google Maps service or the Google Earth application seamlessly plots the data on a map or a globe. There are thousands of applications available on the Internet that depict data on Google Maps (such as crime by neighborhoods, home sales by zip code, cheap gas by zip code and many others). There are also many websites and blogs that provide resources to help users publish data to be consumed by Google Maps or Google Earth. Bradley: How are market forces driving implementation of your data strategy?

Krieger:

If you define the market as the universe of users with the DoD and related agencies, then data is a market-driven asset. It is a consumable. Need for data drives the formation of a COI. COIs form when people recognize they have a common information-sharing problem and they must collaborate to solve the problem. All that is needed to form a COI is a willingness to stand up and work across DoD departments to make it happen. The Federal Maritime Domain Awareness COI is a great example. Users from the Navy, intelligence community, Coast Guard and Department of Transportation collaborated to address a maritime information-sharing problem. They delivered an initial capability to address the information-sharing problem in nine months. Bradley: How does metadata fit into the data strategy?

Krieger:

Metadata, or data about data, makes data assets visible or discoverable. For example, in digital cameras, where the data is the photographic image, metadata would typically include the date the photograph was taken and details of the camera settings. The Department of Defense Discovery Metadata Specification (DDMS) specifies how to use metadata to make data assets visible to the enterprise. It describes how developers, engineers and users should advertise data assets posted to shared spaces so that others can discover them. We didn’t make up our metadata standard. The DDMS is based on the industry Dublin Core standard, and we added a security leg to it. This approach moves people away from hoarding data and increases data visibility and sharing. For example, the Maritime Domain Awareness Community of Interest was created when three federal departments—Defense, Homeland Security and Transportation—wanted to share maritime vessel-tracking data. DDMS-compliant discovery metadata was used to make four large data assets visible to authorized federal users and improve awareness of maritime vessels, cargo and crews. Bradley: Were there cultural changes?

Krieger:

Of course. There will always be cultural issues when you ask engineering teams from different federal agencies—each with different architectures—to collaborate. Collaboration places a premium on trust. The key here is the COI was truly a community effort because the community is formed to solve a real problem. As a result, this effort was enthusiastically supported. Bradley: How did you handle resistance to the information standard?

Krieger:

It helps when the community develops the vocabulary or information exchange semantics. This helps both data consumers and producers. One-way translation from the community standard at the producer or consumer location is the only requirement. Technologies like XML easily enable data wrapping for one-way translations. Resistance is reduced because you only need to fix one side of any legacy system. This is how you can republish data from a legacy system to unanticipated users without rebuilding legacy applications.