The following HTML text is provided to enhance online
readability. Many aspects of typography translate only awkwardly to HTML.
Please use the page image
as the authoritative form to ensure accuracy.
Critical Code: Software Producibility for Defense
Put simply, engineering practices and technology choices for precedented systems (such as stable back-office systems capabilities) are guided by convention (such as commercial best practices for such systems), while engineering practices and technology choices for unprecedented systems and components are guided by processes for mitigating engineering risk. In fact, there is a constant pace of innovation even for seemingly established functional capabilities, such as back-office systems, with some areas of innovation and other areas that are more guided by convention.
Following precedent may require engaging in a process of adapting previously unique business practices to reflect more “standard” or “conventional” operations practices that are more readily supported within mainstream systems and ecosystems, particularly when there is correspondence with modern back-office systems in the commercial world. This adaptation of functional goals to achieve consistency with normative practice is an explicit part of the commercial requirements engineering process. The DoD and other government agencies may struggle more because they may find it more difficult to compromise, and for many good reasons. But the extent to which the DoD can find commonalities (and avoid unnecessary differentiation) with other government agencies creates opportunities for major cost reduction, risk reduction, and process simplification.
As noted in the previous chapter, the need to develop unprecedented systems is a consequence of the highly complex and rapidly evolving operational environment within which the DoD must operate and execute its mission. Complexity is increasing, as is the difficulty of the threats and challenges. Highly capable information technology is now ubiquitous worldwide, and adversaries have ready access to cutting-edge technology. Mission and deployment priorities are constantly shifting. The DoD must collaborate extensively with other agencies, nongovernmental organizations (NGOs), coalition partners, and others in constantly changing configurations over which the DoD has no control. Operational decisions are derived from a broad diversity of inputs. Command-and-control models must adapt to rapidly evolving threats. Success in this environment depends on systems designed for flexibility, agility, and robustness, but it also requires flexibility, agility, and robustness in the process by which systems are developed and continue to evolve. There is much less opportunity to rely on precedent and much greater requirement to undertake a process of ongoing innovation. This process of innovation entails acceptance of certain categories of risks. (See Box 2.1 for details.)
Commercial best practices have also evolved for developing unprecedented systems. Air traffic control, telecommunications switches, middleware (such as from IBM and Oracle), operating systems (such as from Apple and Microsoft), and large-scale web applications (such as from Google, Facebook, and Amazon) have been developed under commercial best practices with varying degrees of success. However, these large-scale, unprecedented systems emerged over a period of years from market opportunity without a specification-driven need, while others did not. Besides business savvy, the main critical success/failure factors in these situations have involved the ability to assess potentially disruptive technologies and competitor strengths, and the corporate agility to adapt to change.1
This chapter addresses the processes and practices by which these risks can be understood and addressed in the engineering of systems. A principal conclusion is that a well-managed incremental (iterative) process, supported by appropriate evaluation and measurement approaches, can more reliably lead to successful outcomes even when there are significant engineering risks. On the other hand, attempts to produce innovative or unprecedented systems using familiar linear (“waterfall”) processes
Michael Cusumano and David B. Yoffie, 1998, Competing on Internet Time: Lessons from Netscape and Its Battle with Microsoft, New York: The Free Press. See also Clayton M. Christensen, 1997, The Innovator’s Dilemma: The Revolutionary Book That Will Change theWay You Do Business, New York: Harper Business. See also Robert L. Glass and P. Edward Presson, 2001, ComputingFailure.com:War Stories from the Electronic Revolution, Upper Saddle River, NJ: Prentice Hall PTR.