Build vs. Buy - what to do?
Date posted
26 May 2016
Reading time
17 Minutes
Build vs. Buy - what to do?
As a developer or architect, you'll often be faced with a problem that you need to address for a customer, for example, maybe you need to search across data stores, or have some form of workflow* or even store content. How do you solve it?
Inevitably the question becomes one of 'should we build something' or 'should we buy something' (assuming that there isn't a non-technical, simpler way of solving it first, of course).
Often, but not always, people congregate into either a build camp or a buy camp, and we can all be quite tribal about our viewpoints. Usually we'll hear statements like these below??? ??feel free to add your own in the comments section.
The Build Camp
We'll only build what's absolutely necessary and no more. Using a product gives us so much extra bloat that we simply won't use.
- If we build it, we'll know what's there and it will be easier for us to understand and maintain, as we invented it and coded it ourselves.
- If we use a product, we'll need to constantly pay consultants to come in and support it for us. They'll pull one over on us and we'll never get rid of them.
- If we build it, we can use all the new shiny technology. We'll be lean and not locked in to some dusty old product. We can even microservice all the things.
- We won't need to pay licensing costs as we'll own all the source and look after it ourselves.
- If we use a product, we'll be tied to their upgrade cycle. We won't be in control of our own destiny.
- If we buy it, we get a fantastic product that does all the things we need and so much more. We'll get to use all this cool stuff in the future. Look at all this extra functionality that we can use to improve the business.
- We can have the supplier provide a managed service for us. They know all the ins and outs of the product and can make sure it's configured properly for us.
- If we can use a tried and tested product, why would we build it? It's been heavily tested and proven in other environments for other customers. Look how well it's doing in the Gartner or Forrester analyst reports. No-one can doubt we picked a good product.
- If we buy a product, the supplier can give us a great deal that works out way cheaper because we could standardise on their tech stack. This brings about great savings for the business in the long run.
- We don't have the people to build anything. We'd either have to create a team from scratch, or get suppliers in to build something for us. At least with this product we get something quickly that we can use right now.
- Product X has all these abilities that have been demonstrated by the supplier. It can scale to cope with 10 million items per hour and it's been security tested by the Pentagon. It's a well proven technology. It can handle what we need it to do and more. It has a roadmap that we can follow and use to introduce new features to the business.
- Always focus on the user needs. It will be the users actually using the system, so if you can evidence a need for something then it's clear to anyone why a decision was made. Remember, facts > opinions.
- Consider that everything leads to entropy. Code rots, especially with a high turnover in developers. Aim to make understanding 'easy'. If you decide to use an esoteric language to develop in, then you're going to have problems getting people to support your system in the future, or even to build it in the first place. Establish clear development principles that help new developers understand things, and decompose your codebase into coherent, logical modules, separating out those that change frequently, from those that are less static. This keeps churn localised to a few specific parts of the solution. A good talk on this is Adam Tornhills your code is a crime scene.
- Use open standards and avoid lock-in. If you believe a product meets the user need, then ensure that you don't become locked into it. How difficult will it be to get your data out of the product if you wish to change? Data is the valuable asset here, not the product. How much will it actually cost to get your data out from the product? Factor this in to your considerations.
- Design for change. The business may decide to pivot into a new market; can your architecture or solution pivot too? How difficult is it to swap out a component? Build to established interfaces to minimise disruption to other parts of your system.
- Understand the business capabilities. If you want to build something, is the business geared up to support it? Something like microservices have pre-requisites. Don't just jump on the bandwagon and follow the sheep.
- Evaluate options yourself, don't rely on the reports. Carry out a tech spike to properly evaluate a product. Can it be automated for deployment? What about monitoring and metrics? How can you scale it? What happens when some sub-component fails? How long has the supplier been in operation? What is their support like? How easy/difficult is it to have people learn the product? (Frequently people say that product X is bad, but fail to recognise that they have invested little in building in-house capability with the product in the first place.)