Digital Transformation at the DOD

This post is adapted from the 2022 DevOps Enterprise Forum guidance paper Software is Eating the Battlespace by LtCol John Schreiner, Jondavid Black, Col Corey Brunkow, Virginia Laurenzano, Rob Nolen, LCDR Andres Otero, and Rick Jack.

Before You Start

There are many software-focused organizations that exist within the DoD. They provide support and services to customers ranging from large organizations (the United States Air Force includes approximately 480,000 personnel) all the way down to small teams. In addition to ranging dramatically in size, customers also have different roles and missions within the DoD. Understanding who you are delivering software to and what the state of maturation of their software development is will be crucial to success.

The 2018 Department of Defense Artificial Intelligence Strategy states that the DoD is taking action to realize the benefits of AI by “Scaling AI’s impact across DoD through a common foundation that enables decentralized development and experimentation.” While the authors are focused more broadly than AI, the strategy also highlights a “common foundation of shared data, reusable tools, frameworks and standards, and cloud and edge services. . . . ” This common foundation does not currently exist as envisioned.

Recommendation 1: Identify Your Customer

Identify the customer you are serving. This may range from individual service members to small joint-service teams and up to a larger unit/echelon/branch. Remember, most projects will have multiple customers (e.g., product users, data owners, and authorizing officials).

Once each customer is clearly identified, enable a “common foundation that enables decentralized development and experimentation.” Tooling and resources beyond the office productivity suite, such as code repos, development environment, automated compliance, continuous integration, and security analysis tools, are available and can be used with minimal effort by users. Do not simply hand them a bag of nails and expect a house.

Leverage the knowledge of the other software organizations within (and external to) the DoD. Identify and reward leaders and teammates who leverage information learned from their predecessors and understand previously solved problems. Alternatively, leaders also need to allow teammates adequate time and support to publish successes so that others may learn from their wins.

Recommendation 2: Determine Who Will Develop the Code

Identify who will develop the code to solve your problem. DoD software development is spread across units and agencies, from the lowest operational level through strategic-level organizations. We largely know the roles and missions for which software is developed and then deployed, but the organizations that develop and provide software solutions have constraints that dictate how and on what networks they operate. DoD decision-making criteria on whether to build or buy software products may change based on understanding the constraints of software producers and how consumers utilize data.

To solve the problem of the dispersion (in an organization as large as the DoD, it is common for work to be inadvertently duplicated in multiple places/teams) of software-developing/providing organizations, we suggest the following considerations:

Understand that pockets of excellence will sometimes have the unintended consequences of duplication of effort. In many cases, two is greater than zero. Therefore, be okay with duplication, especially in the beginning, when these organizations are still in the process of maturing. However, be deliberate later in identifying ways to consolidate solutions. Build this iterative process into your strategy and resourcing.

Data usage at various classification levels will intentionally be disrupted, siloed, and duplicated. The DoD can get its best ROI from the resources it uses (talent and hardware) for software development. It provides universally interoperable software that can be shared cross-platform and shares run-time environments. Maximizing access to data will provide DoD and consumers with a decisive advantage.

DoD software will not be entirely developed by uniformed service members or employees of the US Government. Provide teams with ways to define and onboard a variety of collaborators. Consider that different projects will require different levels of access, so build that in from the beginning. Developers may be DoD only, or civilians may also need access to data. Will they need access to the development resources? Will they be an authorized end user of the product they develop? Will they be direct-support contractors with official credentials and have access to a common access card (CAC, Smartcard), or will they be third-party contractors who cannot receive official credentials? How can each of these considerations be addressed to enable collaboration?

Obtaining formatted, timely, and useful data is the desired outcome of software. Data sharing and data standardization are best done at the point of ingestion, which preserves source attributes, statistical distributions, etc., prior to transformation. Access to data extraction, transformation, and loading platforms—in parallel with software tools—enable DoD software products that use open standards to produce data with joint utility, making joint use more realistic.

Recommendation 3: Plan Multiple Courses of Action

Several different courses of action (COAs) to solve your software needs may be considered. A KTLO  (keep the lights on) plan for each COA needs to be completed prior to COA selection. Some generic software COAs are:

• build with a traditional software agency
• build through a DoD software factory
• buy a completed solution
• lease through SaaS or similar

The maintenance and sustainability of the platform’s offerings must be accounted for before development begins. Things to consider are:

• maintaining your code
• maintaining the platform that runs your code platform services (sometimes referred to as shared services) that require people, processes, and tools to automate and routinize the functions of onboarding
• making the platform self-service
• building infrastructure scaling
• maintaining collaborative services that allow your team to get your code up and running

These efforts must be transparent to budgeting organizations to enable effective cost management and sustainability over the fiscal years’ defense program (FYDP). They will not be the easiest to account for, as there will likely be a unique wrinkle in every situation. For example, Service A and Service B use the same SAN switch. Which service pays for the maintenance of the SAN switch? Which service pays to replace the SAN switch?

Continue reading about ways to transform the digital strategy in the US DOD in this free DevOps Enterprise Forum paper.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•