Search Blogs Blogs

Mandating affordability as a requirement: Baselining COTS software from the start

By: flood
According to Under Secretary of Defense Ashton Carter, a requisite for efficiency and productivity is to build affordability into a program plan from the outset. That means identifying what we can afford and holding contractors responsible for delivering within that constraint—and presumably preventing the government from changing requirements mid-stream. A lot of components affect our ability to meet this need. Much discussion surrounds starting with the “80% solution” that is available now—which would be welcome news to many of us product providers. At the same time, there will likely be pressure to reduce the technology risk “materials research” phase, which is another place commercial software comes into play. A program’s software content and its impact on overall program cost is an important place to inject affordability from the outset. It is well-recognized (with all the obvious qualifying caveats—more on that later) that, where commercially available software meets a program need, it is significantly less costly than custom-built and -maintained code. And both those points—the “building” and the “maintenance”—are very important. In fact, last year the Defense Science Board noted that the maintenance cost for commercial software can be as much as 10 times lower than that for free and open source (FOS) software. How is that possible, and how can it be evaluated? Here is what we suggest:
  1. Ask your potential commercial software provider about the applicable capabilities and how they map to a program’s requirements.
  2. Ask the provider for detailed information about the APIs and program-wide licensing to ensure the software can be integrated and a known cost can be determined.
  3. Collect the metrics necessary to do a valid cost comparison. For example, ask the vendor for the number of applicable software lines of code, the year-over-year maintenance costs, etc.
  4. Use accepted software cost and schedule modeling software to assess the effort required to replicate the existing capabilities using the known “lines of code” count from the vendor(s).
  5. Compare development costs, development time and maintenance costs over the program lifetime and consider your options.
  While this process excludes a number of benefits of commercial software, it does give a concrete set of parameters to begin the evaluation. Now, regarding the “caveats” about using commercial software instead of custom-developed code, several common “risks” are raised regularly: lack of access to source code, unpredictable maintenance schedule, distribution restrictions, etc. We certainly recognize that these can be issues if handled improperly, but there are a lot of examples where the use of commercial software perfectly satisfied these and other concerns. Let me offer a few litmus-test questions to apply before dismissing commercial software because of these potential “risks.” The first is, “Did you ask the vendor about adapting licensing, data rights, access, maintenance cycles, etc. for your program?” The second is, “Is the alternative less risky and more quickly deployed than the commercial alternative?” If the answer to either is “no,” then I’d suggest your assessment isn’t complete yet. I’ll be writing more on this subject in future entries. If you have any questions or comments in the meantime, I welcome your input.
Posted: 11/24/2010 8:39:47 PM