Buy vs Build

(Pulling out my soap­box…)

One of the clas­sic ques­tions in IT is “buy versus build”. When you need new soft­ware, do you buy it from someone else, or do you pro­gram it your­self?

People of­ten trivi­al­ize this choice. “Why”, they say, “would you build your own word pro­cessor or spread­sheet when you can buy per­fectly good ones from Mi­crosoft?” It helps when you ask this ques­tion to use a a piece of shrink-wrapped soft­ware like Of­fice or a com­plex product like Or­acle as your ex­ample. It seems that any­one who would build their own soft­ware when there is a com­par­able product you can buy is out of their mind.

But it’s not that simple. (If it were, we wouldn’t have MySQL.)

On the oth­er hand, people also of­ten look at ex­ist­ing products and de­term­ine that they don’t meet their cri­ter­ia. The product is too ex­pens­ive, doesn’t quite do the right thing, or uses the wrong tech­no­logy. De­vel­op­ment isn’t that hard, and if you de­vel­op it your­self, you have total con­trol so you can make sure it works ex­actly right. Plus - no li­cense costs!

And again, it’s not that simple.

Here are some bits of our real­ity in NIBR:

  • Soft­ware pur­chased for use in our en­vir­on­ment rarely, if ever, works cor­rectly right out of the box. Pur­chased soft­ware of­ten takes teams of people work­ing for months to con­fig­ure it. If you buy soft­ware from a vendor, it rarely does everything that you need, and if of­ten has bugs that you can’t get fixed.
  • In­teg­ra­tion has a cost. One of the great com­plex­it­ies and costs for cent­ral IT is the main­ten­ance and op­er­a­tion of the “en­ter­prise”, which means the col­lec­tion of all the soft­ware that has to work to­geth­er. Buy­ing some­thing that doesn’t work right with everything else can cause huge head­aches (i.e. costs) for years. Years.
  • Soft­ware that you build of­ten comes back to bite you in three or four years, re­quir­ing up­keep.
  • Dur­ing that time, vendors will have im­proved their products, or brought out a new product that is bet­ter than what you wrote.. re­quir­ing an up­grade pro­ject.
  • Li­cense costs are enorm­ous, and only go up.
  • Some­times, an in­tern­al de­vel­op­ment will help drive down li­cense costs be­cause it gives you an al­tern­at­ive when ne­go­ti­at­ing.

The ques­tion isn’t really “buy vs build”. It’s:

  • buy, vs
  • buy and tweak, vs
  • buy and con­fig­ure ex­tens­ively, vs
  • buy and cus­tom­ize, vs
  • buy and com­mis­sion someone else to cus­tom­ize, vs
  • build by hir­ing someone to im­ple­ment your design, vs
  • build

My points:

  • The buy vs. build de­cision is not nearly as easy as it is usu­ally made to sound.
  • Char­ac­ter­iz­ing a de­cision as a “simple buy-vs-build” does a dis­ser­vice to the or­gan­iz­a­tion mak­ing that de­cision.

(Why, you may ask, am I bring­ing this up? Has NITAS re­cently been char­ac­ter­ized in one way or an­oth­er? Well, pos­sibly and prob­ably, al­though no spe­cif­ic ex­amples come to mind. The reas­on I men­tion this is that I con­tinu­ally hear people us­ing the term “buy versus build” as if it really were that simple - some­times re­l­at­ive to NITAS, some­times re­l­at­ive to De­vel­op­ment IT, and some­times seem­ingly pro­pos­ing that one should al­ways buy. Yet none of the de­cisions on the table or be­ing im­ple­men­ted now were that simple. To un­der­stand how to im­prove in the fu­ture, we have to un­der­stand the reas­ons we are where we are, which means fa­cing the com­plex­ity.)