To buy or to build, that is the question.

Buy before build, is the mantra you would hear more often in enterprise IT. Most analysts would support this line and will have manier reports proclaiming the benefits. However a few independant analysts, tend to put a rather balanced perspective on things.

It appears buy or build decisions tend to fluctuate from buy to build and back to buy depending on where the equilibrium has shifted. The market forces make sure no option remains attractive long enough to become a successful mantra for all the time.

Most enterprises manage technology life-cycle thru some sort of adoption models. These parameters must be aopted in such models, to inform the continuos evolution of to-be state of enterprise architecture. Evolution of Cloud Computing (or XaaS) is a disruption that should also be kept in mind, while building these models. As options are no longer just buy or build, but could be buy, build or lease!

I am listing a few parameters I think that are very important. I would love to hear whether readers would like to add or contest any of these.

1. Commoditised capability vs differentiating capability
   Does the system that is sought to be bought, represents differentiating capability of your enterprise or it is a commoditised capability? For commoditised capability you would not mind going for a commoditised system. Differentiating capability, you would rather hold closer to your chest.
   
   Consider the scenario where differentiating capability is bought. If you then want to enhance the capability, it may need some enabling in the system. That enabler is a valuable intellectual property which vendor gets for free. Not only that vendor will immediately proliferate it to other willing bidders.
   
   
2. Short term TCO vs life time TCO
   Short term TCO of vendor product normally wins hands down vis-a-vis buy option. But when you consider life time TCO, including cost to replace, there may not be much difference in TCO. It is because, for built systems you can let them decay and save some costs before replacing. Whereas in case of bought systems, you need to keep pace with changes thru (sometimes forced) upgrades or else face unsupported obsolescence (quite risky). This works in your favour especially if you are an early adopter and back the right horse. Then building may be better proposition than buying.
   
   
3. Sourcing options
   Vendor supplied systems normally offer more sourcing options but are not necessarily cheap. Built systems are slave to the people who built it and sourcing options are limited. But this does not necessarily mean costly. This depends entirely on circumstances of each enterprise. Especially in case of mergers, retaining talent to nurture the built system may not be easy. On other hand the vendor of a bought system may get bought over or go out of business, thereby obsoleting the system. Which in turn will reduce sourcing options.
   
   
4. Time to market
   Vendor supplied system's biggest advantage is time to market. But this can be realised only when the systems are used straight out of the box. It is rarely the case though. Minimally you would have some integration to do, worse you will have to customise the system extensively to match your requirements. This fits in with the first point above. If its a commodity capability, you would want to use the system as is, with minimal integration. If necessary change the organisation to fit the system. But when its a differenting capability that system support, you would end up doing heavy customisation and integration. This would negate any benefits of off the shelf system.
   
   
5. Time to respond to events
   This is one of the big issue with vendor supplied systems. Where they will provide periodic upgrades and in some cases respond to mandatory changes (imposed by regulation). They are not likely to respond to event which are significant for your enterprise alone. You are on your own anyway. If you have adopted the system for differntiating capability then this would be a big problem.