How to think like a software factory
The Department of Defense needs to look to its own innovation hubs for lessons on how to keep up with the pace of technological change and emerging threats.
In today’s rapidly changing battlespace, the U.S. military cannot afford disruption. Technology development must ensure fewer bad things happen because of bad software. Mission outcomes are critical in this space, therefore building, learning and deploying software at the pace of emerging global and domestic threats is too. Today’s warfighters require reliable and secure software as precise and effective as the weapon systems it is designed to support.
Software modernization is a necessity, but teams operating within the Department of Defense must also navigate acquisition processes, including various operational, testing and cybersecurity requirements. Many of these are based on outdated policies, designed to win our last war, on legacy systems. The result is a limited capacity to respond to lessons of the past and a reduced ability to proactively develop solutions to avoid disruptions in the future.
The “secret” lies in achieving continuous authority to operate through continuous application of the risk management framework in a highly disciplined software factory. The RMF builds transparency and trust through the hard work of documenting controls. The policy is clear — no loopholes, no magic. Likewise, a software factory is not only a platform, pipeline or tech stack, but, more importantly, the collective people, processes and technology required to create value and eliminate waste in the software production for a particular mission.
Early, continuous delivery of software is critical to keeping pace in the U.S. military's race for technological dominance. The current acquisition process focuses on features developed in the past that are only now eligible for funding and unlikely to solve our current problems. Real success lies in continuously delivering software to production. Without this, agile has not manifested and we have nothing. We lose.
Embrace change while mitigating risk
Clearly, the old ways cannot solve today’s big problems or there would be no doubt whether defense can or will be successful in the race to technological dominance. The problem is one of change aversion rather than risk aversion. This does not mean people or programs should accept more risk — they should not, particularly in any discussion of cybersecurity. While many things can go wrong with cybersecurity or information security in general, there are known things which lend themselves well to checklists. If there is a risk or a vulnerability, there should not be deployment to production.
However, there is plenty of opportunity for change. Instead of perpetuating a failing program, stand up a software factory with balanced teams in product management, product development and product design. Defund current contracts to buy software delivery capacity in the form of a software factory, and require failing programs to fight for existence versus those that continuously deliver software to production.
An important piece of lean and user-centered design is that it results in both less code and less code sprawl. This reduces the amount of code that requires maintenance and assessment and reduces attack surfaces. A balanced team means cleaner, better and safer code. In addition, continuous monitoring is key to ongoing authorization as it provides a near real-time threat picture. Teams must build in and perform spot checks and penetration testing to identify and address risk, and then formally document renewal on a (recommended) quarterly basis.
Examples of successful implementation of these change methods and practices are visible across DOD software factories like Kessel Run, a division within Department of the Air Force Life Cycle Management Center’s Digital Directorate; Kobayashi Maru, the Space Command and Control Program; and the Army Software Factory within Army Futures Command, among others. The Army also recently shared plans to transition to a software upgrade process that mirrors commercial practices, where software teams write an app, make improvements and release periodic updates. The perseverance of change agents and innovators within the bureaucracy is key to success now and in the future.
At the end of the day, technological dominance is dependent upon outcomes — not continuous ATOs, not platform, not even people or process. None of this matters if we fail to ship outcomes to production.
Bryon Kroger is founder and CEO of Rise8, a digital services company.
NEXT STORY: Great job, US Embassy in Beijing