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.

And then conversely, you have the buy camp:

The Buy Camp

  • 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.

These examples are admittedly, quite contrived, but they aim to expose some of the opinions that you’ll frequently hear. Is there a better way? I believe there is, and the answer is somewhere in the middle between build vs buy. It may even be a combination of the two.

The reason why I say this, is that it really should boil down to evaluating the needs of the user, along with the capabilities of the business to meet those needs.

For example, I once worked on a project where a senior stakeholder was convinced of the absolute need for workflow* to solve a particular problem. “In fact”, they said, “the whole system could be done in a workflow product”. Were they correct? I’d say that yes, you probably could have built the entire system in a workflow product, but was there any evident need to do so? No.

After a brief chat in which a product owner and the senior stakeholder had quite a heated discussion, it turned out that the only process that was needed was one to change the status of a piece of work across 3 states (submitted, in-progress and done). We didn’t buy a product and the simple process was built via a couple of web pages that the end user was happy with. Job done.

Following on from this example, there are usually hidden factors in the build vs. buy debate that aren’t usually considered. These need careful consideration.

Does the business have a development team to build something in the first place? If yes, what language would they use? The reason I ask this is that people often come and go on a project, and also you have the switch from active development to ongoing maintenance, and it’s not usually with the same people involved.

The point I’m making here is that there is a learning curve for people on the development side, just as there would be when introducing a product. How quickly does it take someone to understand what’s been built. (Usually this is quicker than understanding a product, but it should still be a consideration). The solution has a living memory, and that memory resides within the people that work to build it. When they move on, that memory moves on too.

What about something like document and records management? Could you build this? Absolutely yes, you could, but would you comply with standards such as DOD5015? (do you even need to comply?) I’d say that if you built something you could probably get there after an extensive period of development time, but you’d have quite a journey in front of you. The point here is that sometimes it doesn’t make sense to build from scratch.

So how do we handle these situations? How do we know what to do? I would advocate following some straightforward principles that can guide you. Again, if you have suggestions, please add to these in the comments:

  • 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.)

These are just some principles that you can follow on your build vs. buy journey. It’s not an exhaustive list, but the key point here is to think about the long term considerations of a decision.

Good luck on your journey.

(*) Workflow is something that frequently gets bandied about as a term. The thing is, it can mean different things to different people. I like the following definition of workflow, in the BPM (Business Process Management) sense of the word.

Workflow engines can do interesting things: wait for events, correlate events, allow you to implement multi-step processing logic with sequence counters, forking and-joining a process, mutual exclusion, timeouts and much more. They can even keep a complete history of every processing step performed.

As you can see, this is quite a comprehensive set of capabilities. Contrast this to workflow were we are basically describing a state change of a work item from a to b to c. A lot simpler, yes?

There’s a ‘workflow’ scale here, and it’s good to establish where on the scale your need lands. If it’s at the simple end, it may be better to build something rather than buy.