Outsourcers Passing the Buck


Outsourcing is a tricky business when it comes to costs. Since there is at least one extra financial stakeholder in an outsourcing situation (more, if it's a "multisourced" model), the task of figuring out how to allocate, recoup, and bill for the shared and dedicated fixed and variable costs without introducing unneeded complexity.

For that reason, the customers and outsourcers try to keep things as simple as reasonably possible. I have been noticing a trend lately with outsourcing using a chargeback framework with their customers that may be a bit too simple. Recognizing that they can no longer charge "per box" with virtualization, they take it one small step further, and give a customer a "per host" and "per VM" price.

That way, they accomplish part of my recommendation of separating the infrastructure costs from the management costs. If 100% of the infrastructure costs are tied to the host (plus a small amount for the tools and labor associated with the infrastructure layer), and any per-VM costs (mostly OS management labor, plus a little bit for things like antivirus and other agents), then you eliminate the problem where "one size fits all" when it comes to VMs. There is no disincentive with the provider or the outsourcer when customers ask for "small" versus "large" VMs. 

As long as the per-host price is updated as more powerful hardware becomes available, this model works quite well. Moreover, it fully transfers the risk of unused capacity to the customer.

Here's the problem: it only works well with a single business unit customer. Virtualization is supposed to provide us with a liquid, shared, yet secure pool of infrastructure for multiple business units, multiple SLA requirements, and different capacity needs. The per-host / per-VM model passes the chargeback buck (literally!)



Let's imagine a conversation between the outsourcer and its customer:

Outsourcer:

Well, here's your price: $400/month per host, and an additional $150/month per VM, all-in, fully managed. That's not bad, compared to the $300/month we've been charging you for physical servers, huh?

Customer:

Great! I love how you guys save me money.

Outsourcer:

 I know. Isn't it great?

Customer:

What if I have VMs from than one business unit running on the same host? You guys told me I could do that and still guarantee performance and security.

Outsourcer:

Of course you can. It's solid. One big liquid pool of capacity that can be carved up into little liquid pools of secure, guaranteed capacity.

Customer:

But how do the business units pay for it? You gave me a single per-host price.

Outsourcer:

Not our problem. You'll have to figure that out yourself.

Customer:

But you're the one with all of the data. Why didn't we come up with a capacity-based pricing model?

Outsourcer:

 Umm… good point.

 

If a customer needs a way to charge back to individual business units, the pricing method between provider and customer should closely match that between the customer and its business units.

The per-host / per-VM model forces the customer to maintain their own complex pricing model with their own business units. Or, worse, it forces them to isolate their business units into silos. The outsourcer is the one managing the capacity and is in a better position to design and manage a more mature pricing model (with a mix of fixed/variable + shared/dedicated costs).

Often it's not even the outsourcer's fault. Sometimes outsourcers are forced by the customer's outsourcing advisory consultants (I'm looking at you, TPI) to fit a particular pricing framework that has a "per instance" charge. This way, the consultants can pit the outsourcers against each other on a level playing field with normalized pricing. Once the real world kicks in, the customer realizes the normalized pricing doesn't necessarily fit with their business.

Any time I see an outsourced customer re-swizzling, re-jiggering, and reselling an outsourcer's services to its own business units, I get a little scared.

 

 Digg 

 

What did you think of this article?




Trackbacks
  • No trackbacks exist for this entry.
Comments
  • No comments exist for this entry.
Leave a comment

Submitted comments will be subject to moderation before being displayed.

 Enter the above security code (required)

 Name

 Email (will not be published)

 Website

Your comment is 0 characters limited to 3000 characters.