A more agile acquisition strategy got users excited about a joint system to report and map chemical, biological and radiological attacks, and prompted one service to change its mind about participating.
How do we measure our success in acquisition streamlining? In today's information-enabled military environment, it is more important than ever to use flexible, agile, mobile and user-friendly applications that provide information to our commanders at least as quickly as the enemy is able to operate. The information-sharing environment of our forces is constantly evolving, and for the program offices that deliver capability to our warfighters, fast implementation of new strategies or infrastructures is crucial to deliver tools that are still relevant by the time they reach the field.
The Joint Warning and Reporting Network (JWARN) and Joint Effects Model (JEM) are software applications being developed for all services and the National Guard. JWARN is a warning and reporting system that communicates information about chemical, biological, radiological and nuclear (CBRN) incidents across the chain of command and to affected units; JEM is a modeling-and-simulations application that can provide high-fidelity plots of an affected hazard area after a CBRN attack has occurred or to assist operational planning efforts as forces prepare for the possibility of a future incident. Both programs are designed to operate on hardware provided by the services.
Each service's approach to the CBRN mission is different, because of the differences in missions of the services themselves. For example, the Army may have forward-deployed forces maneuvering through a battlefield where the enemy might employ chemical weapons in an attempt to prevent that maneuver; the Air Force's interest in CBRN events is more focused on defending a well-established air base that is (obviously) not maneuvering. Therefore, an Army command post needs to see a plot of where a chemical attack occurred and the area contaminated by that attack, and it needs to be able to plot that "picture" on command-and-control maps, which depict where friendly units are and what direction they are traveling. In the Air Force, the emergency management personnel who are charged with responding to CBRN events need to see where on an air base a chemical detection may have occurred and the parts of the base affected by that attack, so that they can adjust operations accordingly and begin decontamination efforts as needed.
Using current weather observations and forecasts, JEM can provide a high-fidelity plot of the affected area that the Air Force would need to determine which part of the base is affected; the Army can use the plots to anticipate which areas need to be avoided by ground troops in the area. Navy crews on ships and aircraft could be supporting relief efforts around a radiologically contaminated area, similar to the response to the Fukushima earthquake, for example, and may need to plan accordingly. And all services have a requirement to notify higher headquarters and other affected units if they observe a CBRN attack or incident, for which JWARN provides the messaging capability.
Furthermore, JWARN's ability to overlay graphical depictions of those CBRN events onto a command-and-control map that also shows the locations of friendly forces, as well as neutral (non‑participating) units or known threats, is of utmost importance for an operational commander who needs to understand the tactical significance of a CBRN event and decide what to do next. The personnel managing a CBRN incident might only be concerned about events occurring in their immediate area of responsibility, but the cloud-based implementation of JEM and JWARN allows users to track events worldwide.
Each service operates in a different environment and with different constraints, with the result that each has developed its own command-and-control architecture tailored to its unique needs. The Army uses more robust command posts, complete with tactical servers dedicated to maintaining a tactical and operational picture of what is happening. The Marine Corps tends to take a more expeditionary approach to land warfare and relies on smaller, lighter systems-primarily its Joint Tactical COP Workstation (JTCW, where "COP" is an acronym for common operating picture). These ruggedized laptops perform a similar function to the larger systems used by the Army, but are smaller and lighter than the full complement of servers deployed by an Army brigade.
Air Force emergency management teams use ordinary Windows-based computers to perform their base defense functions. Navy ships have a customized architecture of command-and-control servers networked with personal computer workstations, and while the ships themselves maneuver through the battlespace, the computer networks onboard are pretty well locked into place-i.e., they are not taken down and later reassembled like those of an Army unit on the move.
Because of these different operational environments and considerations faced by the services, each has developed different approaches to how they handle their information and messaging needs. JWARN and JEM run on the hardware used by the services for their other command-and-control functions, and that means that JWARN and JEM developers must accommodate a wide variety of computer architectures. Those environments range from standard desktop computers used by the Air Force, to command post servers used by the Army, to a cloud-based implementation that can be accessed globally by anyone with a web browser and proper authentication. These complex systems pose a particular challenge to developers trying to field products into those environments. Because each service's architecture must integrate multiple programs and resources to field the overall system, a schedule issue for one component may have cascading effects across the entire system.
MULTIPLES AND MULTIPLES
That challenge is compounded for joint programs like JWARN and JEM that must integrate with multiple service architectures, while each architecture must itself integrate multiple programs and resources. For example, JWARN and JEM may be required to pass warning information via one method when installed in the Army's Command Post Computing Environment, but the Marine Corps' Joint Tactical COP Workstation may use an entirely different messaging protocol.
With a traditional "single step to full capability" approach to acquisition, that could spell unacceptable program delays. For example, as the Army's command-and-control system delivery schedule is built, the program management office in charge of that system is building the schedule around a complex series of applications being developed and integrated together. JEM and JWARN are two of those applications, but there are numerous others-many of which are unique to the Army. Meanwhile, the Navy builds its architecture around the integration of a similarly complex series of different applications. The same goes for the Marine Corps, Air Force and National Guard. The JWARN and JEM programs might never be able to field their software if they had to wait for a time when all services had "finished" building their computing environments.
'MAKE THE SOFTWARE MORE USEFUL'
The first iterations of JEM and JWARN had been developed, but operational users saw new opportunity for what the programs could do. By using a more modern web-based interface, the programs could be adapted to run in a wider variety of environments. The server that is actually "running" the software could be installed in a place that made sense-in some cases, on a local server at the command post, or perhaps in a cloud-based server that is globally accessible. The user would simply point a web browser to the appropriate server location. This web-based approach was one part of a three-pronged strategy to make the software more useful.
In 2014, the Joint Requirements Office for Chemical, Biological, Radiological, and Nuclear Defense approved the requirements documents for a second version of JWARN and JEM. This second version ("JWARN 2" and "JEM 2") would be where the newer web-based interface could be implemented. The Joint Requirements Office, the program offices for each application and the services' stakeholders also seized the opportunity to take a new approach to software development. The commercial side of the software industry had been leveraging faster development cycles with an approach known as Agile development.
GET AGILE
Practitioners of Agile development subscribe to 12 principles outlined in the "Agile Manifesto." The first two of these principles describe the value of "early and continuous delivery of valuable software," and "welcoming changing requirements, even late in development." The thought of fluid, evolving requirements might make a traditional defense acquisition professional cringe, but the commercial world recognized that tackling software development challenges with smaller, more easily accomplished steps ultimately resulted in more useful and more relevant software than when developers attempted to make one monolithic delivery of a grand design.
In 2012, the Joint Requirements Oversight Council updated its Joint Capabilities Integration and Development System (JCIDS) manual, the "instruction book" for how the requirements process works to acquire new defense systems and capabilities. One such revision made allowance for the fact that software development occurs in a context where the rate of change-in both the requirements and the environments in which software must operate-is so fast that it can often outpace the traditional acquisition system's very bureaucratic required processes. It offered an alternative model in which a system's requirements are bounded on four sides by "Organization and Oversight," "Hardware Refresh, Enhancements and Integration Cost Controls," "Application and System Software Development Cost Controls," and "Capability Requirements and Initial Minimum Values," (which could be simplified as "Oversight," "Hardware Cost Limits," "Software Cost Limits," and "Minimum Capability Required"). As long as a program is staying within the "box" bounded by those four areas, the requirements process can be delegated to a lower level, allowing for more rapid requirements-document updates, which in turn authorize more frequent updates and enhancements to the software itself.
In our personal lives, we are accustomed to software on our computers and mobile devices being updated on an almost daily basis, so this might still seem like an overly bureaucratic way of managing what is now "normal." But it's important to remember that without requirements documents stating a validated capability need, a program office is not authorized to spend money to develop or enhance something-even if it seems like the operational need is obvious.
On the other hand, the Defense Acquisition System is designed around holding programs (and their managers) accountable for fulfilling all of the requirements outlined in the programs' requirements documents, by a specified deadline. So, a requirements document that outlines a "blank check" of continuous updates and enhancements to be pursued indefinitely is not an option, either.
Yet we know from personal experience that that is exactly how software works in the 21st century. Requirements evolve, computing environments (e.g., operating systems, Java versions, message protocols, etc.) evolve, and if software doesn't evolve along with them, the obsolescence clock starts ticking as soon as that software development stops. The "Information Technology Box" (IT Box) was a compromise between the two realities, trying to blend the accountability and rigor of the traditional Defense Acquisition System with the reality of rapidly changing information technology requirements.
Dynamic requirements and frequent update cycles don't mesh particularly well with the traditional acquisition process, but by the time the initial capabilities documents for the second increments of JEM and JWARN were being written in 2014, the JCIDS manual had been updated and included provisions for a new, more agile approach to defense acquisition of software systems.
This new approach to software development in a defense context, the IT Box, was an initiative to bring some of the benefits of Agile development to a notoriously cumbersome defense acquisition system. It brought about a paradigm shift in the requirements-development process by breaking requirements into related functional groupings, known as requirements-definition packages, and then subdividing those into more manageable capability drops. So rather than an overarching requirements document tasking the program office to create a piece of software containing dozens (or hundreds) of new capabilities, each capability drop might only direct the addition of 10 or so new features.
More importantly, requirements approval and updates for those smaller packages and drops are delegated down to the O-6 (colonel) level to allow for more frequent updates. People representing the operational community for each of the services come together with leaders from the program offices and the Pentagon's Joint Requirements Office for CBRN Defense, and form a collaborative group called an integrated capability team. This team meets regularly to talk about what has been delivered so far, the services' priorities for features still to be built, and feedback from everyone involved-whether it be the operational forces using the capability or those at the Pentagon who are overseeing and funding the program. This working group is able to hash out the best path forward, and then take those recommendations to an approval authority at the O-6 level, rather than staffing the updates up to the general or flag officer level. The program office and developer can begin to tackle the requirements that are known and stable while other requirements might still be in flux. The end result keeps the product relevant while minimizing the bureaucracy and delay.
IMPROVING THE UPDATE PROCESS
Combining two approaches has led to more user satisfaction and a sense of buy-in from the operational user community: using smaller, more frequent updates to the core software capabilities described in JWARN's and JEM's first requirements-definition packages; and targeting integration with the individual services as their systems are ready to receive the updates. Feedback has been overwhelmingly positive, both from operational users at user feedback events and training sessions, and at the services' stakeholder level in the integrated capability teams that represent the services to the Joint Requirements Office.
That positive feedback and increased demand was captured by a memo from the Army Staff's G-8 on Sept. 25, 2017, requesting that the fielding of the new version of JWARN be expedited to Eighth Army on the Korean peninsula. Furthermore, the development of a cloud-based capability for JWARN and JEM has made the software available to users even when their service's native command-and-control systems are not available-for example, when units are back home in garrison. Users are now able to see meaningful progress in software development and can use the functionality that is ready now, even as they wait for enhanced functionality to be introduced later.
Perhaps the clearest example of the benefits of this streamlined approach can be seen in the transition of the products to the Defense Information Systems Agency (DISA) milCloud. The milCloud provides a platform for users around the world to access JEM and JWARN software. Because it is a cloud-based software platform, users are able to see a hierarchical list of CBRN events being updated by themselves and other users around the world. Sites exist on both an unclassified and a secret network, and there are lists of events on a training site and an operational site for each security level (unclassified and secret).
Integrating JEM and JWARN with the services' command-and-control systems-which provide command-post personnel with situational awareness of friendly force disposition, neutrals and threats-is still an important requirement. However, in DISA's milCloud, the program office has control of that environment and is not beholden to the services' development schedules for its individual command-and-control systems.
Previously, an update to a third-party software application like JEM or JWARN might have been ready for months (sometimes a year or more) before the service would be ready to update its command-and-control system with new or updated software applications. Now, when a new capability drop is ready, it can be fielded in milCloud and made available to users worldwide. Users accessing the cloud-based version of the software need only a web browser and an account on the system, and they can access the most up-to-date version of the software available. The user does not have to download, install or update any software locally, nor does the user's system administrator, since the software is delivered dynamically as a webpage from a server that is maintained by the program office. This speeds user adoption, training and feedback, and gets user feedback back to the developers more quickly, ultimately strengthening user satisfaction.
BETTERING A BAD REPUTATION
The JWARN 1 program of record began more than 10 years ago using the older JCIDS process, which was structured primarily to support hardware development. Unfortunately, JWARN 1 developed a dubious reputation in some circles because development was slow and costly, and didn't deliver product quickly enough for the return on investment to be obvious to the user.
When JWARN 2 adopted the IT Box concept and Agile development paradigm, it allowed the user more buy-in with a rapid and more streamlined cycle. The user sees multiple software builds of incremental capability solutions, the results of the development and a path forward.
The combination of stakeholder involvement in the requirements process by the integrated concept team, along with more frequent capability drops, has the operational user community excited about the product again. When the initial capabilities documents for the second increments of JWARN and JEM were being developed, the services were outlining their requirements for the implementations that would be fielded on their particular systems. The integration with the Army's Battle Command Common Services servers was the first iteration of JWARN 2 and JEM 2 to be tested, followed closely by a limited deployment on the DISA milCloud, which was the Air Force's chosen means of accessing the capability.
When the service-specific capability-drop requirements were first being written, the Marine Corps knew it would need a warning and reporting capability in the field. But when it came to the high-fidelity analysis for which JEM was intended, the Marine Corps opted instead to "outsource" its modeling needs to the Defense Threat Reduction Agency rather than having to maintain and support a modeling application and train its user base. So the Marine Corps did not even levy a requirement to integrate the software with their systems in the field.
However, after seeing the success the other services were experiencing with the new generation of JWARN and JEM, both on battlefield servers and in the cloud, the Marine Corps asked to "come back in" with JEM integration after all. Furthermore, the services gave unanimous support in August 2018 when the JPEO for CBRN Defense issued a first-of-its-kind multiservice fielding decision that made the version of the software on milCloud available to all services for operational use and training. The ubiquitous nature of the cloud and the similarity of the software across multiple environments made it possible to field to all services with one fielding decision.
CONCLUSION
There's a lot of talk about "acquisition streamlining" lately, and JWARN and JEM have shown just how effective it can be to use Agile development principles to tackle big challenges one little step at a time. By adapting the JCIDS process to allow for a faster, more fluid development approach, developers can provide users with results within a time horizon where individual users see results. When users see results, they buy into the process and the feedback loop gets even stronger. From a program with a reputation for slow development, to a new generation that's redefining what's possible by leveraging the cloud, the results have spoken for themselves.
For more information, go to https://www.jpeocbrnd.osd.mil.
CMDR. J. ALAN SCHIAFFINO, U.S. Navy, serves as acquisition product manager for JWARN in the Joint Program Executive Office for Chemical, Biological, Radiological and Nuclear Defense (JPEO-CBRND). Before joining JPEO-CBRND, Schiaffino was operational test director for the E-2D Advanced Hawkeye, a multibillion-dollar Acquisition Category ID program; executive officer and commanding officer of Navy Recruiting District St. Louis; and operations officer on the USS CARL VINSON, planning and executing regional stability operations in the South China Sea and Korean Operating Area.
MARY C. BAKER, an associate at Booz Allen Hamilton (BAH), provides acquisition and operations support for JWARN. Before joining JWARN and as a BAH consultant, she maintained acquisition and program management for shipbuilding programs in the Naval Information Warfare Systems Command in San Diego. Baker is an Army combat veteran and retired as a first sergeant in 2013.
This article is published in the Fall 2019 issue of Army AL&T magazine.
Related Links:
Assistant Secretary of the Army (Acquisition, Logistics and Technology)
Social Sharing