Below is a research essay, written Dec., 2004 as part of my Undergrad in CIS. It is a must-read for any Project Manager or Software Engineer out there:
To build, or not to build? That is the question. (Friedman, Halder) This topic, brought up often by many Managers and Executives throughout the ages is probably one of the most asked questions in the software technology world that has yet to be answered fully. Purchasing COTS (Commercial, Off-The-Shelf) systems tends to be risky – the idea of bringing a “black box system” into a corporation can limit scalability and cost money in needing to buy future upgrades and components. However, The Standish Group estimates that only 30 percent of development projects themselves are deemed successful. 20 percent are deemed complete failures, and the rest are usually late and/or over-budget (make that 150 percent over-budget). (Strande) This has generally been accepted by the industry as being more expensive in long-term development and maintenance costs than purchasing a COTS system would be. However, with the risks associated with the purchasing of software that have been mentioned, could there be a better solution?
To figure this out, one must evaluate each process and understand what affect it has on the project lifecycle. Do the statistics support the logic? To understand whether building is better than buying or vice-versa, quality requirements management must take place. With bad requirements, developers are prone to fail in a build situation, and it is near impossible to pick a vendor that will meet the project’s needs long-term if a product is to be bought.
So, assuming good requirements have been established at the start, let’s examine the costs of requirements management in a build vs. buy situation. Even in a well-managed project, the requirements for the software system always change. It is near impossible to predict all problems that will creep up in any project. (Sommerville, 139) So further requirements must be established.
Developing software requirements focuses attention on software capabilities, business objectives and other business systems. As the requirements definition is developed, a better understanding of users’ needs is achieved. This feeds information back to the user which causes the requirements to be changed… It may take several years to specify and develop a large system. Over that time, the system’s environment and the business objectives will almost certainly change. The requirements must therefore evolve to reflect this. (Sommerville, 140)
In the build situation, this is an advantage. If good requirements have been established and as the design process evolves, so do the requirements, a system is much less likely to fail in the future, eliminating the extra cost of developed systems over “bought” systems. Developed systems are usually more scalable to the business and allow the system to easily adapt to the business’s needs.
However, even when building such a system with good requirements, you still have the disadvantage of the time it takes to establish such requirements and design the system. It is often advantageous to have a quick turnaround in the time it takes to implement a project. This is where buying software is more advantageous and will be less costly.
Requirements management is still a need when purchasing software off the shelf, however. Without proper requirements established, good decisions cannot be made regarding what to purchase, what vendors to use, and how scalable their product will be to the needs of the corporation. This is a downside to purchasing COTS software – it may be faster to purchase such software, but it is usually only faster when improper requirements planning has been established. This will be a risk to most organizations.
So with good requirements management and planning, it is more beneficial to develop software in-house due to reduced maintenance costs, however such planning takes extra time and effort – projects cannot be implemented in a short amount of time. However, it is probably more beneficial without good requirements planning to just purchase the software off the shelf, relying on the risk that the vendor purchased from may not truly meet the company’s needs, allowing the project to be implemented swiftly. The second choice as can be seen also has its disadvantages. So the question remains, isn’t there a better solution?
One other predicament that one can run into in a buy vs. build situation is in the testing phase of the project lifecycle. Sommerville specifies two types of testing, Validation testing and Verification testing. Validation testing can be referred to with “Are we building the right product?” Verification testing can be referred to with “Are we building the product right?” (Sommerville, 420) Both of these scenarios encompass all forms of detailed testing techniques, and just by the above statements one can summarize the advantages and disadvantages of testing in a buy vs. build situation.
In a buy situation, it is very tough to approach a product with the verification testing technique. Because a finished product is presented, it is tough to approach the product, whether bought as a “black box” or with the source included, and test the individual elements because one was not available during the planning and development phase of the product that was purchased. However, with proper requirements planning it is very easy to perform validation-type testing methods on a COTS product.
In a build situation, the verification testing techniques are simple if approached right. Along the way during the design and development phases if the product is continually tested, one can determine fully if the product is being built right. However, again, the validation phase can only be determined by good requirements, and especially with a developed project this can take a lot of time to determine if the right product is being built. So what is the solution?
The solution can be found in the foundations of computer history. Back in the early days of the personal computer, IBM revolutionized the future progression of computers by making the computer affordable for the consumer to buy. Essentially, they released the consumer of expensive costs in buying computers by making the production of computers an open standard. (O’Reilly) Open standards are what free the consumer from the high costs of buying products and give the consumers many more fast options to developing their own product.
How does this relate to the build vs. buy situation when it comes to Software development projects? In the year 1980, Richard Stallman, a graduate student at the Massachusetts Institute of Technology was frustrated with the many proprietary software systems that had to be dealt with. Often he would have to sign Non-Disclosure Agreements just to use the software to get his education. He had become accustom to the open-source/shared software that was common among the computer labs of various school networks of the 1970’s, but had been overshadowed by big business. Frustrated with keeping up with the proprietary business software out there, he wrote:
- I was faced with a choice. One: join the proprietary software world, sign the nondisclosure agreements and promise not to help my fellow hackers. Two: leave the computer field altogether. Or three, look for a way that a programmer could do something for the good. I asked myself, was there a program or programs I could write, so as to make a community possible again?” (King, 1999)
Stallman went on to become one of the pioneers of a new movement called “Open-Source Software” with his GNU, or GNU’s Not UNIX as it stands for, software. GNU was meant to be software other developers could use that would be compatible with UNIX systems, that they could freely edit, distribute, and use without the worry of NDA’s or other binding software agreements. His software was thereafter used by developers and system administrators throughout the world and became the de-facto standard of UNIX system tools. (openknowledge.org)
Stallman’s GNU and concept of Open-Source software opened a new method of software distribution which resolved both the build and buy dilemmas. Such techniques have been used by organizations such as NASA, retailers such as Amazon.com, and perhaps most of the Fortune 500 Companies out there. (O’Reilly) As can be seen by its growing use, it has been proven to be a successful technique.
NASA claims that, “Fundamentally, OSS (or Open-Source Software) offers an attractive third option to the build vs. buy question. Where ‘build’ offers flexibility and ‘buy’ offers accelerated development, incorporating an open source component might offer the best of both worlds. OSS is ‘buy’ without having to spend anything and ‘build’ without having to develop anything – it’s hard to imagine a better deal.” (Norris) So now the solution can be presented in the buy vs. build dilemma. How does OSS fix the requirements management nightmare?
Previously, it was mentioned that building was expensive and risky because maintenance costs could be high due to poor requirements planning. Also, building a project from scratch can be a slow process and can’t meet time-crunching project deadlines. By adding open-source into the mix of the build scenario, maintenance costs are less because an entire community of developers throughout the world are working on the project in addition to the corporation’s own staff. Fewer developers need to be hired, and one can expect high-quality software due to the large number of developers on a particular project.
It was mentioned buying was more cost-effective, but expensive in the short-term, and not as flexible. Open Source resolves this case by being able to replace bought software. No longer does an organization have to purchase the software to get a pre-packaged solution – just as was seen in the Richard Stallman example. Not only that, but the project is now as flexible as the organization needs it to be because the source code is readily available and can be customized and adapted as the organization sees fit. Scalability is endless.
In regards to testing, verification is now easy due to the availability of source code in Open-Source projects used. Source code can easily be evaluated and tested. Not only that, but due to a large community of developers around the world working for free, chances are they all have performed their own verification process on the software available. The validation process now becomes a no-brainer. Due to the openly available software and source code, the product can easily become adapted to meet the specific needs of the company.
A paradigm in software and IT history has taken place over the last decade. No longer is there a need for the build vs. buy dilemma. There are consequences with each. With the proper planning and decision making process, an organization can figure out a way to incorporate Open Source software to reduce the risks and costs of developed projects, while keeping their software specific to the organization. There is another solution. Before making the decision to buy or build one must take into account the vast availability of Open Source software available out there.
Works Cited
A Brief History of Free/Open Source Software Movement, from http://www.openknowledge.org/writing/open-source/scb/brief-open-source-history.html
Brinker, Scott, Build, buy or borrow?, from http://www.media3pub.com/usbank/articles/buildbuyborrow.html
Friedman, Steven Morgan and Haldar, Abhara, Answering the Build vs. Buy Decision to Best Leverage Your Corporate Assets, from http://www.basex.com/web/Basex%20Online%20Store.nsf/0/81d3a0b79720e40185256c7d00510810/$FILE/BasexReport.CMSBuildvBuy.EXECSUMM.pdf
Greenbaum, Joshua, Build vs. Buy In the 21st Century, from http://www.intelligententerprise.com/030422/607feat2_3.jhtml
Lewis, Bruce, Free Software: Solving the Buy/Build Dilemma, from http://web.mit.edu/wwwdev/cgiemail/buybuild.html
Norris, Jeff, Mission-Critical Development with Open Source Software: Lessons Learned, from http://64.233.161.104/search?q=cache:Jt4GKe60T6cJ:phk.freebsd.dk/pubs/ieee.software.pdf+build+software+vs+buy+oss&hl=en&client=firefox-a
O’Reilly, Tim, Ten Myths about Open Source Software, from http://opensource.oreilly.com/news/myths_1199.html
Sommerville, Ian (2001), Software Engineering, 6th Edition. Essex, England: Pearson Education Unlimited.
Strande, Jon, How to avoid the pitfalls of the traditional outsourcing model, from http://www.darwinmag.com/read/070103/license.html
