“Build Versus Buy” is More a Scale of Options than a Binary Decision
As consultants, we’ve been involved in helping our clients to decide which is the best software to invest in (or not invest in some cases). This is quite a responsibility as we are putting our reputation in the hands of a vendor, and we know that tech vendors are amazing at making claims. We see it in every trade show we attend. Therefore, it can be impossible to verify all the features of every product.
From our experience, this can be difficult to get right. So here are a few lessons in buying software (or not) to avoid making costly mistakes.
Limiting Your Potential Options is Sensible but Dangerous
One sales tactic is to present two options. This makes sense in some ways: management is time constrained and doesn’t want to assess all 100+ options that are possible, but this can lock you into a limited way of thinking, especially if you only assess two extreme “buy“ and “build” options.
Scale of Product Types from Build to Buy. By Jake Watson.
So you want to look at a variety of options, and for most organisations, look at options across the scale. We find a managed Platform as a Service (PaaS) in the middle of the scale, fits well for most but not all!
Think Beyond a Product
You may also want to consider a mix of both build and buy components; this can get you closer to fulfilling a set of complex requirements in a reasonable budget and timeframe.
One of our favourite examples is Fivetran, a vendor that offers a super quick and easy way of getting source data into your Lakehouse or Warehouse. However, it can cost a lot at scale, so you may end up doing the math and finding that building your own ingestion is more cost-effective for some, but not all, sources. Or try open source (Airbyte, Meltano).
And yes, maintaining two or more systems is generally worse than one, but that should be a guideline, not a rule, as sometimes, you are the exception.
There are Too Many Choices Though!
You can go too far the other way and spend months going through dozens of options out of 1400+ products that exist in data and AI.
One example of the variety of options available to you is real time data processing, where you can choose from least to most managed:
- Build Kafka on AWS EC2s or Azure VMs (IaaS*)
- Build Kafka on Kubernetes (IaaS / PaaS)
- Half-build, half buy Kafka on Managed AWS Kafka (PaaS)
- Mostly buy (with some build) a cloud managed streaming service on AWS Kinesis, Azure Event Hub or Confluent (PaaS)
- Buy a Low-Code Real Time Streaming on Azure Stream Analytics or Nussknacker (PaaS / SaaS)
*For those who haven’t come across IaaS, PaaS and SaaS we recommend this article.
We’ve probably missed a few more options, and this doesn’t even consider rivals to Kafka (Red Panda, Pulsar) We understand that this can feel overwhelming, so the sensible approach is to take a funnel approach and briefly compare lot of options to quickly to exclude and then narrow down to a few options for a deeper comparison.
Three of the biggest reasons we’ve come across for product exclusion are:
- Too expensive for the budget
- Bad fit for the team that will build and maintain the software (say, for example, knowledge of needing to use Java, in a team that only knows Python and SQL).
- Doesn’t meet security requirements
So start here before comparing more technical requirements that will require more work to compare and make a list of must-haves in MOSCOW) before comparing nice-to-haves requirements (must haves in MOSCOW) before comparing nice-to-haves must have’s in MOSCOW) before comparing nice-to-haves to save on extensive comparisons.
Where to Start
Starting a product comparison can be the hardest part if you have no experience in the domain. There are a good few places to start: hiring expertise if you don’t have the time. Oakland is often called in to assess a client’s options. As we are tech-agnostic and have experience working with many different clients, we know what works and what doesn’t! (shameless plug for us), read blogs and books by subject matter experts (check out the Data Platform Journal another shameless plug) or use social media for advice.
Try to avoid straight-up sales pitches and salespeople early on; you are trying at this stage to gather information to make a better-informed decision later on, not make a decision right now. Most have useful guides and content which you can use to inform your decision-making.
Modern Data Stack is also a great website for finding a range of data solutions, though skewed towards smaller start-ups. Gartner is another option if you have a license, but it skews towards established buy solutions.
What to Watch Out For When Buying Software
Avoid bias towards slick sales staff and fancy user interfaces: vendors can hype up their products with years of sales experience, whereas engineers have little to no sales experience to hype up their build option.
Also, how much does a good User Interface (UI) for your users matter? For engineers, often not much, non-technical users, a lot.
Buyers may not realise that even heavily managed solutions require some configuration and support, not as much support as a build option, but this aspect is often forgotten about.
People tend to also forget about the 10% trap, where on average a complex solution requires 10% to 20% of its requirements to be met by highly customisable software.
We’ve seen a number of times people look at and/or test the simple use cases and forget the more difficult requirements they have, which inevitably means that the solution comes unstuck and can’t deliver on all of the requirements. Test your potential solutions against your most challenging must-have requirements.
Beware of your own Engineer’s Biases Towards Build
So far, this may sound a little biased towards “build“ solutions, so we’ll rein it in here.
Most experienced engineers would back themselves to build solutions that can also be bought if given the time and money, but just because you can doesn’t mean you should. Often, projects take longer and throw up difficulties along the way.
So, if the build and buy solutions cost roughly the same and both meet requirements, we would er on the side of caution and go for the buy option.
Another classic trap engineers fall into is pitching a solution that is technically better but doesn’t improve the organisation: making a pipeline run faster with fancy new tech doesn’t always make the organisation’s profits larger.
If you’re not an engineer, then you may be more likely to be biased towards a “buy“ option in our experience, though again, there are exceptions.
Summary
So, in summary: avoid extremes, gather information before engaging sales teams, compare using the most difficult and important requirements first, be creative and check your biases towards either buying or building.
Author: Jake Watson