Build or Buy ?

"Build vs. buy" is one of the classic technology decisions any  architect or engineer has to make at one point or the other.

In this post, I will discuss some of the blind spots that even experienced decision-makers miss.

Quick results vs. Local Maxima

Decision makers' failing to see the local Maxima is one of the common traps; this is true for a Build vs. Buy or a COTS vs. COTS assessment.

You have local Maxima when whatever you optimize for has a near peak, but way below what is possible with a good solution.  A real-world example often goes like this,  the vendor promised magical results, and your team believes it meets most of your use cases out of the box. You do not realize that it is nearly impossible for this solution to fully meet the needs of the future Enterprise and realize its full potential. There will be a lot of duct-taping between the local maxima and the full potential.

Not all local maxima's are feature constrained; they can be non-functional requirements such as scale or performance. Local maxima can also be technical or platform-related, preventing the solution from scaling to meet the needs.

It is impossible to predict the future, and like everything else in real life, local Maxima's are often caught in hindsight. To improve the decision quality, an organization needs to have an opinion of the future, Technical, and Business, and see the COTS decisions from three, five. Ten-year horizon to see if it fits your overall strategy. Architects should seek out questions that reveal the constraints of the products around the corners than getting Euphoric about adoption.

No Code

I love great no-code solutions, and in fact, the web editor I am typing this on is an excellent no-code solution for authoring and publishing webpages. It works so well that I never think of it as no-code software.  A tell-tale sign of an ideal no-code solution is that you do not have to reason with the system but only think about your work, for example, writing in this instance.

When COBOL debuted in 1959, everyone claimed it marked the end of programmers - because COBOL is English-like, and now everyone can "program" in English. It is clear now that it was a fallacy, and all it did was create a new class of developers called COBOL Developers. This abstraction continues to today, where you have PEGA developers and Salesforce developers, and so on.

There's an essential distinction between the online editor and Pega.  One gets out of the way, and one is another abstraction layer on programming.  The problem is not solved but moved up. You use pictograms instead of words. Pictograms are ideal in many places; for example, all the road signs are pictograms - they convey a lot of information with a simple representation, which is excellent and very helpful until it's not.  While you might not want to read a passage to find out where your bathroom is, you certainly need more than a bathroom sign to explain how your medical claim is adjudicated.

Low code/no-code tools are essential in your tool kit, but understanding what you are buying and how that integrates into your Enterprise will limit/reduce your disappointment.

COTS  Tax

It's essential to understand the Tax that often comes with COTS platforms.

• The COTS platform requires "COTS developers" - often people with less transferable skills to other teams.
• Be ready to spend time dealing with edge cases that conflict with core design tenets of the platform.
• Limited automation, CICD Integration, and Team culture - often requires entirely separate workflows from your core development teams.
• Depending on customization - your upgrades can be painful. A vendor will undoubtedly tell you how customizable their platform is but not what it takes to keep those customizations.

Summary

Buying COTS Software or using a SaaS service is often the best way to build a solution to business problems. However, keeping an open mind to the pitfalls of COTS solutions will help IT leaders make better quality decisions.