Catalogs and portfolio management are valuable to distinguish commodity services (like electricity) from premium services. However, using a catalog to get users to appreciate IT more is -- in my view -- getting the cart to push the horse. Electricity has the benefit of having a unit of measure (use more, pay more). For a long time IT did not. Thanks to recent developments like catalogs and cloud computing, we can finally start to sell IT by the pound. This however does mean we need to get serious about calculating what the various pounds of IT should cost, and the portfolio is a good place to start.
Last spring I wrote about the relative difficulty of calculating IT costs, sharing a CIO.com article written by IT consultant Bernard Golden in which he points out that few IT organizations, even service providers whose business is based on being able to provide services for less, know their true IT costs.
Gartner analyst Thomas Bittman makes a similar point in a recent blog post. And it's an issue that could hamstring mass adoption of cloud computing, he implies. Neither cloud computing providers nor their customers have a good handle on the customers' requirements. Most providers today don't address this, instead offering one-size-fits-all cloud services that they believe will fill the needs of the majority of their potential customers. But as more companies try cloud computing, they will inevitably want a wider variety of options from which to choose.
Some service providers will fail as they try to offer more options, due to the hassle and expense of retrofitting their IT infrastructures, opines Bittman. Service options link to and trigger automation behind the customer interface. Rather than building lots of automated processes, many providers instead will focus on targeted vertical offerings with a limited number of options, Bittman says. They'll have to weigh the added cost of rearchitecting their infrastructures to provide more options with the potential new business they'll gain by doing so.
Enterprise IT organizations building internal clouds for their users will face a similar dilemma. As Bittman writes:
Do they limit their offerings to their service catalog alone, or do they allow exceptions and special requests-which will add overhead and cost?
Thanks to their knowledge of their companies' business processes, internal organizations should enjoy an advantage. They should have an easier time understanding current customer needs, forecasting future ones and taking steps to ensure their IT architecture will support those needs.
Cloud computing customers working with external service providers -- especially those doing so without working through internal IT channels -- may undergo a rude awakening, writes Bittman:
In most cases, they're used to an enterprise IT provider who reacts to custom requests and changes in requirements. There is someone to talk to. There are often implicit "service level" requirements that enterprise IT handles without the customer even knowing-like disaster recovery, security, regulatory compliance, availability, legal requirements/risk. Enterprise IT often over-provisions services for users-giving them more than they asked for. Don't expect that from a cloud service provider. Failure to understand your own requirements might lead you to choose the wrong provider, increase your costs, or any number of scarier problems. Bottom line, fully understand your service level needs before you take the leap.
Bringing it back to service catalogs and a portfolio management approach, Bittman urges IT departments to create detailed service-level agreements, to be more transparent about the services provided, including those (like disaster recovery, etc.) that are not obvious to end users, and to "prepare for the time when external cloud service providers will be a viable choice." He suggests establishing an internal cloudsourcing center of competency and/or enlisting outside help.
Honorio Padron, Global IT Advisory Practice leader for the Hackett Group, made a similar suggestion when I interviewed him last spring, to create what he called a global business services organization. As he explained it:
You want a service model where a GBS (global business services) organization forms, and there is one focal point and one professional organization that can manage that category and source it, either internally or externally. As opposed to having three executives who are trying to figure out "How do I do outsourcing?" Instead, it's all inside that single organization. And by the way, it's not static, it's very dynamic. What today is a center of excellence may tomorrow be a commodity.