A little while back, I was talking with Dr Bernd Kosch, chairman of the Enterprise Grid Alliance (EGA), now to be the Open Grid Forum, and we got on to the issues of cross-charging within a utility-style environment.
My feeling has always been that cross charging within a company is a great way to waste money.
You start with, say, 1,000 local currency units as positive value on the corporate bottom line. You then spend some of this in measuring how much technology is being used by the different parts of your own company.
Also, the very measurement of this usage uses some of the technical resources that you would like to make available to the users. Having identified what the users are using, you then raise an internal invoice for them.
The users question the usage (or not) and finally 'pay'. Except they don't. All we've done is shuffle nominal monetary units around and no-one has created anything of value.
The problem is that the 1,000 local currency units that we started off with against the company bottom line have suddenly become 900. We've lost money, we've used technical resources and we've allocated human resources only to lose the company money.
But it seems that measuring IT and trying to get money from its users is pretty widespread, and my lone voice in the wilderness is unlikely to change that.
What is likely to drive a change in thought processes is the move to service oriented architectures (SOAs) based on utility computing architectures such as grid.
Why? Well, how are you now going to measure usage? You can't point to a server and say 'that belongs to sales' because it's all virtualised.
You can't easily allocate physical storage usage to discrete groups because again it's all virtualised.
You can't even look at application usage; we're talking composite applications created on the fly from reusable components here.
So does this presage the end of cross-charging? Not likely. What Dr Kosch and I were discussing was the move to value-based service level agreements (SLAs). And what, you may ask, is a value-based SLA?
The way we looked at it (and there is a focus group set up in the old EGA that was looking at this) is that once we have functional components on a highly virtualised infrastructure, we can begin to look at applying differing service levels depending on the internal customer.
As an example, let's look at voice over IP. VoIP needs to be managed to give fully consistent, reproducible voice quality.
Obviously, high quality is needed when we are interfacing with customers and more often than not with suppliers.
Internally, we have better bandwidth available to us and we may be able to offer un-managed VoIP that will be fine most of the time.
On the odd occasion when quality isn't so good, we can re-initiate the call and no-one is too upset.
So the contact centre pays more for its VoIP than the internal engineering staff. How about more transactional work?
Due to the way that a grid virtualises the underlying platform, all resources are potentially available to all applications.
The grid will make the best use of these resources depending on the type of application and the priority it has been given.
For example, a low priority application which uses little resource might end up running on a physical server with little power until there is a sudden unexpected peak requirement.
The SLA then kicks in, and available resources from other areas can be brought into play if they are not already being used for another higher priority application.
The group dependent on this application finds that the peak is successfully managed, without the need for them to pay for discrete extra hardware which will then sit unused for large periods of time.
However, the IT department can charge a higher agreed SLA rate than the base level, as the services provided to support the out-of-band application needs had to be 'borrowed' from other parts of the grid.
The key here is that cross charging becomes dynamic. The IT department can sit down with the business units and give them the options: a base level of functionality/performance will cost this much (or be free).
Higher levels of guaranteed base functionality/performance will cost this much extra. Peaks of performance can be covered at an agreed level of response, but it will cost.
Now it's down to the business. What level of risk do you feel that you can carry, and/or what level of performance are you willing to pay for?
On the other side of the coin, it gives the business a real means of managing SLAs. If the agreed level of service isn't given they can either agree to be cross charged only for the base offering, or can agree a premium offering recompensed as required.
Value based SLAs also apply in the software-as-a-service world; service providers looking for differentiators in the market can offer bronze, silver, gold and platinum service offerings based from the same infrastructure.
Contact centres and websites can provide different levels of response to known high-value customers than to ordinary customers, and can actively provide low service to those 'customers' who continuously eat up any possible margin from low expenditure through high contact.
Let's get rid of asset- and transaction-based internal money losing cross charging. Let's get rid of fixed service levels for all customers. Here's to value based SLAs: let the buyer decide whether they're cost-conscious or needs-driven, risk-averse or risk-happy.
Choose a level of service that you feel you need, but don't whinge when your cost saving low-level SLA gives you the service you deserve.
You can download the PDF version of this article here.