April 22, 2010
by Phil Downe
Software licensing negotiations are getting increasingly complicated for the buyer. Who on the buy side can be expected to understand all the combinations and permutations of many of today’s software license metrics when the concepts confuse most sales teams?
In fact, in a recent transaction with one of the 800-pound gorillas in the software industry, the sales team could not explain the licensing requirements and pricing on what should have been a fairly standard transaction covering a migration, upgrade and addition to the existing software configuration.
To even consider the sales rep’s statement—that “this is what our pricing people came up with”—would be folly. It would create a completely avoidable risk presented by an opportunistic vendor or, even worse, set up negotiations on relative pricing positions that neither party can quantify.
The situation is about to get a lot worse with virtualization. It’s not exactly a new concept. As early as the 1970s, the virtual machine (VM) platform allowed you to partition a single physical machine into multiple virtual machines, allocating one or more partitions and memory resources to an application, all under a single cover.
The term virtualization has now taken on a new life and it adds another layer of complexity to the negotiations and how technology buyers will pay for software licenses. There are now multiple flavours of virtualization: machine, application, storage and network, to name but a few.
Benefits of virtualization
Let’s take a server farm as a practical example of some of the benefits of virtualization. Roughly 90 percent of the server market is composed of x86 architecture servers. Based on a traditional model of one application per server, 80 to 90 percent of the computing capacity is unused at any one time.
With a virtualization strategy you de-couple the operating system (OS) from the hardware (machine virtualization) and the OS from the applications (application virtualization) that run on multiple physical devices. When a job needs more resources it isn’t confined to its physical cover; it instead seeks out unused capacity across the server farm and relinquishes it when it’s done. When you need to roll out a new solution you simply configure a file instead of adding another physical device.