You no doubt have heard of the Defense Science Board (DSB). Since its establishment in 1956 it has helped the Department of Defense and entire national security community wrap its head around ways to optimize science and technology in service to critical national issues. Every year they conduct studies on a wide range of issues. Board members and other invited participants are some of the nation’s greatest thinkers and most experienced professionals.
It always amazes me how DSB studies can stand the test of time. It is a testimony to the quality of thought this group produces.
This point really struck me when doing research on the topic of Commercial-Off-The-Shelf (COTS) vs Government-Off-The-Shelf (GOTS) decision-making in government (we launched a survey on this topic here and plan on writing about it extensively in 2020). Some of the critical issues around the ongoing COTS vs GOTS topic include:
- What can government decision-makers do right now to optimize the use of commercial innovation to support critical missions?
- What factors cause decision-makers to decide to use their own developers to re-create the wheel or make other sub-optimized decisions?
After reading a DSB report from 1987 (See Report of the DSB Task Force on Military Software) it is clear another topic needs to be addressed. We need to understand why we still need to study this topic after decades of study and recommendations. Clearly there are cultural topics at play here.
Here are some timeless points made in this three decades old DSB report:
- Many previous studies have provided an abundance of valid conclusions and detailed recommendations. Most remain unimplemented.
- The big problems in government software efforts are not technical. Issues are with management, attitudes, policies, practices and culture.
- DoD needs to change how software is acquired. Instead of buying software like DoD buys ships, new ways of setting iterative requirements must be established.
- In 1987 it was recognized that the civilian software market had grown exponentially. The total civilian market for purchased software was at the time estimated to be 10 times larger than the DoD market (three decades later is is hard to estimate how much larger it is, maybe 1000 times larger?)
- DoD can no longer create de facto standards and enforce them on the civilian market.
- DoD must not diverge too far from whatever the civilian market is doing, else it will have to support its own methodologies and systems with little resources or training commitment from others.
- Custom built software is notoriously bad and never delivers the functionality intended, and is always more expensive in the long run. The government should be aggressively looking for opportunities to buy, in the civilian market, tools, methods, environments and applications.
- Using commercial applications provides big gains in timeliness, cost, reliability, completeness of documentation and training. This point is underscored again and again in the report. Clearly, then as now, the cheapest, and fastest way to get software is to buy it in the commercial marketplace rather than to build it.
- Unfortunately, government acquisition regulations and procedures are heavily biased in favor of developing custom-built software for individual programs. In policy drafting and debate, the mass civilian market is generally ignored.
- Government programs should use commercial-off-the-shelf (COTS) solutions whenever possible, and burden of proof should be put on leaders who claim they need to extend commercial solutions or develop their own. COTS is preferred over GOTS.
- More technical talent in government is required, but not for building software, for managing programs and acquiring the right software.
Interesting isn’t it? We have so many new concepts and business models for software, and so many new delivery models and new devices. But human nature endures. To maximize government use of commercial innovation we will need to make changes to the way people think and make decisions.
Another interesting note: The leader of this 1987 DSB software task force was Turing Award Winner Frederick Brooks, a famous name in the software community. Not only did he lead some of IBM’s most massive and successful software development activities, but he became a community thought leader influencing how software engineering is taught at all major universities around the globe. He is now a professor of computer science at the University of North Carolina at Chapel Hill. His book on software project management titled “The Mythical Man-Month” is a must-read for any in technology leadership or management positions.
We will be writing more on these interesting topics of COTS vs GOTS. Next up we will provide insights from the 2018 Defense Innovation Board Software Acquisition and Practices (SWAP) report.
But if you are a government decision-maker today, ask yourself what you can do to help change the culture of your organziation and the government overall. Are you doing everything you can to advocate for COTS over GOTS? Do you have lessons learned that can help others understand how to make the best decisions in this regard? If so, please do what you can to share them. This includes participating in our survey. Please see: The CTOvision COTS vs GOTS survey.
