Rethinking Software Pricing in a Service-Oriented World
Charging for software was simple in the early days of the PC. You bought your app on a floppy, and you had the right to install it on your PC. Pricing was one floppy/one user/one CPU. Then came client/server with its per-seat pricing. The software installed on one server and multiple clients, so charging by the number of users made the most sense. Next came the Internet, and with it the n-tier architectures required to scale software on cyberspace. Now, counting users was problematic, so per-CPU pricing became popular. And all the while, if pricing became too complex, there was always an enterprisewide license that would boil the whole mess down to a single–but not insignificant–dollar figure.
Today, the rise of Service orientation heralds the need to rethink software pricing models yet again. Because Service orientation means thinking about software functionality as location-independent Services on the network–a layer of abstraction that masks the complexity of the underlying technology, if you will–per-CPU pricing can be problematic. Rather than implementing monolithic systems, companies are realizing that they can build loosely coupled systems that are composed of Services of varying degrees of granularity. Given that Web Services are changing the way companies build, deploy, and manage their IT assets, doesn’t it make sense that it will change the way they buy them, too?
Functionality for License
Traditionally, software companies have sold application functionality via a licensing model. That is, a company would purchase certain rights to use software as often as they liked. And this model made sense in the past, since in effect, companies were taking “ownership” of the applications they bought given that each application was a monolithic stovepipe — every much an asset like the office chairs that the developers sat in. One of the primary benefits of the licensing model for application functionality is that it is well understood. Companies understand how to budget for, acquire, and account for software assets that they purchased.
However, these licensing models make little sense in a Service-Oriented Architecture, where an application might be composed of hundreds of individual Services, each running on separate servers, perhaps even redundantly on different networks, each performing an individual task that contributes to a coarse-grained business application. In fact, in a Service-oriented environment, per-CPU licensing actually punishes users for trying to achieve the goals of distributed computing —- the more CPUs you distribute a Service on, the more it will cost you. As such, traditional software licensing in which the notion of software “ownership” is tied to a specific deployment is at odds with the virtualization inherent in Service-orientation.
Furthermore, in a true SOA, Services can be added, modified, or retired at will. As such, companies might be forced to pay for all possible uses of a Service in an enterprise, regardless of whether or not they actually use the Service. Thus, a licensing model for Web Services penalizes users for implementing truly agile IT infrastructures, since in essence, companies would need to pay for the whole universe of Services they might need at their disposal.
Functionality for Rent
One relatively new approach to charging for software that resolves some of the limitations of the licensing model is the notion that companies don’t have to purchase application functionality, but rather just lease it for a period of time. Known as the subscription, membership, or rental model, this pricing model allows companies to only pay for the functionality that they need at any one point in time. Companies can pay by the month, by the desired application, or by any combination of functionality, timeframe, and number of users they require.
To this date, the subscription model has had mixed success. While some Web-based companies have found success in this model, notably SalesForce.com and a few select others, most companies never resolved the business and technical issues involved in delivering software this way. In fact, the Application Service Provider (ASP) market largely fizzled due both to business challenges as well as technology roadblocks, including the difficulty of integrating with the non-leased applications that companies had in-house.
Yet, the subscription model offers some promise for companies looking to purchase or sell Web Services-based solutions. In particular, companies that are in the pilot phases of deployment may find comfort in the fact that they only purchase the functionality that they need at the time they need it. However, there are many significant problems that make subscription models far from optimal for Service-oriented software in general. When Services are reused and embedded into coarse-grained business objects, it is hard for a company to keep track of when it is using leased functionality. It might come as a surprise to some companies when their business processes begin to fail because the subscription expired on one Service out of a hundred used for a particular process. Thus, subscription models discourage the construction of composite applications.
Finally, subscription models work best when it’s easy to outsource Service itself, or at least, when it’s practical to place the Service outside the corporate firewall. Since subscription-based Services are not under the direct control of the enterprise, companies tend to not want to implement these Services as part of core operations behind the firewall, integrated with their back-end applications. Rather, since the Service can be discontinued at any time, or since an external third-party might be managing the Service, many companies see the subscription model as most appropriate for Services intended for their extended enterprise of customers, suppliers, and partners.
Functionality by the Metered Unit
Another approach widely considered by Service providers is charging for Services on a fee-for-use or per-transaction model. In this model, users would pay based on the number of times they use a given Service. In many ways, this is a “pay-as-you-go” approach, and can be quite attractive for infrequently used Services, or for companies that are simply not sure about how they will use certain Services. On the plus side, companies are actually used to paying for things on a fee-per-use basis. Transaction-based pricing models are often called utility computing because of the similarities to the true utility companies —- electricity, telephone and the like —- since those utilities have been charging on a fee-per-use for over a hundred years. Likewise, companies buy business services, such as consulting services, copy shop printing, and outsourced services, on a transaction basis as well. Thus, corporate financial officers are adequately prepared for transaction-based billing. However, they are not quite as comfortable with transaction models for purchasing application functionality, because they are difficult to budget for. Just how much will a particular Service be used, anyway?
There are more serious challenges with the per-transaction pricing model in a Service-oriented environment. In particular, transactional models penalize Service reuse. The more a Service is used, the more you have to pay for it. And, just like the subscription model, when companies aren’t aware of how they will be using a Service, the transaction model could well be an open wallet. On the provider side, transaction models also pose serious challenges. Micro-billing, or billing for Services in very small increments, has long been a promising idea that has yet to become a cost-effective reality. In fact, only telecommunications companies have the infrastructure to handle wide-scale micro-billing. Even credit card companies have too much overhead to support the monitoring, management, and billing of large numbers of small transactions from many different vendors. Finally, offering transaction models requires significant functionality on the Web Services Management side. Companies looking to bill for or even monitor Web Services traffic on a per-use basis will need to have robust runtime monitoring, active management to prevent over-use, and the ability to identify Web Services dependencies to help business plan and budget their SOA roll-outs.
ZapThink Take: Offer the Full Menu
So, given that there’s no such thing as the perfect Service-oriented pricing model, how should software vendors price their offerings as they move toward Service orientation? The answer is remarkably simple: remember that the fundamental business driver for Service orientation is business agility. It would clearly be foolish for a software vendor to invest substantial resources in building a great product, only to hamstring its customers with its pricing model. Therefore, application vendors must offer all three pricing models. To maintain their customers’ business agility, they must require that the customer, not the vendor, select which pricing model is most appropriate to implement. Furthermore, it is quite likely that many enterprises will implement all three approaches at one time. For example, it is quite conceivable that the Service-oriented business application of the future will have some licensed parts, some subscription parts, and some pay-per-use parts. Therefore, ZapThink recommends that software vendors offer all three pricing models above. By offering this freedom of choice, software vendors help their customers free IT from making business decisions, thus contributing to their customers’ quest for business agility.