Tue, 16 Nov 2004

Build vs. Buy -- A response

Background

Recently I received a copy of a memo forwarded by a CIO with an expressed preference for moving towards buying applications over custom building them. While I can't reprint the memo here, I do wish to cover some of the points it made and respond to them from an alternate perspective. The memo summarizes one case study within the company of what is portrayed as a successful acquisition and implementation. The application is based on a vendor product and customized in-house to a limited extent. The case study asserts the benefits of the buy decision over three areas -- the technology, the cost, and quality. The memo was written by an employee was involved in the acquisition and implementation of the software, and mostly describes the experience in positive terms. Certain cautions are mentioned, but not explored in depth.

Technology

An application purchased from a vendor will remain up-to-date with current technology, as long as the vendor maintains it, but the upgrade cycle may not fit well with the business needs, and a failed vendor can result in "abandon-ware".

Cost

A vendor can amortize the cost of software development over all customers, but the variety of customer needs can lead to higher overall development costs, compared to an application custom-developed for a single business.

Quality

A product viable in the open market is percieved to have a minimum level of quality and to conform to commercial conventions at an affordable price. Organizations often claim to value these things may in fact accept vendor promises. If these business have in-house development shops that are not held to the same minimum standards, it's a strong indicator that the value is not as great as appearances.

Over the next few articles, I'll examine in a bit more detail the specifics of these arguments for build vs. buy.

permanent link