How Did Software Maintenance Become Such A Bad Deal? Oracle and the Fall of the Traditional Model

As part of the Escape Hatch from Oracle Research Mission, we must examine basic assumptions, the central dogmas that define the market and govern most behavior.  Here are some basic questions about software maintenance that are crucial to understanding the rationale for sending vendors so much money every year.

• What was the promise of software maintenance when the enterprise software industry was fresh and new? 
• What has software maintenance become in the modern world? 
• What are you really paying for? 
• Is the traditional model of software maintenance universally a bad deal?

In this article we step way back and look at the fundamental questions that people should be asking before they continue to commit a large stream of cash to a vendor for support.

The Original Premise for Software Maintenance: Supporting Progress

When enterprise software first emerged, during the 1980s and 1990s, the products were moving forward rapidly. Every six months there were new features based on innovation from R&D that was funded in part by software maintenance. It funded bug fixing but also development of new features and improvements. And, when you had something big go wrong, you could call and get help. This launched the “break/fix” model of support that persists to this day.

This didn’t mean that maintenance was free: large leaps forward with major upgrades were and continue to be expensive and disruptive. But the original premise for software maintenance looked like this:

• Maintenance funded bug fixes
• Maintenance funded improvements to the current versions
• Maintenance funded break/fix support when the software had a problem.

The Mature (Or Lock-in) Premise for Software Maintenance: Continuing Support

But things changed as the lifespan of software extended. First of all, most of the bugs for software that are actively used are found in a year or two. Problems still occur after that because data and customizations change, but these are not included in most support contracts, including Oracle’s. The result is that companies have to spend additional funds and resources to support these configuration and customization issues, which typically account for the vast majority of all support issues and are not covered as part of the standard contracts. Also, over time, Oracle and other vendors made the support policies and practices more favorable to them. For instance, Oracle decides if a problem is a priority and gets expedited, not the customers. We will cover more of this in the next section.

Additionally, as the industry matured, problems arose. First, vendors spent less maintenance revenue on adding features to current versions for free. New functions did come out, but were more often add-ons that required upgrades. So what did the support payment become in the world of mature software? 

It continued to cover bug fixes, but the amount of time the bug fixes were relevant was reduced. It also funded new features, but again, a smaller number of these features emerged as time went on. Finally, it funded break/fix support when the software had a problem via the idea of having “one throat to choke.”

In essence, software maintenance became a form of insurance. If something new happened and really did go wrong, you did have a throat to choke. (This is the break/fix value proposition.) But widely used software becomes stable pretty quickly.

Now do you think that vendors responded to this evolution by reducing the payments for software maintenance that companies paid? To my knowledge, no vendor has ever engaged in that type of more reasonable payment structure. And of course, why would they? That wouldn’t be in their interest. The costly maintenance companies pay the vendor funds R&D that helps to launch new platforms and releases which companies then have to pay for all over again after spending millions on the existing systems. It’s a win-win situation for vendors.

Instead, there was a realization that the continued payment of software maintenance reflected the insurance factor of one throat to choke and the large cost of switching. In other words, companies were uncomfortable not having support and they were also uncomfortable paying to switch. So software maintenance payments became insurance against relatively low risk events, but companies kept paying because the cost of switching was so high.

The Concept Of Forced Upgrades Is Born

After a certain point, software vendors recognized the high costs of continuing to support every older release of software, and so instead, they decided to decrease the amount of support offered for those releases, while still charging the same maintenance and support fees, up and until a time they decide to stop supporting them altogether. In this scenario, in order to avoid paying for the increased maintenance fee, companies would upgrade, just to keep support for their software. This had a very low value proposition because of the work involved with upgrading. To pay for this just for continued support, but not needing the new features, is an unwise use of money.

What Services Come With Support-Style Maintenance Today?

Ultimately, the problems with support style maintenance is that it is vendor-centric vs. customer-centric in nature. If you call Oracle or other vendors, they will assist you, but it will be a long, cumbersome process with mixed results. A lot of burden is placed on the customer to figure out what is going wrong, or justify the level of support needed. And, as mentioned earlier, if the issue relates to customizations you have made, the vendor may push back on providing a fix to the problem. So, you often need to show how the software is broken, not just demonstrate that you are having a problem.

Oracle also gave itself more latitude by deciding on its own, rather than based on its customers’ desires, what level of priority a given support issue requires. What may be a priority one issue in the customers’ eyes is not necessarily a priority one issue in Oracle’s eyes, and additional justification and escalation may be required. 

Ultimately, there’s a limit to how much a vendor like Oracle can even help. The reality is that the vast majority of security breaches are outside the scope of most Oracle software. Vendor security patches also don’t address all known and unknown vulnerabilities. They are also not always timely and are often burdensome to apply.

A comprehensive, holistic “layered” security strategy (also known as “defense-in-depth”) is required to protect known and unknown vulnerabilities from a constantly-evolving threat landscape. Today, there are innovative, alternative security strategies, models and tools that can offer faster and more effective protection against vulnerabilities than the traditional vendor maintenance models.

One counter argument is that vendors do continue to supply security fixes. But the security of software as it ages is less about fixes or patching of the software after the fact, and more about proactively securing the surrounding ecosystem in which that software lives. Critical Patch Updates, for example, are often not applied or applied late by many customers, and are released only after an issue is discovered. 

The bigger problem here is that for a mature solution, most of the relevant security is concerned with granting access only to known users. Application security problems may exist but are often not addressed because they require major changes. Additionally, cloud vendors have introduced a shared security model that is an acknowledgement that security is a shared responsibility. Therefore, the amount of help a company gets is limited as the idea that security is ensured by continued support is generally not true when all that is provided is a stream of security fixes.

What should companies want from support? They should want support that addresses the things that uniquely matter to their environment — like customizations and changes — and not be forced to prematurely upgrade or have to apply scheduled updates for certain components at higher costs just to keep support. They should also be in control of prioritizing an issue, not the vendor, if they are paying for “full support”. 

Breaking Free Of Lock-in is the Problem

That ultimately leads to the question of why companies continue to pay for software maintenance. Does any business really sign up to buy expensive insurance as part of purchasing software? No, not really.

There are two reasons companies get into this situation. 

The first is that they have the assurance of knowing that the solution works. There is no denying that Oracle and other legacy vendors have great products and deliver on their promises. Even though it is widely known that Oracle is an aggressive company that will press its advantage in every way, companies all over the world decide that the quality of the products make dealing with Oracle worth the trouble. Oracle is also great at creating and nurturing ecosystems of third-party companies to provide lots of help in making its products work. As we say over and over in this research mission, Oracle’s products are awesome in many ways.

The companies that are the happiest with Oracle know now to negotiate a deal and control usage so they are always in the blue zone of the Four Zones of Freedom from Oracle. It is not rocket science to stay in the blue zone, and our research mission is dedicated to showing how to stay there.

But the other major reason companies continue to pay for this maintenance and stay in these relationships with legacy vendors is lock-in and the cost of moving away from these vendors. This is the larger driver that keeps companies paying large amounts for support. 

Additionally, inertia places a critical role in companies staying with what they know. Oracle, despite its flaws, is a known entity, and often companies just continue on with what they’ve always been doing rather than taking risks with newer products. Additionally, it some cases, it can be very expensive, especially when dealing with older systems, to move from older to newer versions. Lock-in then helps to cement this profitable revenue stream for vendors like Oracle which is upwards of 90+% margins with the current maintenance model.

Alternatives to Support Style Maintenance

So what options do companies have? 

The easiest way to avoid paying support is to reduce lock-in by creating a path to credible alternatives. If companies increase their competence in migrations, this can greatly help. Additionally, improving the company’s ability to negotiate with Oracle helps to place it in a position of power when it comes to deciding whether to pay these ongoing fees. Opening up the possibility of being able to switch to a cloud platform or another vendor offers not just more choices for companies, but also the ability to gain leverage in negotiations and ultimately save a great deal of money.

Companies should also explore third party maintenance in which a third party, rather than the original vendor, provides that maintenance. This allows companies to take advantage of the power of a perpetual license (which we will cover further in later stories). It also helps to reduce maintenance costs by at least 50% in most cases as third party providers are generally cheaper, while also bolstering the quality and level of support received. Third party providers frequently support not only the software but also the use of the software. 

Answers to the Fundamental questions

So to answer the questions we started with:

• What was the promise of software maintenance when the enterprise software industry was fresh and new? 
  • In short, it was that companies would be able to get bug fixes, meaningful improvements, and break/fix support in case anything big went wrong.
• What has software maintenance become in the modern world?
  • It has essentially become a large payment to insure break/fix support if a major problem occurs. 
• What are you really paying for? 
  • As alluded to in the previous question, companies are really just paying for insurance. The reason the insurance can be so costly is lock-in and the huge amounts required to switch vendors or platforms. 
• Has the traditional model of software maintenance universally become a bad deal? 
  • Yes: Companies have quality software in place today, but they’re getting little return on their investment in the support they have for that software. Companies who are paying top dollar for meager support should be looking to move to an alternative support model that provides better service and value with a more reasonable price.

It is perfectly possible to navigate the world of enterprise software. But if companies do not plan ahead in a thoughtful fashion, they can quickly find themselves in a bad situation in which they’re paying a lot but receiving little in return. Enterprise software maintenance has not always been a bad deal for companies but it has become one in a growing number of cases as lock-in has increased, products have matured, and innovation has slowed.

The Escape Hatch From Oracle Research Mission is Sponsored by:

Oracle is a registered trademark of Oracle and/or its affiliates. Early Adopter Research is an independent firm and not associated with Oracle. © 2019 Early Adopter.

Oracle escape hatch rimini street

Author: Dan Woods

My mission: Find technology for Early Adopters. Follow me on Twitter @danwoodsearly and on LinkedIn www.linkedin.com/in/danwoodsearly/. I am a CTO, writer, and consultant. For tech vendors, I help explain their technology. For users, I help find, select, and deploy new solutions that have explosive business value. I love to speak and share ideas.