Not too long ago, while working on a project, the development team required a particular functionality to complete the work. The mentioned capability was required to be available to any of the company’s systems and to be up to date most of the time (the aimed goal was 100%). Many solutions came to the table, but at the end of the day, the real two alternatives were to build or to buy. Another option, which in this case was not available, but it is worthy to mention is Open Source (Hwangbo, 2013).
After a fast research, it was found that there were many software companies providing the required information, mainly as Software as a Service (SaaS), where the consumer is to use the cloud provider’s application running on its cloud infrastructure (Rafaels, 2015).
Build, buy, customize (open source or company’s packages) options have been challenging management for a long time and thousands of lines justifying one or the other alternative have been written.
During the evaluation process, I have found the following table, which has been adapted from (Wong, Maoz, & Desisto, 2015) very useful (Capabilities of Buy, Customize and Build Options):
| Buy | Customize | Build | |
| Ability to customize functionality | Weak | Strong | Strong |
| Integration with core enterprise applications | Strong | Good | Good |
| Updating abilities | Good | Strong | Strong |
| Minimization of use of maintenance internal resources | Strong | Good | Weak |
| Ability to add additional services | Weak | Good | Strong |
| Flexibility to add other data sources | Weak | Good | Strong |
| Ability to add additional features | Weak | Good | Strong |
In this case, the final choice, was the buy option (customization was out of the picture). The decision was based mainly on these criteria (Cohn, 2014):
- Budget, considering the total cost of ownership.
- The company’s technical proficiency on this particular matter. Specially for maintenance.
- Time constraints. The development team did not have enough time to build the desired application.
- The software needed was available without any modifications. No need for additional features.
- Building the software would have not created any competitive advantage for the company.
References
Cohn, C. (2014, September 15). Build vs. Buy: How to Know When You Should Buid Custom Software Over Canned Solutions. Retrieved from Forbes : http://www.forbes.com/sites/chuckcohn/2014/09/15/build-vs-buy-how-to-know-when-you-should-build-custom-software-over-canned-solutions/#7b45cb5c4849
Hwangbo, H. (2013, October 21). Enterprise Architecture for Emerging Technology: Build, Buy or Open Source. Retrieved from Emerging Technology Blog: http://usblogs.pwc.com/emerging-technology/enterprise-architecture-emerging-technology-build-buy-open-source/
Rafaels, R. (2015). Cloud Computing From Beginning to End. Lexington, KY: Ray Rafaels.
Wong, J., Maoz, M., & Desisto, R. (2015, March 05). Key Considerations in the Decision to Buy, Build or Customize Enterprise Mobile Apps. Retrieved from Gartner: http://www.gartner.com/document/2999118?ref=solrAll&refval=162179990&qid=50117e172f34528760c6ceaf6b3792c4
Jorge Luis Rodriguez Blog 
I like the matrix a lot and will use it in the future. I’m very much a buy before build or customize person. As you also mention in your last bullet, the main question that I pose to the business in making this type of decision is “will a custom-built solution give the business a competitive advantage?” If the answer is a simple “no” or a long, muddled, meandering answer, then it’s better to buy. A good example are finance applications. No business is going to gain a competitive advantage by building their own finance application – it’s a standard, commodity capability that hopefully everyone buys.
Another factor in making these kind of decisions is with ensuring the software development staff is focused exclusively on writing business rules and business processes. I do not want my software development teams to spend any of their time developing plumbing and other non-business rule concerns. One example was a new-hire that came in saying he developed an object-to-relational mapping solution that was better than anything commercial or open source. I didn’t believe him, but the main point is that if we adopted his framework, our limited software developement resources would now have been burning time developing and supporting a piece of plumbing that can and should be bought or open sourced.
One last observation on the last row of the matrix (Ability to Add Features) – “strong” for build scenarios and “weak” for buy scenarios makes complete sense. However, the irony that I’m only now beginning to appreciate, is that with “build” scenarios, this can be a double-edged sword, where responsiveness to user needs is the good side, but the downside is that some businesses allow the customizations to run amok, implementing way too many features and driving up the cost of ownership slowly but steadily. Thanks for a great post. -Scott
LikeLike
Jorge,
Thank you for placing coverage on the eternal debate of these strategies on make or buy decisions. We find this Customized vs. Vanilla debate particularly tricky with expensive ERP implementations, and in that area, the build option is virtually non-existent. In my opinion, there is no one clear answer. And while your tabular guidelines are indeed helpful, I look at my own field notes, and feel that the actionable position is still highly contextual on the industry, as well as the specific organization and its culture.
For organizations which have customized their mission-critical ERP systems over the years, they will eventually find future upgrades as extremely costly affairs and a challenging prospect. They can truly be a nightmare, and would perhaps lead many to lose hours in “analysis paralysis.” From my consulting experience, and having the opportunity to discuss with reflective organizations (post-trauma), there are indeed many lessons learned.
This is such as huge discussion, and as you hint, it’s always a trade-off decision — between changing the way the organization’s process works and adapting to the software’s way; or customizing areas where the organization has more control in its evolution. At any rate, I can argue that this is not black or white, or a strict matter of choosing one approach vs. the other. The true challenge to my mind, particularly for ERP selection and implementations, is finding the sweet spot and balance of mixing customized with vanilla. More and more we hear of happy endings for those companies who have used the hybrid approach, and are quite happy and at peace with their decisions because they have avoided vendor lock-in where possible, while enjoying out-of-the-box facilities where it makes sense.
Thanks again for advancing the class discussions!
– Ian (EA Bartolome)
LikeLike