Bespoke software is expensive. As we all well know, it is risky to build, technical debt can easily creep in, and you can easily end up with a maintenance nightmare. And software developers, well – we all know they are hard to work with, they tend to have opinions about things, and did I mention, they are expensive?

The argument has always been that with purchased software, you get an economy of scale because you share the software with others. Of course, this works out well most of the time – nobody should ever be developing their own internal commodity software (think operating systems, databases, and other “utilities”).

However, not all software is “utility”. There is a continuum of types of software, going from something like Microsoft Windows or Linux on one end, which nobody in their right mind would write, and company specific applications of all kinds that have zero applicability outside of a given, well, “Enterprise”. The software I am talking about in this post lies somewhere in the middle of these extremes.

Almost anyone who does work in corporate IT has probably encountered one of these systems. The following traits commonly pop up:

It is oriented at a vertical market. The number of customers is often measured in 10s or 100s.

The cost for purchase is usually measured with at least 6 figures in USD.

It usually requires significant customization – either by code, or by a byzantine set of configuration options.

It was almost certainly sold on a golf course, or in a steak house.

You usually need their own consultants to do a decent installation. The company that sells the software has professional services revenues at or higher than the software license revenues.

It is my observation that software in this category almost always is loaded with technical debt. Technical debt that you can’t refactor. Technical debt that becomes a permanent fixture of the organization for many years to come. Enterprise Software – especially software sold as “Enterprise Software” to non-technical decision makers, is more often than not, a boat-anchor that holds organizations back, adding negative value.

Why is this? Enterprise software is often sold on the basis of flexibility. A common process, sadly, in the world of package selection, is to simply draw up a list of features, evaluate a set of vendors on the basis of desired features, and balance that against some license cost + implementation cost threshold. Lip service is given to “cost-of-ownership”, but the incentives in place reward minimizing the perceived future costs. What this process selects for is a combination of maximum flexibility, moderate license cost relative to a build (but often high), and minimized estimates of implementation cost. Even if one company bucks the trend, the competitive landscape always selects for things in this direction.

Why is that true? We don’t assess the technical debt of enterprise software. I have seen a lot of buy versus build analysis in my years as a technology consultant, and not once did I see something that assessed the internal quality of the solution. Enterprise software is bought based on external features, not internal quality. Nobody asks about cyclomatic complexity or afferent coupling on the golf course.

Does internal quality of purchased software matter? Absolutely. In spades. It is hardly uncommon for companies to start down a path of packaged software implementation, find some limitation, and then need to come to an agreement to customize the source code. Rarely does anyone have the intent to take on source when the software is purchased, but frequently, it happens anyway when the big hairy implementation runs into difficulty. But even if you never take possession of the source code, the ability for you to get any upgrades to the solution will be affected by the packaged software vendor’s ability to add features. If the internal quality is bad, it will affect the cost structure of the software going forward. APIs around software that has bad internal quality tend to leak out that bad quality, making integration difficult and spreading around the code smells that are presumably supposed to be kept “inside the black box”.

What is the end result? Package implementations that end up costing far in excess of what it would have been to build a piece of custom software in the first place. Lots of good money thrown after bad. Even when the implementation works, massive maintenance costs going forward. It gets worse though. The cost of the last implementation often colors the expectations for what the replacement should cost, which tends to bias organizations towards replacing one behemoth nasty enterprise software package with something equally as bad. It is, what the French like to call, a fine mess.

So what is the solution? We need to change how we buy enterprise software. The tools we have for buy versus build analysis are deficient – as few models include a real, robust cost-of-ownership analysis that properly includes the effects of insufficient internal quality. It is amazing that in this day and age, when lack of proper due diligence in package selection can cost an organization literally billions of dollars, that so little attention is paid to internal quality.

What would happen? There would be a renewed incentive to internal quality. Much of today’s mediocre software would suddenly look expensive – providing room for new solutions that are easier to work with, maintain, and provide more lasting business value. More money could be allocated to strategic software that uniquely helps the company, providing more space for innovation. In short, we would realize vastly more value out of our software investments than we do today.