I'm an engineer. It's in my blood. As an engineer, I want to build things. So anytime the build vs buy discussion arises, I have to fight the urge to say build and get right to it. I am definitely happier building my own stuff than configuring and deploying that built by somebody else. But I'm also a pragmatic engineer that accepts that I should leverage existing products wherever possible. But why should we ever build in problem areas where products exist?
A build vs buy decision is primarily about determining if a vendor product can be sufficiently customized to solve the problem that your organization faces. Products are designed to solve a wide range of problems. They have to be or the product vendor limits their potential customer base. The need to solve a broad set of problems does limit the optimizations a vendor can make. This follows the adage that anything that does several things, does none of them well.
How is it that custom built solutions can be better than commercial products though? You will have less engineering resources and less testing than a commercial product. Shouldn't it be obvious that commercial solutions will have an edge in capabilities and quality? Commercial products lack one crucial element though. A specific problem.
Knowing your problem domain allows you to careful choose your compromises. Every problem has unique constraints that can be leveraged to reduce complexity or improve performance. This is a reality that is inescapable and becomes the crux of the build vs buy decision process. For what you are balancing is the optimizations you can achieve against the resources the vendor can offer in terms of support and on going R&D.
The largest challenge that I've seen is adequately defining the requirements for your current problem and being realistic about your future needs. Comparing feature sets from a vendor with your internally developed solutions is a pointless exercise. The goal is to find a good fit, not to have the broadest set of features. The requirements can be difficult to clearly derive though. There are often second order requirements that are less than obvious but in fact lead to the largest opportunities.
As an example, when looking at messaging systems, we knew we needed reliable delivery. The major revelation however was that we did not need exactly once delivery or ordered delivery. The majority of the information we were propagating possessed inherent keys for managing idempotent delivery and there was no inter-event dependencies. There is a great deal of complexity that can be eliminated and tremendous performance gains that can be achieved when you eliminate ordered, exactly once delivery from the messaging infrastructure. Of course, this is not a good idea in general, but this example illustrates how a careful analysis and understand of the problem can lead to more clarity on the requirements.
Okay, so I'm obviously advocating build over buy. No, not really. There are several factors to consider before building a custom solution that has clear overlap with a vendor product. Some of the key factors are:
- Business Impact - How much does the problem you are trying to solve impact your bottom line? The less impact, the less critical a highly optimized solution becomes. I know this is obvious, but it is worth stating. Optimizing marginal problems is largely pointless.
- Incremental Benefits - How big are the gains you are likely to achieve by building your own solution vs using a commercial product. In the example above, we discovered we could reduce the number of SQL statements per message by 9X which made it very compelling. Had the improvements been 30% or less, we probably would not have embarked on building a solution.
- Holistic Costs - It's very easy to focus on the cost associated with the primary solution and ignore the overall life cycle costs. Not only does the NRE for the component need to be considered, but also all ongoing support costs as well as the second order infrastructure components that are required to support the solution.
If you consider these (and others which I would appreciate hearing about) and still find that the benefits out weigh the costs for a high impact problem, then build makes sense. One thing that I find organizations also fall victim to, is assuming that product companies have smarter engineers. Ultimately, you should understand your problem better than anybody else. Therefore, you should be able to deliver the best solution to your problems. There are lots of reasons to rely upon vendors to deliver your solution, but presumed superior engineering talent should not be one of them.
As always, I welcome your feedback.