Build vs Buy

I was asked recently about build vs buy. Specifically what was my opinion? Without thinking about it I betrayed my software background by saying that the pendulum had swung too far towards buy, whereas with modern approaches to software engineering the risk involved in build is much less than it once was provided the requirements are well understood.

However since then I have had a chance to reflect on this and I think to answer this question requires a little more nuance. Broadly speaking there are three categories of problem to consider:

• Problems that can be solved by a commodity off the shelf product.
• Problems that can be solved by configuring an off the shelf product.
• Problems for which no off the shelf product exist.

The first category is a no brainer: there is no sense in writing your own word processor when there are several mature products on the market. Typically any unique business requirements for such problems will be sacrificed at the altar of the cost savings of commodity software.

The second two categories are more interesting. In my experience the biggest problem in IT projects is identifying and agreeing the business requirements. The first category resolves this by using the product to determine the requirements, but neither of the other two help with this. Modern products such as SAP and Siebel have such flexible data models that they can be configured and adapted to do pretty much whatever you want.

I'm not saying that organizations should go out and write their own ERP systems from scratch, but on the other hand I have worked on several projects where only a small part of the capability of such a large package is being used, so there is minimal value in buying rather than building in these circumstances.

The bottom line: if you don't understand your business requirements, build or buy makes no difference!