This post is the next in our series focusing on building vs buying software for government uses. Also see our CTOvision Study on Build Vs Buy in Government and How Do Leaders In Government Decide GOTS or COTS?
The issue of building or buying software for government uses is one of the oldest discussion topics in the federal IT ecosystem.
Another interesting study that hits on this topic is one tasked by the FY18 National Defense Authorization Act (NDAA). This study, led by the Defense Innovation Board, was chartered to explore ways to streamline software development and acquisition approaches.
The Defense Innovation Board (DIB) is an organization set up in 2016 to accelerate technological innovation and best practices to the military. The DIB is an independent federal committee advising the secretary of defense on a variety of technology related issues. It is made up of an eclectic group of experienced professionals from a variety of domains and with its charter and tasking has access to just about any information it needs to conduct any study or assessment. Any conclusion, recommendation or assessment done by this group is worthy of review. This is especially true of their 3 May 2019 report on Software Acquisition and Practices (the SWAP study).
Here are key take-aways from the Defense Innovation Board on the topic of Software Acquisition:
- The board recognizes that this topic has been studied to death. Countless past studies have recognized change is needed, but little changes.
- The board decided it would be foolish to simply reprint the 1987 DSB study on military software that pretty much said it all (see our review here). So the board took an approach of engaging stakeholders (including Congress, FFRDCs, contractors, the public and others) to seek ways that DoD can take better advantage of the commercial U.S. ecosystem.
- The goal of the board was to move past all the reports and studies that got so little traction.
- The board’s report did a good job of articulating the problem. It is pretty clear that the government, especially DoD, has to improve its ability to acquire software and continually improve software, at rates faster than adversaries. Adversaries are innovating fast in multiple technological domains including use of AI, ML, robotics and smart weapons. All indications are that our failing approaches really must change or it will be an even more serious national security issue than it is right now.
- The board repeatedly underscores three critical topics around useful software: Speed to mission, the need for people-focused software, and the understanding that software is different from hardware.
- The board delivers many recommendations. The executive level summaries of the report only focus on how the department writes and integrates software. But the full report makes it clear, this is also about how the department acquires commercial software, especially for business systems (like those supporting HR, finance, logistics) and enterprise systems (like cloud services or data center services or high end AI/ML services).
- The board understands that combat systems will almost always, for the near term, require some level of customization. But even these should take advantage of COTS anywhere they can.
The board categorizes software in a way very consistent with the 1987 DSB software study, but with a slight update in keeping with the modern digital age. The board categorizes software as one of the following four types (the first three being commercial based and the last mostly custom):
- Type A (Commercial Off-the-Shelf [COTS] applications): The first class of software consists of applications that are available from commercial suppliers. Business processes, financial management, HR, software development, collaboration tools, accounting software, and other “enterprise” applications in DoD are generally not more complicated nor significantly larger in scale than those in the private sector. Unmodified commercial software should be deployed in nearly all circumstances. Where DoD processes are not amenable to this approach, the Department should modify its processes, not the software.
- Type B (Customized Software): The second class of software constitutes those applications that consist of commercially available software that is customized for DoD-specific usage. Customization can include the use of configuration files, parameter values, or scripted functions tailored for DoD missions. These applications generally require (ongoing) configuration by DoD personnel, contractors, or vendors.
- Type C (COTS Hardware/Operating Systems): The third class of software applications is those that are highly specialized for DoD operations but run on commercial hardware and standard operating systems (e.g., Linux or Windows). These applications will generally be able to take advantage of commercial processes for software development and deployment, including the use of open source code and tools. This class of software includes applications written by DoD personnel as well as those that are developed by contractors.
- Type D (Custom Software/Hardware): This class of software focuses on applications involving real-time, mission-critical, embedded software whose design is highly coupled to its customized hardware. Examples include primary avionics or engine control, or target tracking in shipboard radar systems. Requirements such as safety, target discrimination, and fundamental timing considerations demand that extensive formal analysis, test, validation, and verification activities be carried out in virtual and “iron bird” environments before deployment to active systems. These considerations also warrant care in the way application programming interfaces (APIs) are potentially presented to third parties.
The above is just a high level overview. My strongest recommendation is that any tech leader in government block some time to dive deeper into the full report by the Defense Innovation Board. There are things that you can do yourself to improve the way the government acquires software.
Reading the full report will also give you insights into some of the most exciting things happening in DoD software.
It will also enable you to join in with your own ideas and suggestions, including thoughts on what the board may have missed or may want to dive deeper into in one of their future studies. I’ve certainly got a few ideas for them and will be looking for ways to lob ideas into the discussion (for example, I think the report should have focused far more on why government should buy COTS instead of building GOTS, and their own report seemed to jump and cheer when they found examples of government organizations that build their own stuff when clearly there are commercial capabilities that could have been used).
See the full report at: The SWAP study
And, if you have not taken our survey yet, we could really use your ideas. See: CTOvision Study on Build Vs Buy in Government
