To Build or to Buy; Could Devs be the Answer?

To Build or to Buy; Could Devs be the Answer?

Of the many responsibilities Tech Leaders and IT Architects have, one that will continue to take up space on their plate is the question of whether to build or to buy?

With so many off the shelf options out there, all offering a similar service, and all with marketing budgets to ensure they appear in front of you… the attractive value of building can become muddied when a more transactional approach is available.

Gregor Hohpe advises to “build the software that differentiates your business and buy all else” AWS Architecture Blog

In a blog for LinkedIn, Blair McCracken from CVS/Caremark put forward that the question of whether to build or buy is actually a ‘red herring’.

And instead to “start by approaching how valuable it will be to leverage the strength of enterprise solutions with the nimble innovation of custom software developers.”

So let’s start!

The build process is two fold.

Build a team and the product.

Of course, when building your own software solution, you are afforded complete control of the product and don't have to rely on external sources to incorporate new features. But, it does mean the products’ success could be restricted by the availability and fluctuating levels of software engineering expertise in the team.

How often is time made to allow IT Architects a discovery phase - to gauge the overall capability of the team? To reveal the exact skills (and skills gaps) of individual software engineers and how their individual skills add up to a team.

In this scenario, hiring capacity must also be taken into consideration. 

And in this current market of scarce developers with high levels of competition leading to higher than ideal levels of attrition; recruitment responsibilities being outsourced by proxy when buying software, is attractive. 

Buying provides a foundation.

And all architecture needs a good foundation.

But, who is making the final decision on the purchase? And, who has been consulted beforehand? 

Technical vs Non-Technical

“The 2022 State of the CIO” survey observes that tech spending is on average split evenly between IT and non-IT departments. Gartner, the technological research and consulting firm revealed in their research that “67% of people involved in technology-buying decisions are not in IT”.

Dependending on the type of service you offer and industry you compete in, either the product or the customer experience is going to be the most important thing to either outsource or have complete control over. 

Gregor Hohpe advises to “build the software that differentiates your business and buy all else” AWS Architecture Blog

CIOs, CTOs and IT Architects must establish where in the architecture vision having complete control would be most valuable?

Perhaps this need is acutely represented by the Gartner research reported by CIO, which found that 56% of organisations have a high degree of “purchase regret” when it comes to their largest tech-related purchase in the prior two years. 

Though, “Organisations report regret only 38% of the time when the CIO is the final decision-maker compared to the overall rate of 56%.”

It’s clear that if opting to buy, who gets involved in the decision making process and who the final decision maker is has a real impact. 

So, what about incorporating software developers into the build or buy process? Or as Blair Mccracken put it - make use of their “nimble innovation”. 

When buying, to avoid costly purchase regret and unsatisfied software engineering teams, is it time IT Architects and C level IT decision makers adopted a team first approach?

Incorporate their software engineers into the buying process from the start, by discovering whether or not they have the skills to build what is needed. Or, at the very least, gain their perspective on off-the-shelf products that they’ll be adding bespoke features to.

When embarking on a build, it appears there is untapped value in adopting a team first approach. What are the capabilities in the development team? What is it that your developers actually want to work on? What is it that they could realistically work on? 

In a blog posted to Medium, David Asch states, “when facing a build or buy decision for software, it’s best to strategically use developers for technical evaluation but not let them be the final arbiters.” 

Regardless of the final build vs buy decision, the developers are going to be involved. Whether that’s realising the architects vision via a build or by adding innovative solutions to a bought product.

For CTOs, CIOs and IT Architects discovering how and when best to leverage the strengths in their development team is paramount.