Build vs Buy

An excellent blog post from an experienced engineering manager describes how to think about build vs buy - here is how we address his points.

3 minute read ∙ May 21st, 2020

We came across an excellent blog post from Will Larson, an experienced engineering manager, on how companies should think about a build vs buy decision. He describes the major factors: managing risk, determining value, and evaluating costs:

My rule of thumb is to first understand if there are any sufficiently high risks that you simply can't move forward. If the risks are acceptable, then perform a simple value versus cost calculation and accept the results!

Since our customers are facing this decision, we wanted to share what we have done to minimize risk and cost and maximize value when it comes to implementing OpenADR and other protocols.

Risk

There is usually a risk to working with an external vendor: if something happens to them that makes it impossible to keep using their solution, you are back to square one. Our customers do not face this risk, as they have very permissive use licenses, along with clean and editable source code, so it is as though they did build it themselves.

The blog post notes that most build vs buy decisions focus on risk, but should spend more time thinking about value.

Value

Core work is described as directed towards selling something useful to your users, all other work is auxiliary work (protocol implementation is auxiliary work: necessary, but not a competitive differentor). But auxiliary work must not be overlooked, as it is still a key part of the overall solution and can fail to support or even jeopardize core work if done poorly. Therefore, the value of auxiliary work should be evaluated carefully. As the post states:

To calculate the value of a vendor, compare the vendor's offering against what you're willing to build today. The perfected internal tool will always be better than the vendor's current offering, but you're not going to build the perfected internal tool right now, what will you actually build?

Some companies already know they need a full protocol implementation, for example if they are required to go through a certification process, which usually makes it a much more obvious choice to buy a stack rather than build. Other companies may interpret "what will you actually build" to be a minimal implementation, as cheap as possible, with just the parts you need.

With OpenADR, this typically doesn't work well. For one, OpenADR is very particular about how messages are formatted and parties interact with each other, and quick, uncertified implementations lead to a lot of debugging when trying to use the protocol in real world interactions. Perhaps even more importantly, this type of thinking is anti-pattern. The value of open protocols is to use them widely - if it were truly a one-off implementation, both parties may be better off co-developing something minimal that provides just what they need. With OpenADR, wide scale interoperability is the goal, and a robust implementation will be extensible and flexible enough to enable it.

Our customers don't spend time implementing protocols, instead they spend time building differentiated products that provide value to their customers. But we do work to make sure they get maximum value from this ancillary work, as close to the perfect internal tool as we can.

Cost

Once value has been determined, it must be compared to cost. The three main buckets of cost are: integration, financial and operating. Integration and operating costs are the cost of time for the buyers engineers to run the solution. Financial costs are what you pay for the solution.

As descrobed above, We minimize integration cost with a microservice implementation and flexible HTTP integration with the microservice, allowing most customers to implement in a "just in time" manner - integrate just the parts you need now. This also keeps operating costs down: since the integration between the microservice and our customers platforms is simple, there isn't too much to do to update it.

For financial cost, we keep our cost structure simple, so customers can easily compare the cost to buy our solution vs the time and opportunity cost of building and operating themselves.

Ultimately, we feel that when our customers look at the cost of our solution vs building a robust implementation themselves, it is an easy financial decision to buy instead of build.

Summary

Our philosophy in offering an option to buy protocol implementations rather than build is simple: our customers are in the business of providing valuable solutions to their customers, not implementing protocols. Protocol implementation is table stakes, not a competitive advantage. By taking the protocol out of their hands and making it simple to implement while being as close to the "perfect internal tool" as possible, we help them focus on what they do best.