How many enterprise IT organizations can point to actual documented agreements with their business customers for services provided? Out of these organizations, how many have service level agreements that use metrics the business cares about? Out of this smaller subset, how many actively monitor and report compliance with the agreement back to the business?  From my experience this is a very small number, yet the number of enterprises that would say they are "doing Service Level Management" is a very large number.  How can this be? 

Service Level Management has suffered from an identity crisis whereby the bar for "SLM" has been set too low.  Operational monitoring tools that report on thresholds like application response and transaction times are critically important inputs to SLM --  not to mention high-value solutions within operations -- but are they really scratching the SLM itch?  Also highly valuable are tools that aggregate and synthesize availability and performance data for a mapped collection of application(s) and infrastructure - the ultimate representation of "services" in some "Business Service Management" approaches as defined in a CMDB.  But are any of these "bottoms-up" approaches BY THEMSELVES really getting at the main value promise of "SLM" - managing IT according to business value by mutually agreeing on service measures with customers?  More importantly, are these bottoms-up approaches to SLM "good enough" starting points on the maturity curve, or are they merely a diversion that are setting up some IT organizations to fail?  Anyone who suffered through a bottoms-up CMDB project knows this pain all too well.

There are two main reasons that I believe bottoms-up SLM will quickly lose favor to top-down approaches. First, because Cloud computing is going to make true SLM a political necessity, and second because bottoms-up approaches can't get to true SLM value fast enough -- if ever.

The gospel of services has been preached to and within IT for a long time, but theory and practice are two different things.  Competing priorities, organizational inertia, and technical challenges have slowed many IT organizations' true embrace of a services approach and stunted maturity for the disciplines that hold the most promise for managing IT for business value - Service Portfolio Management, Service Catalog... and Service Level Management.  IT has naturally focused on the service management processes closest to its traditional technical comfort zone - processes like like incident, problem, change and configuration. Knowing that something is a good idea isn't enough motivation to win internal budget fights, persist against organizational inertia, work through technical challenges and accelerate the maturity curve. For SLM to truly take off it needs a compelling event.

Enter the cloud. OK, I know what some of you are thinking. This is where everyone with an agenda "X" claims that "Cloud makes X more important!" Maybe you think cloud computing will "change everything" or maybe you think it is "overhyped", but won't cloud services increasingly condition the business customer (and CIO and CFO) to think of IT in service terms?  They will get sales calls, flashy demos and glossy brochures (probably online as service catalogs) that describe services in the customer's language. They will get clear descriptions on what the services will do for the customer. They will get clear pricing. And they will increasingly get assurances of service quality with clear metrics - and consequences for not achieving those metrics. I'm not saying all cloud providers are great at this today, but the ruthless laws of economic evolution will make winners of those that do and extinguish those that don't. Even some who thought they were safely nestled within a captive enterprise customer base. Never before has the customer-centric concept of "service" had so powerful a poster child as with the cloud juggernaut.

After being conditioned to think of applications, infrastructure and platforms as services, business customers will ask their internal IT departments, "How does what you provide compare to this cloud service?" Or more broadly, "What do you do for me, at what cost and quality?" That is if IT is lucky. If IT is unlucky the business won't bother asking - they'll just work around IT and buy services directly from cloud providers, having long tired of fuzzy answers to clear questions like "What am I getting from IT for the money?" 

Of course, this assumes that IT is "lucky" if it preserves its current span of control. While disruptive, it could eventually be in IT's best interest to cede some of its traditional territory to external providers. If adopting "commodity" services from the cloud allows IT to focus more on unique value-add to its business customers, increasing numbers of CIOs and Operations and Development executives will hand more and more plumbing over to the cloud. But that won't get IT off the hook from framing that unique value-add to its customers in the newly accepted language of services - notably a service portfolio including clear quality, cost and function for each service offered. The adoption of cloud services by enterprise IT will of course introduce new challenges, including how to manage inbound cloud services as part of the service portfolio, their relationships to other cloud and internally-provided service components (multi-sourced services), and how they all come together to deliver value to each business customer. Once again, SLM needs to be front and center.

So we have:

1) pressure to communicate business value more like cloud providers, and

2) an increasing need to understand the quality implications of multi-sourced services. Add to this

3) a hangover from the Great Recession and calls for more accountability for IT's business value and you get what may be a perfect storm for SLM. True, top-down SLM - managing IT according to business value by mutually agreeing on service measures with customers.

Why won't the typical bottoms-up approaches to "SLM" be good enough? Couldn't you theoretically map infrastructure to applications in a CMDB, then map these collections to services in a catalog, then describe these services in an SLA the business agrees to, then aggregate metrics about those services and report them to customers?  At best, this would be a very long, costly path to get to SLM (or "Business Service Management" for that matter).  More likely it would likely miss the target.  

Among the many problems with a bottoms-up approach is that it assumes SLM is primarily a reporting function and that service levels are something you consider only after the service is designed, built and deployed. Doesn't it make more sense to understand service level requirements as part of the service design process, in collaboration with the customer?  A recent story on 60 Minutes showed how U.S. Homeland Security spent $1B+ on a new border monitoring system that included Border Patrol agents receiving just-in-time information on laptop computers in their trucks. It seems no one bothered to consult with the "customer" - the Border Patrol - who could have told them that the bumpy roads make laptop operation almost impossible while driving while the dusty environment along the Mexican border would quickly render standard laptops inoperable (this and other flaws forced a system redesign.)

Another problem with the bottoms-up approach to SLM is that it assumes that the same collection of application(s) and infrastructure is a "universal service" with the same description and service level metrics regardless of customer. Take CRM for example.  CRM may be the same collection of Siebel or SAP applications and infrastructure, or even the inbound "service" from Salesforce.com, but would you always want to describe it the same way, with the same pricing and service level metrics, to your VP of Marketing, VP of Sales and VP of Finance? The same underlying technology may need to be packaged and bundled as different service level agreements, and even different services, depending on the customer, not something that bottoms-up "SLM as reporting tool" is equipped to handle.

What's needed is a top down approach that starts with the end result in mind - mutually-agreed contracts for services for each customer, using language and metrics meaningful to that customer. Then connect that contract to underlying data sources in operations, service support and business systems in a way that cherry picks only the data needed to calculate and ensure compliance per the contract. Is this trivial? No, which is why CA bought Oblicore, a company that has proven that a top-down, contract-driven approach to SLM is the shortcut to SLM's intended business value.   

Bring on the cloud.