Certification aka "Some Assembly Required"

Red Hat announced yesterday that it intends to provide a product for application vendors to use as a basis for virtual appliances. The product will be the same as the general purpose release of Red Hat Enterprise Linux in order to maintain "certification." It will, however, have a new name – Red Hat Appliance OS. According to Red Hat, the product will be a valuable alternative to rPath because it preserves application “certification.” Apparently this means that customers will still need to assemble, configure, and maintain the components inside the virtual appliance. After all, “certification” is only valuable when the components are not provided as an integrated, optimized, and tested unit.

Given that most customers only buy “certified software solutions,” is it surprising to anyone other than me that they spend 6X the cost of software licenses on assembly, test, administration, and maintenance? If certification guarantees that things work together, why do software vendors currently spend as much as 50% of their customer service time troubleshooting the relationship between their application and whatever “certified” OS the customer has decided to use to support the application? If each release of the components is "certified," why do customers drag their feet when it comes to updates and upgrades? Maybe because "certification" does not really guarantee anything other than "some assembly required."

Fortunately for all of us, “certification” will be a thing of the past when applications companies distribute their applications as virtual appliances. Just like the auto industry, the car will come ready to drive. The notion of Toyota “certifying” the body to work with the frame, or the engine to work with the transmission, is nonsense. All the components work together because that is the definition of a car. Toyota integrates and tests all of the components from all of the vendors in a manner that best meets the needs of the customer.

Given that “certifications” and all the headaches associated with “some assembly required” will soon be a thing of the past, I thought we would take a fond look back at all of the responses that customer service reps provide customers when they run into troubles assembling the “certified” components:

Top Ten Responses to Certification Problems

10 – Re-install and call me back if you are still having problems.

9 – Can you send me a test case that reproduces that problem?

8 – It works for me.

7 – Have you been to any of our training classes yet?

6 – This is obviously not an application problem. Call the OS vendor.

5 – My shift is about to end and I am going to need to transfer you to someone else

4 – Did the sales guy talk to you about our consulting services?

3 – I'm going to need to escalate this one to engineering

2 – Your support contract doesn't cover this type of issue

1 – Take a picture of your screen and email it to me because I have never seen anything like this

The Legacy Code Triple Threat

Over the past 3 weeks I have had several conversations with CTOs and CEOs of software application companies where the support of legacy systems at their customer base has occupied the top spot among the multitude of their competitive concerns. Specifically, these executives are worried about what I now describe as the legacy code triple threat:

Higher Support Costs – customers that will not migrate to new versions of an application are more expensive to support because they expect their basic maintenance contract to provide bug fixes and incremental features that do not rise to the level of new release functionality. Updating a legacy code base is much more expensive than maintaining the newer releases because the “minor updates” inevitably create regressions in areas of the code that were never intended to be maintained or updated but which now must be attended to in order to provide even the most basic of services to the customer. Providing these updates to a legacy code base also siphons off scarce engineering resources that could better serve the company by providing features in the new release that drive new license sales, which is the metric that most interests investors and provides the fuel for the business.

Lower Revenue – customers running legacy code are often unable to implement add-on modules that would provide the application vendor with new license revenue. When the IT “switching costs” of implementing a new module include development and testing costs for existing application functions to be migrated to a new code base, the customer will often say “no” to the new functionality. The possibility of “breaking” something that is “working” in order to get something “new” can be a bitter pill for many customers to swallow.

Competitive Risk – customers that face a significant cost to receive the latest and best code of their existing vendor are prime candidates for the competition to lure away to an entirely new solution. “If you are going to spend a ton of money to upgrade, you might as well consider our competing technology as part of your evaluation” is a classic pitch that works well against any vendor that lacks an elegant approach for delivering updates to their customers. SAP used this to terrific advantage against Baan in the late '90s. Customers that are a “flight” risk lead to very expensive sales and service retention costs.

All of these conversations with executive leaders at software application companies were prompted by their interest in virtual appliances as a way for them to resolve their legacy support issues. They were actually far more interested in this value proposition for virtual appliances than in the more obvious advantages associated with simplified distribution and installation. Of course, in order to realize this benefit of elegant and seamless upgrades, their approach to a virtual appliance architecture has to be much more than a simple snapshot of a running installation delivered as a virtual machine.

The virtual appliance objective for these executives is twofold:

1. Walk into the customer base and give them a working instance of the latest and greatest code running against the customer dataset as a replacement for their legacy instance. A virtual appliance where the application vendor assumes responsibility for the entire technology stack down to the hypervisor is a great way to accomplish this “forklift migration” objective.

2. Create a new relationship with the customer where the application vendor is able to easily deliver new functionality to the customer without ever again requiring a “forklift migration.”

If a virtual appliance architecture can accomplish both of these objectives, the legacy code triple threat can be eliminated. The vendor gets more revenue at a lower costs with a reduced threat of competitive replacement, and the customer gets the best technology the vendor has to offer. It's not often in the software industry that both the vendor and the customer get exactly what they want, but virtual appliances might be one of those rare magical opportunities.