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.
And then conversely, you have the buy camp:
The Buy Camp
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:
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.
Sign up to the Kainos newsletter