Build v Buy - round 10 - a conversation with Frank Scavo

Profile picture for user gonzodaddy By Den Howlett July 8, 2019
Summary:
Should you build or buy your next back office or even front office solution? Some elements are clearly a buy, but there are emerging examples that point to build.

The build v buy debate is almost as old as packaged software. It receded into the background during the late 1990s and through to recent times as packaged solutions gained supremacy. But it is a debate that has popped again in recent times.

Late last week I held a conversation with Frank Scavo, CEO Strativa and Computer Economics to discuss the build v buy options available to enterprises today. This was triggered by a blog post that Scavo penned with the provocative title: Time for a Declaration of Independence from Software Vendors? and timed to appear around the US's Independence Day celebrations. 

Let's be clear what we're not talking about. No one in their right mind would advocate for building your own GL or payroll - it makes no sense. But there are plenty of middle ground issues where the argument for build or buy is less clear.

A slow burn

Scavo's build v buy story draws on trends that his firms are seeing both in the quantitative work that Computer Economics undertakes and activity in the consulting practice. While Scavo is keen to emphasize that the few examples he cites do not make a trend per se, he says that the numbers indicate a far greater willingness on the part of customers to seriously consider build options rather than the perceived wisdom of buying packaged, off the shelf software. 

In our conversation, we explore several aspects of these types of decision. Chief among the reasons cited:

  • Unresponsive/too slow responses from ISVs and SIs
  • Buyer fatigue arising out of perceived wallet fracking and other bad behavior among some vendors
  • Increased cost (with little perceived value), inflexible and once rolled out, hard to replace.
  • Edge case functionality that can be built cheaper and work better than modified packages. 
  • The rise of platforms upon which developers can easily build functionality and which can take advantage of REST APIs and microservices where it makes sense to do so. 

History teaches

There is a firm historical context behind the idea of building rather than buying. As Scavo points out in his original story, there was a time when buying wasn't a viable option, but the unbundling of hardware from software in the early 1970s set in motion a flowering of innovation and a lowering of cost to the buyer:

Hundreds of ISVs emerged, too numerous to mention. The ERP market alone included venerable names, such as ASK (1972), Lawson Software (1975), J.D. Edwards (1977), QAD (1979), and MAPICS (1980), building largely on mini-computers. Unnoticed for the most part in the U.S., SAP (1972) first began providing mainframe-based applications and was then first to market with client-server ERP. PeopleSoft (1987) began in the client-server era, and quickly gained ground. Oracle launched its business applications in the 1990s and grew quickly, acquiring a number of other ISVs in the process. 

What happened next leads to our current situation. Under Moore’s law, hardware costs plummeted, and software became a larger and larger percentage of IT spending. Nearly all the computer hardware manufacturers, including IBM, sought to become software (and services) providers, because that’s really where the money is.

I remember them all. As the story points out, this shifting of emphasis allowed the ISVs that thrived to become the center of gravity for technology investments, gaining significant power over customers who increasingly bought into the packaged mantra. 

Utility pricing - not yet

During our conversation, I trotted out my perennial beef that with ever-increasing costs, why don't firms switch out expensive software that should be a commodity - think debits and credits. Scavo argues that while I may be right on the commodity argument, back-office systems, in particular, are like infrastructure. They're almost invisible though essential and it is only when the pain of maintaining them becomes too great that firms consider alternatives. 

While we didn't tackle this specifically, I would argue that commodity pricing has yet to come to back office systems. As readers know, power utilities, for example, spend massive amounts on building and maintaining infrastructure the cost of which they amortize over the very long term recouping some cost from customers through modest standing charges. In the alternative, they make money by charging for metered usage.

That model is only used by AWS with Microsoft and Google following suit. None of the major application vendors have found a way to successfully do this although in fairness, SAP has made efforts to develop that model. The problem for both buyers and sellers in this model is that it is difficult to see a pathway from the entrenched practice of upfront fees coupled to high maintenance figures which generate huge margins that to date have proved more attractive than the margins gained from subscription pricing. 

In transition?

Today, we appear to be in a transitionary period. Those of us who've followed the enterprise market for many years are still waiting for the emergence of a powerhouse player who can offer the kind of utility approach that would make a genuine difference.

However - and again as Scavo points out in our conversation - some vendors are eschewing the less attractive practices in favor of models that are much more customer friendly. In this context, Jon Reed's in depth conversation with Zoho from June, 2019 is well worth the study. Couple that to open source, low-code/no code, cloud computing infrastructure and agile development techniques and you can see where the components lay for more of a build model. 

The build alternative has plenty of advantages - no maintenance costs other than that you control, getting what you need and not what an SI thinks you should have, zero vendor lock-in and so on. But then it's not all upside. A principal problem is the flipside of maintenance. Just as we've seen interest in vertical industry solutions struggle in the packaged world, business specific expertise is vital and if/when that goes away then what do you do?

On reactions to Scavo's story, the answer was entirely predictable: those analysts who favor innovation and see increased value in build options are like 'Hell yeah,' while those analysts who are invested in the packaged vendor community are 'Hell, no!' There's not a lot of gray in that community on the topic of build v buy!

My take

I'd like to think that we're in the early stages of utility nirvana but I suspect we're at least 5-10 years away.

There's simply too much money in pricing based upon bums on seats plus maintenance. The software industry has done too good a job at conditioning buyers to accept this as the baseline model for a wholesale change to occur anytime soon. 

However, if the examples that Scavo sees are indicative of a rebellion then it will be interesting to see how this fleshes out. Regardless, the build v buy argument is one to which we should all be paying closer attention. 

Endnote

For more on enterprise vendor pricing and the 'camps' that are emerging - check out Josh Greenbaum's excellent analysis that includes extensive reference to the Zoho model.