Eric Rudder is sitting in a briefing room in London talking to a group of business journalists, when he is asked a question about software licensing. He buries his head in his hands: "My head hurts…my head hurts a lot when I think about that problem," he moans theatrically.
But the questions do not stop, and a little later, he begs, "We should move off this topic now. You're making my head hurt. It is a very complex issue, I don't have the answers."
But if anybody in the world does have the answers, then surely it should be Rudder. He is senior vice president of the Server and Tools Division of Microsoft, the world's largest software company, and his fast growing division brings in $10 billion a year in sales. As Rudder admits, the issue of how software is licensed and paid for will determine the shape, flow and possibly the future growth of that $10 billion.
But when it comes to planning alternative scenarios for software licensing, he admits, "these numbers are dangerous to type into a spreadsheet."
Rudder's frank admission sums up the extent of the problem that the software industry now faces. Whichever way it turns, huge, disruptive forces, mostly driven by technology, are forcing a rethink in the way software suppliers do business – and the way users want to pay for their products.
The problem runs like a fault line between the old and new worlds of information processing. On the old side of the line, hardware and software is purchased, and budgeted for, in large, predictable chunks. For software licensing, the most common way today is for the customer to pay a fixed fee according to the processing power of the machine or machines being used. A widely used alternative approach is for the licencee to pay a fixed fee according to number of users (or seats) accessing the software.
Both approaches are relatively stable. The customer can budget using a formula, and the software supplier receives a big chunk of licence revenue upfront, with a steady flow of maintenance revenue (usually 15% to 20%) each year after that. It is a steady, profitable model that customers and investors understand.
But on the other side of the fault line lies the world of on-demand, agile computing, where processing power is purchased and paid for according to demand. Here, the emergence of the service-oriented architecture (SOA), and the development of virtualised computing, have introduced the notion of almost complete flexibility in which systems or services are used. Increasingly, users of the system themselves can decide how much power to use or how many users have access to the software. Often, these numbers will change by the minute.
That creates all kinds of problems. If something is not used, for example, then, increasingly, customers do not expect to be charged for it. But if something is used, how is it measured? And what if resources are allocated on a provisional basis, but not used?
If, for example, an application is running on a very powerful, multiprocessor machine, but is only used for a few hours a year, what should the user pay? And what if the application is never used, but is held there as a standby in case of emergencies?
Confusion and disputes
Trying to answer questions such as these is what gives people like Rudder of Microsoft a headache. It can make it all but impossible to assess what is a fair price for a fair service.
"Software pricing is one of the most opaque things you can image. You have to have an audit [to be really accurate and fair]. It's a full employment charter for the lawyer industry," says Jonathan Schwarz, the chief operating officer of Sun Microsystems, which has pioneered (and been criticised for) some simple new models for charging for software. But the difficulties are not confined to the supplier side.
Many customers, seeing confusion and self-interest among their suppliers, are becoming restive. "There is a lot of confusion," says Rob Jones, infrastructure manager for Northern Europe for Alstom, the engineering company, which is using virtualisation software and rapid provisioning extensively across its European data centres.
Repeatedly, Jones says, the answers he gets back from suppliers such as Siebel, Oracle and IBM on what he should be paying are often "inconclusive" or "confused"; and frequently, he complains, suppliers simply take the line that will most comfortably protect their short term revenue.
Another big IT user, Experian, the data services company, is also beginning to use virtualisation. "At the moment, there is no consistency to how software vendors have responded to virtualisation," says Keith Kalinik, director of technology services delivery at the credit checking and business information services giant. "Some are licensing on a per-processor basis, others on a per-user basis. For us, apart from internal systems, virtually none are on a per-user [or a pay-per-use] basis."
Suppliers increasingly recognise they need to respond. "This is unique. The customers are actually driving this transformation," says Jason Weisser, president of Enterprise Integration for the IBM Software Group, which offers some pay-per-use billing methods.
And IT industry analysts observe the problem looming too. "Companies continue to be unhappy with the complexity and obscurity of their vendors' licensing structures," say Jim Shepherd and Karen Carter in a report by AMR Research. "We are far more likely to hear complaints about how the software is licensed than we are about the actual price of the software." They add, however, that frequently customers themselves do not know what they want.
One thing is clear: provided it is not too volatile, and it is controllable, customers want to pay-by-use. They are gradually introducing flexible technologies such as ‘software as a service' and virtualisation (see box), and see huge benefits in being able to flex their purchase of technology according to demand. The point is made clearly by Kalinik at Experian. "The more we can make our costs variable, and linked to the volume of the business, the better we can manage our P&L," he says.
But although software suppliers frequently talk about pay-as-you-go or pay-by-use charging as if it is already widely used (IBM's ‘On Demand' computing is a good example), in practice it is still very rare.
The best examples in practice today can be seen at the mainframe end of the market. This is partly because they use relatively simple techniques, partly because the very high up-front capital costs of the whole machines make it more attractive to both supplier and customer, and partly because high-end system sales often involve a big service element.
The two main system suppliers, IBM and Unisys are both able to ‘flex' the power supplied and meter accordingly by over-provisioning the machines supplied. When, at peak times, demand is high, unused processors are switched on dynamically and the usage measured. "We can measure usage in seconds, then bill by the month," says Colin Gash, senior product manager for Unisys' Clearpath mainframes. It is even possible for IT directors to apply ‘governors' to prevent over-spending of their budget.
This method has been enormously successful, especially for Unisys, where nearly half of its high-end systems business in Europe is now based on pay-per-use.
Large systems suppliers such as IBM and Unisys have also pioneered using another flexible method of paying – by an agreed business metric. Jeff McGinnis, VP of IT at Farmington Savings Bank in Connecticut, for example, is delighted with the way that his company now pays for its computing infrastructure: he pays more if the business is doing well, and less if it is not.
Farmington is a pioneer of a pay-for-service model also offered by his main IT supplier, Unisys. "We only pay for that infrastructure as we use it, based on the number of bank accounts we're servicing," he says. "With this approach our IT costs are directly aligned with our business results." In spite of the success of such method, there is little evidence of its being successfully used outside the mainframe area. The main reason is that Unisys, IBM and others price their high end processing power and software at levels where their risk is low – and they have detailed knowledge of their proposed customers' businesses.
For the rest of the computing world, pay-by-use remains desirable but problematic. And there are several reasons why.
A first problem is that there must be an agreed and measurable unit of function that has been supplied. This is easiest over a remote service for a definable, pre-set job or period. In early 2005, for example, Sun Microsystems, introduced a flat rate grid compute fee of $1 per CPU hour processing power. In another example, Esker, a document software supplier, offers to send electronic documents such as invoices for a fixed fee per message.
Hewlett-Packard (HP) has been experimenting with a similar approach. Its Bristol, UK research facility has built an auction-based billing system, where animation companies participating its ‘SEED experiment' can bid for processing time on HP servers to render their drawings.
But most other applications – such as databases or ERP applications – are used much more generally and unpredictably, while composite or tightly integrated applications add further complexity.
And what if the software is hosted on a virtualised environment, where, unless billing is very tightly controlled and carefully audited, it is difficult to even agree what has been provided?
"Even pay-per-use is a tough one. The difficulty is with the word ‘use' – it depends on what use is," says Microsoft's Rudder, who cites an example where ‘use' may be for a few minutes a month or just for disaster-recovery purposes. In these instances, he says, "it seems something more than zero is fair, but it doesn't seem like the full value [of the software] is fair. And I don't know how to split the difference. I really don't."
Certainly, in this context automated billing is seen as a challenge both by customers and suppliers – mainly because of its complexity. "Charging at that level of granularity is a way off – it is simply too complicated. I'm not sure the vendors will come up with a model that isn't uncomplicated," says Rob Jones of Alstom, whose main software suppliers mainly use per processor models in spite of his use of virtualisation.
Microsoft's Rudder agrees: "We could take an approach where we audit everything and charge per use. But that hasn't been our policy in the past and probably wouldn't serve us perfectly. We like our technology to be available, to be easy to use, and not to have [administration] extra costs." Indeed, research has shown many customers are wary of software metering.
Clearly, it is early days for pay-per-use computing. IBM's On Demand programme, for example, implies some kind of on-demand, flexible payment, but in fact, most customers pay in a traditional fashion.
According to a recent report in the investor magazine, Forbes, On Demand billing projects at engineering company Fluor, American Express and electricity and gas utility NSTAR, are all running behind schedule. Of Fluor's 1,500 computer servers, only 200 are billed on a usage basis partly because the billing software is immature.
But there is a third issue: billing technology is likely to be extremely complex if it is to accurately capture the way that software is used in a service-oriented environment. In future, it is widely agreed, software will increasingly be made of dynamically linked components and services, some used almost continuously and others only occasionally.
For this, central billing engines could be required that can measure hundreds of services that are momentarily invoked. At the recent Information Age ‘Future of the Data Centre' conference, one delegate proposed that the ideal model will be the equivalent of the mobile phone billing system, which can meter calls based on usage across a network of many suppliers. But he admitted that no such system is commercially available today; his company has even considered converting an old Computer Associates mainframe package to tackle the job.
Una Du Noyer, head of infrastructure and security at IT services giant Capgemini, agrees that the telecoms industry may provide the model: "We are now where the telcos were when they were moving from fixed line [to fixed-mobile coexistence] – and they cracked it." She suggests that the technical answer may be provided not just be by software, but by services providers who track all the services that are used. This "capacity broker" will be able to orchestrate billing and scheduling dynamically.
Jason Weisser, president of enterprise integration at IBM, says that IBM understands the problem and is working on it. He describes how a management and monitoring system will sit at the heart of the service-oriented architecture. "A [web] service can be replete with an agent that measures its use. The complexity is not that problematic."
He concedes, however, that IBM does not have a solution ready yet – and that while the technical problems may not be that great, for many software companies "it will radically change their business model".
Another proposal is that an emerging form of software, known as event orchestration or event processing systems, be used as the basis for billing. These systems, expected from suppliers such as Tibco, should be capable of treating software or service use as a billable event.
At present, even simpler, composite applications are beginning to cause problems. When SAP's CEO Henning Kagermann was questioned about how SAP will charge for XApps (SAP composite applications) at a recent conference, he admitted SAP was not sure how to charge customers. Some customers felt that they had already paid for the underlying components and so would not be charged for new composite applications. In fact, SAP intends to charge for the extra, integrated functionality.
Once again, Rudder rubs his head: "[How do you charge for] parts of the app that can dynamically appear depending on the request that comes in? That is [another] tough one," he says.
Follow the leader
Is there any obvious solution in sight? There is widespread agreement that the current models are broken – but also that nothing so far being trialled or used will serve users who are implementing virtualised, service-oriented environments.
"That is sort of a work in progress for the industry: to figure out how we want to do those sorts of [dynamic and utility] pricing. People have tried several [types] of utility pricing and it hasn't worked," says Rudder. It is also clear that customers themselves have an important role to play – the future of software charging will be decided by buyers as much as suppliers.
That means they need to make up their minds about a few things. Jaqueline Woods, vice president of global pricing and licensing strategy for Oracle, notes that "customers are more satisfied when they can easily identify and predict what their licensing fees will be." This is a tendency that has been identified in several surveys.
That caution has led customers to ask, simultaneously, for flexible, agile pricing, and for predictable, budgetable bills. And while they want accuracy and fairness, they are reluctant to allow intrusive metering and auditing. "One of the real issues for vendors is that software buyers can't seem to agree on what kind of licensing scheme they prefer," conclude AMR's Shepherd and Carter. That may be because customers still expect the software industry to take the lead.