When Applications Talk To Each Other Via SOA, What Happens To User-Based Pricing


Alphabet soup of evolving application design patterns: SOA, EDA, BPM

It’s clear that SaaS doesn’t represent a threat to client/server pricing.  Consider what SOA might represent. In case the terminology is new, here are the definitions first. Bear with the abstractions. To be technically correct, we have to include Event-Driven Architecture (EDA) and Business Process Management (BPM) technologies as well for customers to get the full value out of autonomous services communicating with each other with few users involved.

  • In the case of enterprise applications, SOA means functionality in the form of business processes that are made up of services that communicate with each other’s interfaces by exchanging data. These interfaces might be implemented as Web services. The supplier electronically submitting an invoice to a customer is the relevant example here. 
  • EDA allows services in an SOA to be more loosely coupled. They can communicate by publishing and subscribing to events without either side talking directly to the other. A retailer tracking delivery of goods to its distribution center via RFID would be an example here.
  • BPM orchestrates services and includes users in a workflow where necessary to manage a complete process. A BPM agent for a supplier may be managing the order to cash process when a customer places an order that goes beyond their credit limit. The BPM agent may escalate this exception to the finance department as well as the sales account manager for resolution.

Real world examples of transition to SOA: connect applications and push access out to self-service users

IBM published a book of customer SOA implementations. What should stand out is how all the systems in a company come together to present the company’s offerings as a set of online services, frequently to external users. Today it’s primarily self-service access to systems. Tomorrow it will be business processes orchestrating communication within and between companies’ systems.

  • Aurora Health Care connected 1,000 applications and pushed out access to patient data to one million external users. They no longer have to interact with hospital employees to schedule appointments, pay bills, or view their medical information. Similarly, billing information from multiple doctors, clinicians, and laboratories involved in a single procedure are integrated into a single invoice sent directly to the patient.
  • Ireland’s EBS Building Society delivered on demand mortgage origination to a new, growing channel of independent brokers who connected to the service via their own systems as opposed to the internal agents who interacted directly with the system.
  • Fifth Third Bancorp exposes its payment processing services to merchants’ systems and point of sale devices directly in order to process 17 billion transactions annually. To its customers, the bank is just an on demand service provider.
  • HypoVereinsbank in Germany connected disparate systems so that its institutional customers’ trading systems could directly access its product offerings as services including order management, routing, and clearing and payment as well as access external market systems. In other words, the bank appears to its customers as a large online brokerage exchange service.

What happens when there are fewer and fewer users in the picture?

What’s clear from the above early adopter examples is that companies are beginning to turn themselves inside out and make their offerings into a set of online services. Fewer internal users are getting in the way. In other words, these services increasingly look like utilities that feature variable consumption. But traditional application pricing has been per user, as described above. What happens if there are only 20% as many users? Does the average price and therefore the revenue drop by 80%? Or do application vendors start to charge by transaction or API call, effectively adopting utility pricing? Perhaps vendors might adopt something more opaque that resembles PeopleSoft’s old pricing model that was related to the customer’s total revenue.

Even infrastructure pricing has been tied either to the number of users or a fixed number of physical server resources. With online services, capacity requirements move up and down along with fluctuating demand for the company’s offerings. But under current licensing rules the company has to provision and pay for all the infrastructure software it might need at the very spiked peak of demand via virtualization. Microsoft requires that SQL Server be licensed for any server or processor that it touches via virtualization any more often than 90 days. Oracle is even more hostile to variable consumption via virtualization. Customers have to license every physical processor or core the product is ever installed on or touches when running. While consumption-based pricing has yet to hit packaged applications, it’s already seeping into bleeding edge infrastructure environments. Bungee Labs, which offers an online platform for integrating other services, charges $0.06 per session-hour, so that monthly usage charges can range from $0.06 for occasional use to $4.00 for intensive use. The more well-known infrastructure from Google and Amazon, which are primarily targeted at consumer Web services, charge by CPU, storage, and bandwidth consumption.

As online services increasingly penetrate the enterprise, the emerging consumer utility pricing model is going to exert enormous pressure on traditional vendors, first on infrastructure and then on applications. As it currently stands, if a range of online services each experiences its own spikes and the customer has each service in its own set of virtual machine appliances, the customer will have to over provision and buy more infrastructure software licenses than there are servers in the data center. Current licensing models represent a price increase for infrastructure software in the emerging online services world. Applications will face the opposite pressure. They will have to figure out how to charge for utility-like consumption or appeal to new users like business users who need performance management and collaboration. There they will encounter a new competitor in the form of Microsoft.


Tags: , ,

3 Responses to “When Applications Talk To Each Other Via SOA, What Happens To User-Based Pricing”

  1. Why SaaS Isn’t The Real Threat To Enterprise Application Pricing « Transitioning From The Enterprise To Web 2.0 Says:

    […] to the cloud and tracking Web 2.0 « Roadmap to Improving IT Services Profitability When Applications Talk To Each Other Via SOA, What Happens To User-Based Pricing […]

  2. Peter Laird Says:

    Nice insight!

    I also like Jeff Kaplan’s podcast interview of Conor Halpin of OpSource billing (formerly LeCayla). Conor offers additional good insight on the weaknesses of user based pricing – one of which its too easy to get into pricing wars with competitors. You also can’t segment your high-value/low-value customers very well.

    [audio src="http://www.saas-showplace.com/images/LeCayla_0107final.mp3" /]

  3. Barry Briggs Says:

    Hey George long time since our Lotus days. This is a great and insightful post — the big issue around SaaS all up will be the integration with corporate business processes.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: