Business Utilities are about levers not CPUs

"As a Service" is a moniker tagged against a huge number of approaches. Often it demonstrates a complete marketing and intelligence fail and regularly it just means a different sort of licensing model.

"As a Service" tends to mean utility pricing and the best "As a Service" offers have worked out both what their service is and what its utility is. Salesforce.com have a CRM/Sales Support service (or set of service) and the utility is "people". Its a pretty basic utility and not connected to the value but this makes sense in this area as we are talking about a commodity play and hence a simple utility works.

Amazon with their Infrastructure as a Service/Cloud offer have worked out that they are selling compute, storage and bandwidth. Obvious eh? Well not really as some others appear to confuse or mesh the three items together which doesn't really drive the sort of conservation behaviour you'd want.

The point about most of these utilities though is that are really IT utilities. SFDC measures the number of people who are allowed to "log on" to the system. Amazon measure the raw compute pieces. If you are providing the base services this is great. But what if you are trying to then build these pieces for business people and they don't want to know about GB, Gbps, RAM or CPU/hrs? Then its about understanding the real business utility.

As an example lets take retail supply chain forecasting, a nice and complex area which can take a huge amount of CPU power and where you have a large bunch of variables

1. The length of time taken to do the forecast
2. The potential accuracy of the forecast
3. The amount of different data feeds used to create the forecast
4. The granularity of the forecast (e.g. Beer or Carlsburg, Stella, Bud, etc)
5. Number of times per day to run it
   

Now each of these has an impact on the cost which can be estimated (not precisely as this is a chaotic system). You can picture a (very) simplified dashboard




So in this case a very rubbish forecast (one that doesn't even take historical information) costs less than its impact. In other words you spend $28 to lose $85,000 as a result of the inaccuracy. As you tweak the variables the variables the price and accuracy vary enabling you to determine the right point for your forecasts.

The person may choose to run an "inaccurate but cheap" forecast every hour to help with tactical decisions and run an "accurate and a bit expensive" forecast every day to help with tactical planning and run a weekly "Pretty damned accurate but very expensive" forecast.

The point here is that the business utilities may eventually map down to storage, bandwidth, CPU/hrs but you are putting them within the context of the business users and hiding away those underlying IT utilities.

Put it this way, when you set the Oven to "200 C" you are choosing a business utility. Behind the scenes the power company is mapping this to a technical utility (kW/h) but your decision is base on your current business demand. With the rise of smart metering you'll begin to be able to see what the direct impact is on your business utility decision on cost.

This is far from a simple area but it is where IT will need to get to in order to clearly place the controls into the hands of the business.

They've paid for the car, shouldn't we let them drive?

The challenge of "build for the web" to SaaS economic models

Build for the web is a strong meme. Most of the time people focus on the technical elements of this and the end user elements. What I haven't seen people talk about much is the impact that this has on the current financial models from SaaS vendors. SaaS can give great benefits for companies by enabling an OpEx rather than CapEx model but the solutions today do assume that a person is using them. Working on the system I'm looking at right now its clear that this model is okay in most cases in 2009 but won't be the case for long.

Think about a world where you are looking to combine a SaaS CRM provider (user based licensing) with a Logistics solution (shipment based) and an analytics solution (user based) and create a new unified sales/marketing and shipping solution.



All fine. But now lets say you get clever and you realise that from the CRM solution what you are really interested is tracking every interaction you have with customers. Your internal people aren't interested in the various options the CRM solution has, they just want to be logging what is going on but using the analytics to provide them with visibility of what they should be upselling and what are the current globally successful products.

Looking forwards as SaaS vendors shift towards different utility models which address their financial demands (e.g. what is a "user" if a remote service or other SaaS solution is accessing it?) the complexity of information sharing is liable to increase, both in terms of licensing ("you shall not cache or store information from XaaS outside of the system except for your own individual use, it shall not be loaded into another application where users other than yourself can access it") and in terms of efficient financial management.

The transactional model, shipments, however remains valid and is very difficult to get around. Sure you can be more efficient on the bundling but you are always going to pay for the actual transaction. This presents both a challenge and opportunity for user based licensing solutions, they can move away from it towards a more transactional based approach, e.g. accounts/prospects/campaigns/etc for CRM, and start providing a business with a more direct measure of the actual value they get from an IT system.

The SaaS revolution has a long way to run and its economic shift is only just starting.

Technorati Tags: SOA, SaaScloud