Build Versus Buy

Quite a contentious discussion that has plagued the technology world for some time is the concept of build versus buy. From what we observe with our customers, we see most companies Buy versus Build based on two main concepts - "Is this a fundamental part of our business to own the IP of this technology?" and "Is our business so specific and different that no software Vendor could cater for this difference in a way that had a good ROI"? I couldn't agree more with this sentiment and it should be one of the main drivers in deciding if you should Build versus Buy

Let's be honest, the question is "grey" in that even if you are building yourself, you are often buying products or utilising existing products. The work then is more about stitching the different pieces together. As most will know, this stitching is seldom easy or riskless - quite the opposite. You also have to question if the maintenance and skills that come with this stitching are in your interest to take on as a business.

There is no right answer, but there are definitely recipes to help you decide, including:

1. Is your problem so specific, that no other tool, framework or off-the-shelf software could ever be utilised in an efficient and costly manner?
2. Do the tools on the market fundamentally not achieve what you need e.g. speed, scale, functionality, extensibility?
3. Do you plan to turn this into a product for which you will earn some type of revenue internally or externally?

If you answer Yes to the first 2 questions, then Build may well be a very good option for you. If you answered Yes to the 3rd option, your choice of revenue is typically never swayed by the fact that you have opted for prebuilt and bought software.

It is rare in the data space, in our experience, that customers have such a specific and rare problem that generic software cannot be a good base for your foundation.

I once had a very successful CEO tell me that the beauty behind the "Buy" option is that the team behind it has gone through all the struggles, bugs, endless nights of performance testing to get you that product. If you build it, you will most likely run into exactly the same problems and realise why Buy was the better option. Let's be clear, "Buy" does not necessarily mean that you have to pay in software costs, but rather that you are relying on a third-party piece of software to cater for a part of your foundation. You might find that you need a combination of these, as without a doubt, there are some "free" products that are better than the paid options and there are some paid options that are preferable to anything out there that is free.

Which begs the next question. Do you develop your data foundation in house, or do you use a dedicated implementation partner?

Without sugar coating the answer, the reality is that a combination of both may work best for you. The difference is that no-one will know your business and its operations better than you. Although implementation partners will attempt to understand your business, you do need to know that these companies will always move on to focus on other companies. It is not because they don't want to help, it is because this is how a business runs.

What is most important to establish is that implementation partners are usually quite good at operating known technology stacks and pointing you in the right direction. This is because they have most likely seen this problem before, can fast track some decisions and hopefully steer you away from potholes. 

I can say, with all transparency, that the main reason why CluedIn exists, and the concept of the “Data Fabric” evolved, was because every business was wiring together the same tools into their data foundation. Some failed, some succeeded, but too many had to reinvent the same processes. CluedIn was built because we saw failure after failure in wiring different systems together into an end-to-end coherent store for data. No matter what tool we chose, we always found that it didn’t fit naturally into the next stage of data processing. This meant that we couldn’t provide users with a platform and a suite of tools that allowed them to see data through its entire journey.

I can say confidently that the vote for build needs to be pretty significant for it to win. But there are also varying levels of what is considered build versus buy. Cloud stacks have given organizations fundamental building blocks for building their data foundation, but at the end of the day, you are buying technology.

The Data Fabric is nothing more than an accelerator where a Vendor has made some choices on your behalf. There is a point where you need to trust technology, otherwise, every decision you make would be met with weeks of scrutiny to make sure it covers all the checks and balances.