Feb 082011
 

The question of whether an organization should build software or buy it dates to when the first significant COTS packages (typically for accounting, computer-aided design, or manufacturing resource planning) appeared on the market between 1970 and 1990. Search for “build vs. buy software” on Google, and you get 52 million results. Most of the results on the first pages are dated around 2001-2002, so one would think that the question has been settled, mostly along the following lines:

  • If you need a capability that is fairly generic, and will not in itself give you a competitive advantage (the way you apply it may be superior to how others do it, but the software itself will not make a difference), then you should buy a COTS package.
  • This will not only give you the desired functionality earlier than if you developed it, but the total TCO will be lower because internally supporting yourself is very costly.
  • A vendor will have much more money and human resources to throw into supporting and evolving the product than you would on your own. The Y2K issue was a case in point: companies with proprietary software sometimes had to spend a lot of money to verify or correct it so it would work in the new millennium, while clients of (viable) software suppliers only had to communicate with the vendor and wait to install the patch. In fact, Y2K caused a significant modernization of the portfolio by making companies retire old software and buy newer COTS packages.
  • If, on the other hand, you have proprietary algorithms or methods that give you a competitive edge, or if you are “ahead of the curve” and the capability you plan to introduce is unique and no one supplies it commercially, that’s when exceptions are justified and you may want to “roll your own.” But then, you should still be ready to throw your software away and switch to a COTS package when the competitive advantage disappears.

There are several reasons that, even for “classical” software such as enterprise resource planning (ERP) or customer relationship management (CRM), the debate refuses to go away:

  • Internal business customers often establish a list of requirements on which they are unwilling to compromise much. Since no commercial package can do everything for everyone, an internal solution may seem appealing since it can seemingly be designed to do everything the business wants.
  • COTS packages usually have a stiff up-front license cost. Even in organizations that can capitalize software, and therefore amortize it over several years, the cash still needs to be spent.
  • Internal development gives a company a sense of control over its destiny, and in particular the ability to prioritize new features and fix problems quickly without waiting for a commercial vendor’s next release cycle.
  • Various collaborative software frameworks (e.g., Lotus Notes/Domino circa 1995, Microsoft SharePoint since 2007) allow the rapid creation of ad hoc workflow management applications. Indeed, such applications tend to proliferate quickly when such a platform is introduced because they can often be created and rolled out with no IT involvement or governance.

These counterarguments in turn deserve their own rebuttals, and we could go on for a while. The one thing worth adding to close this discussion is that software as a service (SaaS) has added an alternative: instead of building or buying, there is a new “leasing” option available. This is important because the major social networks function that way — and the rent is often zero.

{For more of the author’s discussion of the “build versus buy” debate, see “If You Build It, They May Not Come,” Business Intelligence Executive Update, Vol. 11, No. 1.}

Discussion

  4 Responses to “Build vs. Buy: A Debate that Keeps Coming Back”

  1. Claude,

    The build vs. buy debate is often fueled by the inadequacy of “classic” software to adapt to business processes. This seems to be an open secret in the enterprise software market. Customers using these COTS applications are often forced to change to generic processes on the guise that these are “best practices”. So your point is correct: using standard practices means that you lose competitive advantage.

    Organizations are often faced with massive customization and huge maintenance costs with COTS enterprise software. So the TCO of COTS vs. build is often a calculation about which is the worst evil.

    The other open secret is that specialized vertical providers often have the level of flexibility (without code customization) needed to adapt to business processes and competitive advantages. The cost burden of integration is slowly disappearing thanks to support for WebServices and moves to component-based SOA. And, these can often be more easily extended by the customer to achieve all the advantages of build and buy with less of the disadvantages.

    There can be a misleading impression to technology buyers that they must select one of the large consolidating ERP vendors. As if business was a game and you need to pick a winner rather than what is best for you.

  2. This topic (buy vs build) is especially interesting, and has a special twist in eGovernment sector, especially state government.

    Across government domains as diverse as Health/Human Services, Unemployment Insurance, Transportation, Licensing/Permitting, Revenue/Tax, Justice/Law Enforcement, etc, we see a continual pressure among states to adopt systems frameworks which have been successfully implemented and proven in other states — a type of pseudo-COTS approach — which has risks (and potential rewards) of it’s own.

    Vendors are busily investing millions of dollars upfront in COTS-like solution frameworks for the most viable of these government domains (Medicaid Modernization and Health Care/Insurance Reform are very popular now).

    Pseudo-COTS risks are mitigated when the framework is well architected, technology-agnostic, flexible/adaptable, becomes widely adopted through configuration across a substantially diverse customer base, and costs to maintain the “core” application are fairly distributed among many implementations.

  3. […] This post was mentioned on Twitter by Alwin van der Veen, Kevin Brennan. Kevin Brennan said: Reading: Build vs. Buy: A Debate that Keeps Coming Back http://bit.ly/hNt9UH #baot […]

  4. Great Article..It was very informative..I need more details from your side..include some tips..I am working in Erp In India

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)