Virtualised licensing presents a major stumbling block to the widespread adoption of virtualisation. The industry has been slow to address the problem, when it should be ahead of it.
As vendors change their software pricing and associated licence provisions to accommodate virtual use, the people who negotiate software contracts in organisations must plan to spend an increased amount of time per contract to understand the effect of such changes on planned software use. Organisations that do not diligently monitor the ways in which each of their vendors are responding to virtual-use issues are likely to experience significantly increased cost and unintended impairment of their current licence rights.
Discussion about virtualised-licence pricing models strikes fear into customers and vendors. This is because neither party feels that it has enough information to venture into a model that breaks with former licensing tradition and potentially introduces many unknown components. The reality is that customers inherently view virtualised licences as a way to rearrange processing and reduce software costs, while vendors see the increased functionality as a way to position new value and justify a higher price.
Many on both sides of the equation seem to be awaiting a new standard that will ‘magically’ equalise the price/value relationship. The bad news is that such a standard is not likely to materialise soon, and the confusion both sides feel about rationalising price-to-value is likely to become even more complex and chaotic.
A simple analogy demonstrates why the confusion is likely to continue. Suppose you go to the hardware store to buy a hammer you will use to build a $200,000 house. There are several different choices, and each hammer touts different capabilities. You make your choice about the hammer that suits your needs, pay the stated price and leave the store. No one asks you to pay more for the hammer when you decide to build a $900,000 house with it.
By contrast, with software licensing, the vendor attempts to equate price to value derived. If you derive greater value, you pay more, even though you may not use any different features or processes from the person down the street who derives less value. This reality ensures that, as the ways people use software become more diverse, the perceived need to have a greater number of more complex pricing models will expand.
Measured response
Perhaps the most significant impediment to virtual licensing is the lack of tools required to monitor use and service levels. If perceived value (and, therefore, price) is rationalised by a more granular analysis of utilised capacity and service, then customers must have automated tools that support utilisation measurement and self-compliance. Although IBM-developed utilisation devices are already in use on the mainframe as a prerequisite for certain IBM infrastructure licensing models, the independent software vendor (ISV) solution is not as clear. Many competitive, political and security issues wait to be addressed.
The amount and type of information collected by such devices is so powerful that it begs many questions: because IBM already has some such tools, is it easiest for everyone to work from that beginning point? What if every vendor developed its own tools? What if the vendor providing the tools also offered products that compete with another vendor’s tools for which utilisation data is collected? Even if these questions can be resolved between vendors, who will ultimately pay for the continued maintenance and development required?
Until the many opinions gel into a workable standard from which real progress can be made, the marketplace will be fraught with a variety of tools, each of which must be understood and weighed against the others to evaluate actual cost per unit for procurement and asset management purposes.
Vendors unimpaired by legacy systems have the ability to create and advance the purest new virtual licence models. Even if you do not negotiate with one of these vendors, it may be useful to explore their licensing models by virtual system to better understand the approaches employed. Many vendors with legacy software models have evaluated migration to a virtual licence model, and remain adamant that they will not make changes until the market matures further. Much of their reticence can be attributed to a lack of understanding as to how customers use their products to ascertain whether a particular model change could result in a dramatically diminished revenue stream.
Other vendors have taken diverse approaches to better understand how a virtual licence model could affect their revenue. Vendors that are experimenting with different ideas have routinely chosen to carve out some small subset of their customer base to use as a test bed for analysis. Results from these customer subsets will be used to determine the viability of particular features of a new model in the future.
It is important to remember that a vendor of hardware and software is better able to bundle a group of offerings and absorb a loss in one category with a profit margin in another. Thus, it may not be possible to compare pricing of similar products between software providers.
Cost increase
Vendors with legacy systems will struggle to make an equitable cost/value transition because traditional licence models have allowed them to charge based on the size of the processor being used, not on the portion of the processor being utilised. Historically, if you moved a product onto a larger processor, the cost of processing would increase commensurate with the size of the new processor, independent of whether there was any more throughput. In this way, vendor revenue streams increased as customers’ computing resources grew.
A virtualised licence, though, should more closely correlate cost to value. Thus, if only one-third of the processor is used for Product A, the price should go down. However, the vendor is not prepared to migrate to a pricing model that will cause total revenue to decrease. Therefore, if and when a model change is effected, the immediate result will be a cost-per-unit increase.
No vendor is looking at virtualised licensing as a means to reduce its revenue stream. Therefore, be wary that incremental cost is likely to be buried in any move toward virtualisation. Vendors are likely to try to disguise these costs by repackaging their offerings so that it is more difficult to make a direct comparison between old and new pricing models. Also expect to see new and newly worded contract provisions. Many current contracts allow customers greater latitude than would be intended in a virtualised environment. Vendors understand that, without automated self-compliance tools, many customers will have great difficulty staying within the boundaries of their software contracts.
Unfortunately, many vendors appear to see this as an opportunity to increase revenue through more frequent and rigorous audits. They are likely to try to put more responsibility on the customer to track, monitor and prove metrics on virtualised systems. Be careful about turning over internal documents and other detailed information to service representatives and other vendor account personnel, as that information may be used to help you today and hurt you tomorrow.
First of all, you should allow appropriate amounts of time to accurately evaluate all the licensing options, as well as the time to replace incumbent software with a competitive offering. Provide proof of your software use as a key negotiation tactic for a virtualised environment. Analyse every deal to demonstrate the financial effect of the current contract term, and what will happen when it’s time to renew. Ask your contract negotiators to provide price caps for contract renewals, to avoid future unexpected charges.
Frank DeSalvo is a research director at global research and advisory firm Gartner
Further reading
The rise of virtual sprawl – The challenges of systems management are about to grow with the proliferation of virtual machine
Virtual reality – Users report real benefits from virtualisation, but this has lead to high expectations.
