We're at a time of rebellion against maintenance fees, which now include the elements of insurance, extortion, declining systems, and of course refactoring all of which add to the costs of any implementation. Add that into the actual implementation itself, and one is left with whopping fees and eventually ineffective systems. The only value is to the vendor in other words, which gets to pad gross margins at the high cost to the consumer.
Customers are mad as hell and they're not going to take it any more.
One would think that as the network became the computer, some of the thinking around maintenance would change. And in fact, there are initiatives at work that help reduce that burden, namely standards, a vital competitive environment, and new programming methods that help the vendors reduce costs. But the vendors, don't, or can't or won't.
It's worthy of new academic studies, most of which CloudBlog would love to be involved with. But we also want it to be clear that the complexity issues in software evolution don't necessarily rule out "cloud." Don't get me wrong, they are almost exclusively a part of the on premise business model, which has been successful (for some vendors) for more than four decades. Some neophytes, unfortunately, count anything hosted as being part of the cloud. We don't buy it. Virtualization is not cloud. Private cloud is not cloud. Putting some code on hostmonster is not cloud. That said, true cloud faces many of the same issues around development and complexity, it is how it is handled and how expectations are set with the consumer that makes one difference. The bigger difference is that cloud vendors can continue to offer more seamless upgrades, more competitive differentiation, and add more insurance in a way that is more easily understood.
But we wanted to test the theory with someone who talks to VPs of procurement and IT every day. We cornered Duncan Jones, a principle analyst at Forrester, who covers sourcing and pricing. Jones talks almost exclusively to non-vendor clients, and he feels their pain.
He didn't actually call the on premise vendor tactics "extortion." Alas, that term is too harsh. Instead he called it "organized robbery."
In this short and somewhat shaky and grainy video shot live in Boston, Jones documents some of the practices. Everyone in procurement should read it. Forrester clients might want to give him a call. He especially articulates certain issues that come into play with maintenance and you'll see why it is actually organized robbery:
- Vendors conduct audits as they should. Vendors have the right to bill customers for software usage.
- Vendors are nuancing the messaging around software usage to a degree that traps users into paying more.
- Vendors, which once charged on a usage basis, moved to a processor-based fee, and are now coupling the two, raising prices as they do it.
- Vendors are not communicating to the customers how virtualization and private clouds are impacting their prices.
- Vendors are forcing customers to break their compliance rules by not giving them the tools to do their own audits.
As Jones points out, this situation is getting worse and it's a "shame."
CloudBlog has its own opinions. Distrust of vendors' maintenance schemes seems to be at an all time high. Maintenance or the distrust of it is simultaneously academic and emotional and also pragmatic as Jones covered in the video.
The emotional issue is this. At some point in the evolution of software, maintenance became the bane of the consumers, who were more or less forced to buy the maintenance programs in order to have the most current releases of the code they were running. Pragmatically it made sense: software is rarely a fixed asset and for companies to have the most recent patches, updates, and point releases of a particular version, the consumers bought into the plan.
But something happened. Vendors at first fueled new development based on the maintenance revenues from their existing customers. Perhaps they still do this to a degree. But then these vendors wrapped maintenance into insurance, which was then equated with extortion. In order to get the updates, the vendors rolled support policies into the maintenance programs. Consumers begrudgingly accepted the new extortion as the safe choice, akin to street corner store protection from unruly forces at play. It was still OK just 10 or 15 years ago, when the maintenance costs were about 9 or 10 percent. Now as they hit 18 to 22 percent of the costs of the licenses which were rising faster than any inflationary index, the consumers rebelled, albeit somewhat quietly and without representation of the broader community. One reason for this was that there were fewer software choices that were deemed safe, giving the vendors the strings to jerk the marionettes around.
The academic issues have been well argued over the last 30 years. Maintenance has been well documented as part of the evolution of software. UCLA Professor E.B. Swanson in 1980 published a paper that outlined four kinds of maintenance:
- Corrective: bug fixes
- Adaptive: keeping the code usable as competitive dynamics changed
- Perfective: performance improvements
- Preventive: correcting faults before they manifested as real problems
A professor in the UK, Dr. Meir Lehman went further in a discussion about the evolution of software, arguing that as software becomes more complex, it eventually declines in usefulness.
And in 1990, Fred Brooks, a software engineer responsible for managing the development of the IBM System/360 (one of the first monolithic systems that included maintenance as part of the implementation), stated that a whopping 90 percent of a typical system cost arises during the maintenance phase.
As software grows in complexity and decreases in value as it does so, vendors have two options if they are going to be successful: charge more for maintenance so that they can deliver new software or force an upgrade onto the customer. Customers have two choices - capitulate or fight back. Fighting back in this case may include considering new architectures and shifting their business philosophy.