ACQUISITION AT SPEED
officer (CISO) from a Federal Reserve Bank and a senior developer serving the U.S. Special Operations Command—all of them Army Reserve Soldiers from the 75th Innovation Command—leaned in to support the student team project.
FUNDING CHALLENGES In addition to providing technical guid- ance and problem-solving support to the student team, the Soldiers learned key lessons while navigating the common pitfalls for Army Reserve innovation efforts tied to the lack of RDT&E funds (e.g., Antideficiency Act violations) and general challenges for transitioning tech- nology (e.g., lack of enduring sponsorship and programmed funding, intellectual property licensing).
A particularly challenging obstacle was DOD’s governance model for software development. Despite the students publishing the app as open source software, there was reluctance to approve use of operations-and-maintenance funds to operate the application. Legal concerns centered on whether development was “complete” and if the codebase would be used “as-is” to justify operations- and-maintenance funding from the Army Reserve. Tis is emblematic of a governance model tailored to a “waterfall,” or linear sequential, development process. One does not have to look further than DOD major acquisition programs to understand what waterfall efforts look like.
While the new Army Adaptive Acquisition Framework’s software acquisition path- way is focused on custom military-unique software development needs, the DOD currently procures commercial off-the- shelf software using the same framework as a multibillion dollar, 20-year life- cycle program. Per the waterfall model, the Army procures commercial software once all development is complete and
The team collaborated to bridge the “Valley of Death” and successfully deliver new capability into the hands of Soldiers and DOD personnel.
using operations-and-maintenance funds. Though operations-and-maintenance funding can be used after development to support minor improvements that do not provide significant additional func- tionality (i.e., patching), RDT&E funds are necessary for any development beyond the original functionality. Under current guidance, while there is room for interpre- tation as to what qualifies for “significant additional functionality,” there is a pref- erence to use RDT&E funds when there is any doubt.
ITERATIVE IS HARD IN DOD While waterfall development models are not without merit, there is no consider- ation in current DOD governance for modern agile development processes that emphasize continuous integration and continuous deployment. In the continuous model, which is ideal for projects that are driven by an engaged developer team with frequent customer interaction, develop- ment is never “complete” and new builds and updates are continuously deployed based on customer feedback. Software, which has developmental costs that may be measured in the thousands, or even as little as hundreds, of dollars with a life cycle measured in weeks, is currently held to the same standards as a major acquisi- tion program that is billions of dollars and decades in the making.
Not only may this be a policy gap on iterative software development, it is
also a challenge given how the DOD programs funding. Te annual DOD budget cycle is generally not receptive to line items without defined milestones, and reprogramming RDT&E within program-objective memorandum cycles is a painstaking process. Tese policy and programmatic challenges may have very real effects on the Army’s ability to inno- vate and achieve operational agility.
During the early months of its invasion of Ukraine, Russia attempted to jam internet service to more than 30 countries provided by satellite-broadband provider Starlink. A Breaking Defense article from April recounted the impression that the satellite-broadband company Starlink’s ability to rapidly patch its critical software made on a senior defense official. “ ‘From an [electronic warfare] technologist perspective, that is fantastic. Tat paradigm and how they did that is kind of eyewatering to me,’ said Dave Tremper, director of electronic warfare for the Pentagon’s acquisition office. ‘Te way that Starlink was able to upgrade when a threat showed up, we need to be able to have that ability. We have to be able to change our electromagnetic posture, to be able to change very dynamically what we’re trying to do without losing capability along the way.’ ”
Never mind that DOD would currently require the foresight to allocate and program funding two years in advance
https://asc.ar my.mil 11
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74 |
Page 75 |
Page 76 |
Page 77 |
Page 78 |
Page 79 |
Page 80 |
Page 81 |
Page 82 |
Page 83 |
Page 84 |
Page 85 |
Page 86 |
Page 87 |
Page 88 |
Page 89 |
Page 90 |
Page 91 |
Page 92 |
Page 93 |
Page 94 |
Page 95 |
Page 96 |
Page 97 |
Page 98 |
Page 99 |
Page 100 |
Page 101 |
Page 102 |
Page 103 |
Page 104 |
Page 105 |
Page 106 |
Page 107 |
Page 108 |
Page 109 |
Page 110 |
Page 111 |
Page 112 |
Page 113 |
Page 114 |
Page 115 |
Page 116 |
Page 117 |
Page 118 |
Page 119 |
Page 120 |
Page 121 |
Page 122 |
Page 123 |
Page 124 |
Page 125 |
Page 126 |
Page 127 |
Page 128 |
Page 129 |
Page 130 |
Page 131 |
Page 132 |
Page 133 |
Page 134 |
Page 135 |
Page 136 |
Page 137 |
Page 138 |
Page 139 |
Page 140 |
Page 141 |
Page 142 |
Page 143 |
Page 144 |
Page 145 |
Page 146 |
Page 147 |
Page 148
