Don’t laugh, but increasingly I find myself thinking that I’ve been here before. I often find that the underlying situation and argument are familiar, albeit in a slightly different context, with newer brands or technologies.

For example, I was recently asked to assist an overseas team respond to a request for proposal (RFP) for a Big Data Platform and three analytical use cases for the data. These days, Big Data is pretty much synonymous with the use of Hadoop. Hadoop is key for us as both a storage and processing platform, but we rely on others to provide the Hadoop platform itself. So, for this RFP, we partnered with a Hadoop distribution vendor, proposing a couple of solutions to deliver the use cases. A number of other consortiums also responded, one of which involved our Hadoop distribution vendor working with a different delivery partner.

The RFP process included a presentation of the proposed bid to the client and our session included a section delivered by our Hadoop distribution partner. Mid-way through this, the client interrupted the proceedings to ask our partner why they were working with us, when a few days earlier, as part of a different consortium, they had claimed Hadoop could deliver all the required function without needing additional vendor software. Our partner did a good job of explaining how our combined combination of technologies would help but quite honestly, it did disrupt the presentation somewhat.

As I returned home after the session, I wondered how we could have coped better with this key question. At its core, this is a build-versus-buy debate that has existed in IT for many years. Think of the emergence in the late 1990s of packaged-based ERP and CRM systems such as SAP, Peoplesoft and Siebel or the drive to cloud-based Software-as-a-Service (SAAS) solutions including Salesforce as more recent examples. It is interesting, though, that the debate has returned with Big Data. I think it may be because we are still in an early adoption phase and therefore the related software technologies are still relatively immature.

The build-versus-buy debate that has existed in IT for many years and has returned with #BigData Click To Tweet

Faced with the problem, then, what would I do in future, and what would I suggest to others to avoid this kind of situation?

Timing

First of all, I’m convinced it is better to explore this debate early on with the client. Better still, the business development team should already know the client’s appetite for build versus buy. Many mature clients I’ve worked with have stated policies that may favour a given approach, and it is therefore possible to avoid the situation altogether.

Value and priorities

If you are a package vendor competing against an approach which requires coding, it’s very difficult to win an argument on the basis of completeness of function. Proponents of ‘build’ can always claim that they can add additional functions to manage any shortfall of capability. It is probably best not to enter into this argument, or concede the issue and move on. The package solution has different advantages: it is all about what the client values most.

Build vs buy - it is all about what the client values most #BigData Click To Tweet

Unique, or perceived unique needs

There is an argument that custom code can deliver business advantage over a packaged approach. This may be the case for Hadoop thought leaders such as Yahoo, Facebook and LinkedIn, because their unique challenges have driven the incubation of new technical solutions. For most businesses, however, software is largely a commodity: it is how you use and deploy it that makes a difference.

Time to value and risk are likely to be important considerations for any client. A packaged solution should deliver more quickly than a code-based approach, at least in theory, and it is also important to remember that custom code requires ongoing maintenance. This, of course, also adds more cost later.

Audience and user base

One important issue is whether the solution is for the many or the few. The Big Data movement has introduced a range of new products and projects, many of which are open source and involve new languages and command-line interfaces. These may be good for small teams of data scientists or administrators but hardly attractive if you want to encourage take-up by business users. Simplicity of use is an important argument in this debate.

Both ‘build’ and ‘buy’ have their merits, and I do not want to defend one against the other here, only recognise that there are arguments on both sides, and discuss how to address some of them. And to encourage clients, business development teams and distribution partners to acknowledge which is a better fit for the particular purpose or use case.

I found it interesting, though, that there is not much recent discussion on this topic. The best I could find was a 2014 article, and a 2012 discussion from Gartner about adding the term ‘borrow’ to describe the use of open-source software. I do not think this debate is over, by any means, but I do know that the best time for discussion was not in the middle of an RFP presentation!