To Buy, or Not To Buy. To Build? is the Question

Should we buy this application, or build it in house? Maybe some of each. How should we make that decision today?

Build, Buy, or Both?

This is somewhat of an age-old debate. IT departments were initially chartered with cost-reduction initiatives. Automate this process, reduce errors in that process. For some companies, IT departments stopped becoming a cost-center and started becoming a profit-center. Initiatives began to appear that were designed to enable top-line growth, not just cost-reductions. Enable this sale, encourage that one.

As companies objectives for the use of software evolve, we should probably revisit the age old question of build versus buy. But there’s also a middle ground – do some of both. Almost all enterprise software is intended to be customized. Many open-source products are created as extensible frameworks. Companies package applications into suites, and distribute stacks (collections of open-source software, pre-assembled and validated to work with each other).

The game hasn’t changed, but the players have. We should revisit this question.

Their Answers

This question has been asked and answered before. Collecting the answers that have been out there for a while:

• Packaged product vendors tell us to buy. “You should focus on your area of expertise, your products, and leverage our area of expertise, our products.” A very compelling argument. For any given IT department, any particular project is a one-off project. The IT department of an air-conditioning unit assembler/manufacturer is going to have little or no experience in developing a CMS (content management system). A community college is unlikely to have billing and invoicing system experts in-house. The argument is that it will be too expensive for these inexperienced teams to work through the hidden complexities and difficult problems of developing these systems. A vendor of one of those systems will be staffed with experts in that particular system. The packaged software vendor will have been distributing the cost of solving those problems across multiple customers. No one can build Quickbooks for $300. A company is better off buying this packaged software and tweaking their accounting system to use it.
• Many IT workers tell us to build. Any of a number of factors cause people to present this argument. We should dismiss the specious arguments that all fall in the “not invented here” category, or are self-serving. I once worked with a client who’s motto was “Invent.” Their IT team took that to heart, and perhaps selected to build when they should have bought. I also worked with a client who’s motto was “Think.” I believe their IT department did a better job in thinking about when and when not to invent. There are certainly situations when building is appropriate. There may not be a product available for purchase. There may be intellectual property considerations – if Dell is looking to further reduce their lead times or increase their inventory turns, they may want to do that work in-house, simply to prevent outsiders from learning what they already know. In these cases, the IT department does have expertise to rival or surpass the software vendor.
• Enterprise Software is some of each. Enterprise software vendors apply a modified version of the packaged software vendor’s argument. They will point out that the hidden problems are so complex, or the scope of the solution is so large, that no independent IT team should even attempt to solve it. And they generally have a point. But this argument can be weakened. Thirty years ago, no one would consider running a business on Quickbooks. Accounting practices are different for every company. Intuit decided that there was an underlying theme of commonality, and built a company around that theme. Their customers compared the costs of adapting their accounting to match the software with the costs of custom-developing a solution (or paying an enterprise software vendors to customize their “starting points”) and decided that process change was cheaper than product purchase. Enterprise vendors still have an advantage when there are no alternatives that are “close enough” to their solutions.
• Open Source is All of the Above. Open source solutions are “free*.” Companies can download and install free software that attempts to be equivalent to packaged software – install and use. Subversion is a great example of this – a company can install subversion as a source code control system, or they can purchase a solution like MKS, Clearview, or Visual Source Safe. Open Office competes with Microsoft Office. AVG Anti-virus competes with McAffee. Open source solutions may be development environments like Ruby on Rails. They are designed to reduce the cost of building a solution. The more interesting open source solutions are frameworks and stacks. Drupal is as much a framework as it is a CMS. A company can build a solution by enhancing a “free” framework with a combination of free modules and custom-developed modules. A company can build this solution to run on a free operating system, a free webserver, and a free database. A vendor may sell a “stack” of free packages – certified by the vendor to work together. Some stacks are even free – like LAMP (linux + apache + mySQL + php). Combine a LAMP stack with Drupal, and you may have 90% of the functionality of an enterprise software solution. A small amount of (additional) customization can get you to the same end result with a much smaller price tag.

*Free, in this context means that other costs are relatively equivalent to other choices – training to use a new process, or new software, or both, is roughly the same for all of the choices.

Hat tip to Francis Dion, for his recent article on this subject. Here’s his opener:

Back when I was a corporate IT staffer, I used to hate arguments such as this one, confident in the belief (like everybody else in this business) that we could do better than anything that existed out there.

Now that I am a bit (ergh, quite a bit :-) more seasoned, my views on this topic have changed radically.

Buy vs Build

Finding Your Answer

Ultimately, each decision will have to be pragmatic, and will depend on a number of constraints and factors that are specific to your business. Assuming you have already ruled out the infeasible products and approaches that you deem to be “too risky”, you are left with a set of solutions. Now filter those based on your constraints:

• Financial Constraints – are you bootstrapping a startup, or trying to burn through some VC cash?
• Time Constraints – do you have a year to get something built, or will you be sacrificed in a month if your solution isn’t live?
• People Constraints – do you have people with the skills to build or extend and support custom development. If you answered yes – ask yourself again – do you really?
• Intellectual Property – will this software be leveraging or enhancing your core-competencies? Is your business model dependent upon differentiation in this space? How much would it hurt if your competitors (inexplicably) started doing the same thing?
• Vision – your company may have a strategic vision for developing tools to support it’s ongoing business. Not sure why, but maybe you do. Don’t change your nature because of math. Stick to it, and good luck with that.

Select By Value

Once the constraints have narrowed the range of possibilities, we have to make rational decisions based on ROI.

We start by understanding our requirements – why are we building or buying in the first place? We then narrow our possibile choices to those that would achieve our goals.

We look at the TCO (total cost of ownership) of each solution approach. This includes purchase price and maintenance fees (if any), development costs (in-house or outsourced), and training / process re-engineering costs (if any).

We combine the expected gains and costs to identify the expected value for each approach.

We look at the timeline for how quickly we can get a solution in place, and incorporate that timing into our ROI analysis – leveling the playing field by comparing the net present value (NPV) of each alternative.

Conclusion

There isn’t a one-size-fits-all answer. Generally speaking, look at your options, apply the constraints of your reality, then do the math.