DATA-CENTRIC VISION: Within the DOD, the vision has unequivocally been cast for a combined and joint force capable of seamless warfighting across all domains: sea, air, land, space and cyberspace. This data-centric force empowers leaders and Soldiers with the right information at the right time to attain decision dominance at all echelons. (Photo by Michael Fridley, Booz Allen Hamilton, for DASA DES)
The newly established DASA DES office is developing a playbook with a few key initiatives that are laser focused on driving digital transformation across the acquisition community.
by Darren LeBlanc
As the Army delivers its next-generation capabilities, the rivals of the United States are paying close attention. And with the rapid progression of enabling technology, the global threat landscape is changing at an unprecedented rate. To maintain competitive advantage in the worldwide battlespace, the Army needs to rapidly modernize platforms, weapons systems and even business practices. This is a holistic change that will require meticulous attention to gaining efficiencies through digital technologies; it requires empowerment of a highly trained digital-first workforce; and at times a complete reworking of our institutional thinking and processes.
THE ARMY NEEDS DIGITAL TRANSFORMATION
Digital transformation is the adoption of advanced digital technology and the associated cultures and practices to improve efficiency, reduce cost and cultivate innovation. With the recent release of DOD’s digital modernization strategy and the Army’s digital transformation strategy, the Army is primed for wholescale adoption of digital transformation throughout the acquisition force. Jennifer Swanson, the recently appointed deputy assistant secretary of the Army for data, engineering and software (DASA DES), is chartered with just that task. Her office is developing a new playbook focused on three digital transformation technologies: data centricity, modern software development and digital engineering.
A NEW STRATEGY: Programs across the Army are increasing their use of digital engineering but need a common playbook to ensure that system representations are consistent, reusable, able to be integrated with one another and traceable to operational needs. When everyone on the team is running the play properly, the efficiencies are exponential. (Photo by U.S. Army Staff Sgt. Sean K. Harp, Defense Imagery Management Operations Center)
DATA CENTRICITY
For most of the past two decades the Army has operated within a network-centric paradigm. Programs lived or died by whether they were network-centric. Being net-centric meant your system was interconnected to other systems by a communications network. But this proved difficult as networks were built for specific purposes, for specific customers and for specific applications, as the development followed the funding streams (the term “stovepipe” comes to mind here). Soldiers found themselves needing to navigate the disparate networks (instead of The Network) to accomplish mission objectives. For example, logistics, medical and command-and-control systems all had their own separate networks, with different transport hardware, routing protocols, security and data standards. Getting data from one network or application to another often required costly integration work.
Fast-forward to today and the vision has unequivocally been cast for a combined and joint force capable of seamless warfighting across all domains: sea, air, land, space and cyberspace. This describes a simplified and flattened communications pathway with data as the prized commodity; it describes a connectivity that is entirely agnostic to specific transport systems where the right data is accessible to the right consumer at the speed of mission. According to a working definition recently approved by the Secretary of the Army Christine Wormuth:
“The data-centric Army employs advanced lethality, survivability and tempo—empowers leaders and Soldiers with the right information at the right time to gauge risk, optimize combat power, fully employ national means and attain decision dominance at all echelons. Leaders leverage analytics to understand, visualize, describe, direct, lead and assess. In real time, the Army learns, adapts, generates and sustains forces with integrated decision-driven analytic capabilities.”
The ability to achieve this vision requires a robust and secure unified network as a starting point, and a commitment to the centrality of data. At its core, data-centricity is a paradigm in which data is an open resource, accessible and consumable by any trusted, networked application without time-consuming and expensive data integration efforts. With access to all the data, leaders make evidence-informed decisions at speeds previously not possible. Data-centricity is the first shift in this digital revolution, and it’s a big one.
Key Effort: Assistant Secretary of the Army for Acquisition, Logistics and Technology (ASA(ALT)), Unified Data Reference Architecture. Data-centricity requires some set of standards to define how data is packaged and understood. DASA DES is defining a unified data reference architecture in the 2023 fiscal year that will govern acquisition of data-centric capabilities throughout ASA(ALT). This will give program managers and industry partners architectural guidance for producing, sharing and consuming Army data. The unified data reference architecture enables digital transformation by adding data mesh to converge existing data fabric and platform efforts.
|
FROM DATA FABRIC TO DATA MESH In recent years, much has been made of the data fabric concept and rightfully so. The data fabric is an architecture that facilitates the end-to-end integration of various data environments, providing machine-enabled unification and integration of data from disparate sources. The data fabric streamlines sharing of data between users and applications. The problem arises for the Army, however, when we try to scale a data fabric to cover all the needs of every user in every domain (e.g., intel, logistics, etc.). The data needs of an intelligence specialist would be different to that of a logistician. There are so many types of data that creating a single uber-fabric to centrally manage everything is unwieldy. And even if it were technically feasible to accommodate every user and every data type, the volume of data then traversing that fabric would make it quite crowded.  THE DATA MESH SHARES DATA PRODUCTS: The flow of mesh services from identifying a data need and creating a data product to providing and addressing feedback at the end. The data mesh concept simplifies the problem of creating a single uber-fabric to centrally manage too many types of data by specifying standards by which data can be packaged (the data product) and labeled (the metadata) to be consumed by an external consumer. (Graphic by Dan Andrew, DASA DES and USAASC) First defined by Zhamak Dehghani in 2019, the data mesh concept simplifies this problem by specifying standards by which data can be packaged (the data product) and labeled (the metadata) to be consumed by an external consumer. Instead of a crowded, centralized data platform, the data mesh calls for a decentralized architecture that keeps the storage and ownership of the data within its originating domain. Since domains have the expertise in their data, policies about governance, documentation and access are more efficiently managed at that level.Consumers have an efficient catalog system that tells them where to pull the data they need and how to provide feedback directly to the data owners so products can be updated on user needs. With data mesh, the intel specialist has seamless access to intel data in the intel data fabric, but now also can locate and consume standardized data products from the logistics team (or any other domain participating in the data mesh architecture). —DARREN LEBLANC |
MODERN SOFTWARE DEVELOPMENT
Data, however important, is useless if we don’t take advantage of it. Now more than ever, industry, academia and Soldiers themselves are solving critical problems leveraging data with modern software. But the Army isn’t fully modernized in how it approaches software development, deployment or maintenance. “Sure, gone are the days when the software development team would mail a CD-ROM to the operations team to deliver a new application, but we are far from having every application developed and deployed through a modernized pipeline,” said Chad Claussen, director of digital transformation technologies in DASA DES.
Migration to Agile software practices is important because of the pace of change experienced by our warfighters. The legacy development methodology (i.e., waterfall) that we have lived in for decades takes too long to deliver and too frequently misses the target by the time the software is delivered. Major DOD programs average five to seven years from requirements to delivery. But with modern software development practices, things are changing.
At the direction of the undersecretary of the Army and the vice chief of staff, DASA DES is co-leading one line of effort in the Network Capability Portfolio Review to focus on software modernization. The goal of the review is to ensure that the Army is aligned to achieve digital transformation—and a big part of this process has been making sure that everyone understands how their area needs to change to accommodate Agile software practices. For instance, requirements are now being written more broadly so teams can decompose the larger requirement into smaller chunks that can be built and tested in just a few weeks. The test community is making provisions for authorizing deployment at a minimal viable product instead of waiting to test at the end of the development. Units are being mobilized earlier to provide feedback throughout the process shaping the iterative development. One of the biggest shifts comes for logisticians; in an Agile construct, there is simply no such thing as software sustainment—it is always being updated based on users’ feedback and changing needs.
|
FROM WATERFALL TO AGILE DEVELOPMENT The waterfall methodology has been around for a while and it is straightforward: Collect all the requirements up front, build the cascading schedule of sequential phases, and set it all in motion. Completion of one phase triggers the next until the full-featured product is developed and tested. There are still some limited use cases for waterfall development, for instance when you are given all the requirements up front and aren’t allowed to communicate with the user, as is the case with some classified programs. Unfortunately for the Army, requirements change, Soldiers have new mission needs, and the enemy gets a vote. The old way of business, so to speak, has us way too far down the field before we can cut left or right in response to an adversary’s movement, or any change in user needs. Agile methodology, in contrast, is built around the tenet that we may not be able to get all the information up front; the developers may need to be responsive to customer feedback, technology changes or global threats. So instead of creating a plan for solving the whole complex problem up front, the problem is split into achievable tasks with immediate testing, delivery and feedback. Keeping the customer in the loop throughout the process helps ensure the product that gets delivered is what the user actually needs at that time. There are a variety of Agile frameworks (e.g., Kanban, Extreme Programming, etc.), but the most popular is Scrum. Coined by Hirotaka Takeuchi and Ikujiro Nonaka in an article in Harvard Business Review in 1986, the moniker is sports analogy to stress teamwork in confronting complex problems. In Scrum, the team works together in two- to four-week sprints to implement a new functionality and collect customer feedback for future cycles. AGILE VS. DEVSECOPS DevSecOps (development + security + operations) is another modern software development practice that is largely complimentary to Agile. Whereas Agile is focused on frameworks for managing the development and delivery of software (e.g., Scrum with guidelines like two- to four-week development sprints), DevSecOps is more of an internal philosophy focused on breaking down the barriers between the development team (the ones writing the code), the security team (the ones doing security) and the operations team (the ones deploying and managing the code). Both DevSecOps and Agile offer improvement in efficiency but with different key focus areas. One key feature commonly associated with DevSecOps is a continuous-integration, continuous-delivery pipeline (see “Heard It Through the Pipeline,” page XX). In legacy development models, multiple engineers would produce code, then work at the end of the development process to integrate their features, test everything and pass the whole build to the operations team (which could then take anywhere from hours to weeks to deploy it). With a continuous-integration, continuous-delivery pipeline, as much of the process is automated as possible. Features are continuously integrated and available to the rest of the team to reduce bugs, security and testing are embedded in each step of the process, and incremental builds are continuously delivered as often as possible. —DARREN LEBLANC |
WATERFALL VS. AGILE: Chart displays the benefits of moving from the legacy waterfall method to an Agile cycle process. (Graphic by Tracy Bannon, MITRE Corp., for DASA DES and USAASC)
KEY EFFORT: AGILE ENGAGEMENT PROGRAM
As of the beginning of the 2023 fiscal year, DASA DES has launched an initiative to help programs tailor industry-leading practices (e.g., DevSecOps and Agile) to the specific DOD environs (e.g., Army acquisition, contracting, test and evaluation). The first of many pillars of this program will consist of connecting some ASA(ALT) teams working on software programs with qualified Agile coaches and leaders from DOD programs with a successful track record of Agile development to facilitate coaching and mentorship.
Key Effort: Upskilling the ASA(ALT) workforce for Agile, digital first mentality
With more than 100 participants from six program executive offices and ASA(ALT) in an initial pilot, Upskilling addresses how the Army will hire, retain, train and deploy the digital workforce of the future. This includes a human-centered, design-based program to ensure training for key roles in the program offices and building digital career paths for civilians that include education and rotational assignments outside the government.
DIGITAL ENGINEERING
With Agile development, the Army is building the right things and getting them to Soldiers faster, but faster development also means an increased reliance on a digital ecosystem in the engineering process. From remote-control tanks to resilient communications networks, Soldiers rely on complex systems-of-systems that comprise interconnected and mutually dependent parts. Each time one of these individual components gets upgraded, the dependencies and interfaces are put on trial to make sure they were understood and documented well. In an analog system, tracking these requirements is cumbersome. But with digital engineering, the Army’s goals become achievable.
The challenge for ASA(ALT) is to get everyone speaking the same digital language, so we can understand each other. It’s one thing to gain efficiencies if all systems in one platform are neatly and systematically defined, but it’s another thing altogether to deliver every ASA(ALT) system with digital models that can be shared and leveraged by integrators, testers and logisticians.
Taking this down a level further, this means establishing and integrating models that describe each aspect of a complex system and making sure all our systems leverage the same underlying data structures and pull from the same authoritative sources of truth. This process is called model-based systems engineering, which is an important subset of digital engineering.
Programs across the Army have realized benefits and are increasing their use of digital engineering but need a common playbook to ensure that system (and subsystem) representations are consistent, reusable, able to be integrated with one another, and traceable to operational needs. Much like in the game of football, when everyone on the team is running the play properly, the efficiencies are exponential.
Key Effort: Model-Based Systems Engineering Style Guide
As part of a larger plan for adopting digital engineering practices across ASA(ALT), DASA DES is developing a style guide for ASA(ALT) to be released this fiscal year. This style guide will enable programs adopting model-based systems engineering to do so in a uniform way to maximize the value to the Army. The style guide is being developed in close coordination with other service components and Army organizations to ensure maximum interoperability and commonality across DOD.
CONCLUSION
The Army is making significant investments in digital transformation because achieving a digitally enabled and data-driven land component requires decisive action. It involves setting the stage for data centricity; it involves transitioning across-the-board to modern software development and leading practices for digital engineering; and it involves the important work of training, coaching and mentoring along the way.
As Swanson put it, “The role of DASA DES is part quarterback and part cheerleader. We are focusing on providing key enabling guidance and architectures, but also coaching and mentorship to programs out on the front lines fighting the good fight each day.” The Army is expecting these investments to pay dividends as the acquisition force embraces digital transformation through the ranks.
For more information contact the Office of the DASA DES, dasades@army.mil.
DARREN LEBLANC is a senior technical adviser with CommNet, supporting the Deputy Assistant Secretary of the Army for Data Engineering and Software (DASA DES). In his current role, he helps the Army analyze and solve complex problems related to digital transformation. He holds a B.S. in engineering from Messiah University and has done interdisciplinary graduate work at Harvard Business School, Stevens Institute of Technology and Western Seminary.
