When it comes to enterprise IT, every so often we begin to notice things that cause us to question our basic assumptions. The latest is about the role of commercial software.

The traditional advice for companies is that it is best to standardize on a commercial software vendor for the core of the applications portfolio. It might be a major vendor, such as SAP, Oracle, or Microsoft, or it might be any number of other providers. Custom software should be the exception, not the rule, whether for unique industry requirements, or for modifications and extensions to the core system. The more you can rely on a commercial software vendor, the better.

We’ve been giving this guidance for decades, whether for on-premises systems or with cloud-based systems.

We backed up our advice with several arguments. First, you are not in the software business: Focus on what you do best, and leave software development to vendors, who do this for a living. Second, you shouldn’t reinvent the wheel. You are not unique. Therefore, you can adopt commercial software that embodies best practices and lessons learned across hundreds, if not thousands, of other organizations. Don’t write custom software to automate the way you’ve done business in the past. Adopt commercial software, and adapt your processes to the best practices they embody.

Nevertheless, some of our clients are starting to rebel against the conventional wisdom by developing more of their own software in-house. Moreover, they are not doing it just on an occasional or exception basis or for niche applications. They are doing it for domains where we traditionally assumed that commercial software was the natural choice.

The History of Commercial Software

Before we get into the reasons for the rebellion, we need to have a brief recap of the history of commercial software.

In the 1960s and through the 1980s, enterprise IT was dominated by IBM. Unless you lived through this period, you don’t understand how utterly dominant IBM was in corporate IT. Its mainframes ruled the data center, with other hardware vendors, such as DEC, Burroughs, and Unisys, holding a sliver of market share. IBM bundled its operating system software with its hardware, which meant you got hardware and system software all from a single source. IBM did sell some business applications, but they felt like an afterthought—something of a value-add that would help keep you in the IBM fold. The goal was to sell more hardware.

Things began to change with the U.S. Department of Justice lawsuit in the late 1960s that forced Big Blue to unbundle software from hardware. One immediate result was the entry of competitors selling “plug-compatible” mainframes, such as Amdahl. But the effect on business software was not so immediately apparent.

In the early 1970s, when I first started my career in IT at Macy’s, nearly all business software was still homegrown. There was nearly no commercial software. Every business built its own applications, whether it be general ledger, purchasing, or payroll. In fact, I didn’t encounter my first commercial software package until I was about four years into my career and two jobs later.

The DoJ ruling set the wheels in motion for the new independent software vendor (ISV) industry. The word independent here denotes independence from hardware vendors, such as IBM. The rise of UNIX (so-called “open systems”), and especially personal computers, furthered the trend. Commercial software running on low-cost servers was hard to beat. Why develop your own custom systems when you could meet most of your needs off the shelf? ISVs proliferated like wildflowers.

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.

ISVs Have Gained Power

Today, marketplace power has shifted from hardware vendors to software providers. End-user organizations have become less dependent on hardware vendors but more dependent on software vendors. The move to cloud applications doesn’t change this a bit—in fact, one could argue that it makes the situation even worse, as now the customer just doesn’t depend on the ISV for software but for its day-to-day operation of the system as well.

Although there is plenty of competition among ISVs during the sales cycle, that competition is greatly reduced once a prospect becomes a customer. When it comes to their own installed-base customers, the vendors wield enormous power. This is generally problematic for customers in three ways:

• Packaged software has become expensive. When business software was bundled with hardware, it was offered at low or no cost. But when the ISVs took over, they had to make software their primary source of revenue. Today, under the license model, they charge up-front license fees, plus annual maintenance fees that can run up to 20% or more of the license fee per year. The move to the cloud changes the pricing model but, in some ways, it’s worse: There are ongoing subscription costs to pay year after year to the provider, in perpetuity.
• It is difficult to replace. Once installed, most categories of enterprise software are difficult to replace. Implementation is a major effort, and once installed most companies are not eager to go through the process a second time. Moreover, the software becomes an integral part of the customer’s business processes, and switching vendors means redesigning business process to fit the new system. The difficulty of replacement gives installed vendors much leverage over their customers, knowing that it will take a lot for them to walk away from the sunk costs.
• It is inflexible. Although vendors endeavor to make their systems configurable to different customer requirements, packaged software by definition is “one size fits all.” Although this may be desirable for applications that are common across industries (e.g. general ledger, payroll, expense reporting), it can be problematic for industry-specific or unique needs of the organization. This often requires customers to build side-systems or extensions to the package to make it fit their unique needs. Worse, sometimes customers change business logic directly in the vendor’s program code, if they have access to it, which complicates future version upgrades.

At least with hardware, buyers can generally swap out, for instance, Dell servers for HP without a great deal of disruption. With software, commercial packages are not plug-compatible.

The Beginnings of a Rebellion

Over the past several years, as buyers have grown frustrated with the cost and inflexibility of packaged software, they have begun to push back against the ISVs. While there have not yet been widespread defections, we do see signs of rebellion both in news reports and in our own consulting practice advising buyers.

• One client of ours at Strativa wrote a custom system for sales proposal generation. Although there are excellent CPQ (configure-price-quote) systems on the market, the client’s products are so complex that it would have taken a high-end commercial software offering and much work to tailor the package for the client’s needs. The client now maintains this custom system with a single developer, no license fee, and no ongoing maintenance fees.

• Another client, a large global retailer, is planning to abandon its commercial warehouse control system. The reason? The vendor simply cannot respond quickly enough when there are problems in the warehouse or the system needs to be reconfigured for layout changes. Developing and maintaining the system in-house will put the organization more in control of its own destiny and make it more agile.

• Another client, a broker of marketing collateral to many large tech companies, built and maintains its own custom sales order system. The firm’s requirements, which included complex incentive accrual calculations, were simply too far out of the realm of anything we’ve ever seen from ISVs. The client, and more importantly, its sales team of 70, are extremely happy with the outcome.

• Another client, a well-known technology recruiting firm, wrote its own applicant tracking system. Although there are many good ATS systems on the market, this client found that it could automate the recruiting process far more extensively than it could using any of those commercial solutions. It believed this gave them a competitive advantage, and its private equity firm (who retained us to do an assessment) agreed.

• Finally, we can point to the public case study of Dick’s Sporting Goods, which has nearly completed a program to replace all of its e-commerce and inventory management systems with software built in-house. The project was justified in terms of faster response to changes in demand, improved productivity, and customer experience.

Of course, none of this means the death of packaged software. In all of these examples, these organizations are still implementing and maintaining ISV packages for things like general ledger and payroll. But we are increasingly seeing buy-vs.-build decisions at the edge coming down in favor of build-your-own-system.

Interestingly, we also see this trend showing up in our IT spending metrics at Computer Economics, where we see an increase over the past three years in the percentage of the typical applications portfolio going for custom systems. We will continue to follow this trend to see if it continues.

Factors that Enable Custom Development

So, what’s now leading to a change in thinking? There are several long-term trends underway that are making custom development more attractive, and not just on an occasional or exception basis. These include the following:

1. Microservices architecture and Web APIs. Commercial software vendors are increasingly building their systems using architectures that allow them to be easily integrated between modules (or services) internally, and other systems. In addition to making their systems easier to maintain, they also make them more extensible. Customers can leverage them to build their own integrated extensions.
2. Low-code/no-code development tools. Custom development today often does not mean hiring or retaining full-time professional developers. Many requirements for custom software can be satisfied by users outside the development group who can write their own code. The low-code/no-code movement is in early days, but it is growing.
3. Cloud computing. The tools listed above are nearly all cloud-based. Customers themselves can leverage cloud platforms to build new systems or extend existing systems without having to deploy on-premises infrastructure.
4. Agile development. Iterative development methodologies have taken some of the risk out of custom development, in terms of having to make a large up-front commitment before business requirements are fully understood. This is especially important for systems that are intended to provide a competitive advantage.
5. Open source. In some cases, there are open source projects available that can serve as a starting point for custom development, with no software license fees or maintenance fees. Admittedly, however, this trend has not taken hold as strongly as some of us were hoping to see.
6. Tech-savvy workforce. In addition to the technical advances facilitating custom development, there are also demographic factors. Younger workers often come to the job with software development skills, even if they do not have computer science degrees. In fact, many professional developers today are self-trained. Although advanced programming skills may be in short supply, the kind of development most organizations need is much more basic and much more easily acquired.

New Guidelines on When to Build vs. Buy

If developing custom software is an increasingly viable option, what are some guidelines for making the build vs. buy decision? Here are four factors to consider.

• Competitive differentiation: When a system could provide a competitive advantage, give more consideration to building it yourself. That makes it harder for competitors to imitate.
• Industry-specificity: Many vendor solutions are good for business in general but do not offer features that are unique to certain industries. Some analysts exhort the commercial software vendors to develop deeper industry solutions. But perhaps that is too much to expect. Take control of your own destiny and write your own.
• Flexibility, agility, and responsiveness: If you expect the system to undergo frequent changes or must be quickly adaptable to changing requirements, it might be a safer bet to develop it yourself, where you are not waiting on a vendor or systems integrator to support you.
• Cost effectiveness. Sometimes it just comes down to an economic decision. If the packaged solution is costly and perhaps more feature-rich than you need, you might be able to get by more easily and cost-effectively by rolling your own.

The benefits of developing your own software can be attractive. For starters, you are now in control of your destiny. There is no worry about your ISV discontinuing development in the future, going out of business, or being acquired by a competitor that takes the system in a different direction—or lets it die on the vine. Moreover, with your own system, you no longer have to worry about version upgrades. You are always on the latest version, because you are your own vendor. You are never back-leveled. Finally, you don’t have to worry about negotiating renewals—whether maintenance contracts or subscription agreements. There is no ISV sales person constantly looking for ways to gain a bigger share of your wallet.

Buyer Beware

Does that mean there are no downsides to custom development? Of course there are. Specifically, you have to have an organizational commitment to establishing and maintaining an in-house software development group. Sure, you can use “citizen developers” for simple extensions of commercial software or for simple departmental needs. But for serious development you still need professional software developers.

There is also a risk. If you are a small firm and cannot afford more than one or two developers, you are putting yourself in a position of undue reliance on a single individual. In fact, when performing an IT due diligence assessment on an investment target, this is something we watch out for. You could contract with an outside firm for software development, but you will still need to manage the service provider and hold it accountable. And, be sure you have contractual terms and conditions regarding who owns the software and restrictions on the developer’s ability to use it with one of your competitors.

Nevertheless, if every firm is a technology firm, as many analysts like to say, then it is no surprise that many of them are writing more of their own software. It may be that one day we will view the dominance of commercial software to have peaked in the mid-2010s, just as IBM’s dominance in mainframes peaked in the mid-1980s.

In our view, many of the major software vendors are overplaying their power position vis-à-vis buyers, and buyers are revolting. In the near future, we expect to see a more balanced situation, where commercial software is still commonly used for general applications, but custom systems form a larger percentage of the applications portfolio, even in areas that are now dominated by commercial packages.

So, is it time for a software buyer’s declaration of independence? Maybe not complete independence, but it certainly looks like we are moving at least partially that direction.

---

Postscript

In this post, we do not intend to stereotype commercial software vendors. Some are, in fact, the “good guys.” It wouldn’t be fair to name names, because we certainly could not list them all. But if you know the market, you will recognize them as ones that have very low cost per user for a wide footprint of functionality, policies that encourage increased usage of the system throughout the user base without increased pricing, open APIs that encourage extensions, a sales and support function that is easy to do business with, and customer-friendly contracts that make it as easy to get out as it is to get in. And, they are not in the habit of suing their customers.

Bonus: Frank Scavo in a podcast with Diginomica on this subject, going into more detail.

---

Analysis by Strativa President, Frank Scavo.