Build vs Buy: why no-ops tips the balance

This is pandering opinionated garbage and a rant. Please forgive me for it. I try to run a respectable blog, but occasionally I lose my temper. As many times before, I have had an interesting tug of war with myself this weekend over the build vs buy dilemma software companies face on many fronts.

I have had to remind myself of the main deciding factor of build vs buy: is what you are building a core competency of your business? If not, the only way you should ever build it is if it doesn't exist or if it saves considerable money and effort in the long term.  The long-term effort is something I often miss in this.  It may cost less to build and maintain than buy, but it often ties up or further complicates the responsibilities of core contributors.  On the other hand, the same can applies to an ops-heavy buy.  The long-term ops commitment of a poorly designed or misused vendor solution can outweigh the cost to build and maintain an in-house solution.

It is essential to factor in long-term people commitments either way in deciding whether to build or buy.  It is obvious that no-ops vendor solutions are the best value.  Enterprise systems that require continual administration and tuning have no place in a modern business.

A targeted no-ops vendor solution makes it very difficult to justify building it yourself and usually is a better solution overall since it is laser focused on providing very specific capabilities.  By contrast a typical enterprise solution scatter shot with 1000 "must-have" point-features that well-intentioned, but misinformed buyers asked for is a disaster both on cost and ops.

Vendors need to do a better job of not building peripheral non-essential features (stuff that is needed for optics only) and buyers need to do a better job of trimming the perceptual BS out of the requirements they send to vendors.