CTOvision.com

Context for the CTO, CIO, CISO and Data Scientist

You are here: Home / Archives for COTS

COTS

General John Hyten, Vice Chairman of the Joint Chiefs of Staff, Provides Context on Make vs Buy in the Federal Ecosystem

General John Hyten is the Vice Chairman of the Joint Chiefs of Staff. He is widely known as one of America’s greatest strategic thinkers. In the video below, recorded 17 Jan 2020 at the Center for Strategic and International Studies, he provided insights into his position and his priorities. He also provided context on the nation’s strategic competitors, and then dives deep into a topic near and dear to our heart, the need for improvement in how DoD acquires software.

Notes I typed as he spoke (so paraphrased just a little):

Have you watched how fast the United States of America builds software? It is just amazing, when you go into the commercial sector and watch how they build software it is just so fast, you look at Google or Facebook or Amazon Web Services or any of the small startups… it is just amazing.

Have you ever walked into a defense contractor and watched them build software? It is just a nightmare, and you look at any defense program and it is just a nightmare. Why? Is it because the United States doesn’t know how to build software? No we are the leading software nation in the world. We just have not translated that to the DoD.

He then talks about the need to change the industrial age models of DoD like the Joint Requirements Oversight Committee (JROC). He says the answer is to let people take risk. And we have to re-work how people buy things.

I have to agree. But study after study after study says it also takes leadership on the issue of make vs buy. Something else needs to be done besides simply translating best practices or allowing more risk in software development.

Here is an idea, how about a direct military order like the following: No one in DoD, or under contract to DoD, can write a single line of code unless the Vice Chairman is convinced that a commercial product does not exist that can do the same thing.

I know that is extreme. And rational minds would want to moderate that extreme position. But as a thought experiment, think of the billions of dollars that would be saved by doing that, and the speed at which we would bring new capabilities to DoD, and the war winning potential we would be equipping our military with.

Watch General Hyten’s comments below and let me know your thoughts on my proposal. Would love to know if you would support a policy that says defense contractors and DoD could no longer write code without permission.

 

For more background on this topic of COTS vs GOTS see:

Software Acquisition and Practices in Government: Build or Buy?

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

How Do Leaders In Government Decide Whether To Buy Or Build? Do They pick GOTS or COTS?

For decades government leaders have had to wrestle with questions of building solutions vs buying existing solutions. The needs of government enterprises have shifted over the decades, but so have the capabilities of commercially available products. It is critically important that executives in government frame their build vs buy/COTS vs GOTS questions correctly so they make optimal decisions. To help in this framing we are launching a new study designed to capture lessons learned and best practices in federal IT build vs buy decisions.

We would love your inputs on this study!

Please give us your thoughts at: The CTOvision COTS vs GOTS Study

The questions there were designed to be short and sweet to enable you to provide your inputs quickly. You can also reach out to us with your comments by replying to any of our newsletters.

Thanks in advance for your inputs!

Find the survey at: The CTOvision COTS vs GOTS Study

More Proof That The Government Should Always Prefer Commercial Off The Shelf Software

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.

 

More Content

Cyber War

SciFi

Super Bowl Ads Indicate Big Businesses Think You Are Afraid of AI

Tom Loftus provided an insightful review of some of Super Bowl ads in the 4 Feb 2019 Wall Street Journal. Like AI parody in SNL, these ads really poked fun at computers: Seriously, did anyone catch the commercials? If the Super Bowl is the zeitgeist, then it is safe to say that America is not […]

HBO’s Westworld: The Man In Black is a special kind of Twitter user

HBO’s Westworld is a modern take on the Michael Crichton SciFi tale of a robotic amusement park. The HBO version has a new twist. The creators/writers were all exposed to years of Twitter, which has influenced every episode and the entire arch of two seasons of the show. Now that season two is wrapping up, […]