The real meaning of the service level agreement

The real meaning of the service level agreement

Summary: I believe that outsourcing It is almost always wrong - but it has its uses if you want someone else to take the hit for forcing IT management change.


In reviewing someone's data processing operation the first thing you ask for is the service level agreement [SLA] because that's the preeminent control used in that type of organization.

Like all DP organizational artifacts the SLA has a long history - going back, in this case, to 1920s job descriptions for data processing management requiring incumbents to guarantee things like the on time delivery of the printed AR reports.

In today's context, however, the SLA is mostly used as a get out of jail free card: as a limitation on service expectations by DP people; as a critical element in getting an easy ride from the auditors by both DP executives and the senior people they report to; and, as barrier keeping DP people in a distant and clearly subordinate role by executive management.

Basically the problem is that an SLA commits DP to meeting specified expectations - and thus both relieves DP of any need to exceed those expectations and acts as a barrier separating those on each side of the agreement. As a result its existence in an organization testifies to that organization's ability to resist change by passing costs on its customers - meaning that its existence is characteristic of government and monopoly, or near monopoly, organizations; including industry level IT monopolies in which the employers compete but all use the same, essentially interchangeable, IT people, tools, and methods.

When confronted with an organization that relies actively on SLA enforcement through some kind of DP management committee but is now facing genuine cost pressure - say an American state or municipal agency facing sharply falling tax revenues- there aren't a lot of good choices.

One is to take advantage of the nature of the SLA process itself to recommend and strongly support out-sourcing all IT work. You do this nominally because outsourcers always promise quick savings and because use of the existing SLA as the basis for the contract means that no significant organizational change will be needed - but really because out-sourcing under cost pressure is a bad idea whose eventual reversal should - assuming cost pressures continue - lead to the kind of IT change the organization needs but is not yet ready to undertake.

The more dangerous alternative is to go after real change now - but that's extremely hard to do largely because you've got to pull off two miracles at once: change senior management perceptions, and change the way IT is run.

At the senior management level you'll be dealing with people who mostly don't want to hear it: and getting them to first internalize the reality that IT provides the organization's "nervous system" and isn't an arms length expense center at all, and then accept that DP's relatively poor performance, organizational isolation, and freedom to escalate project costs have historically been due to the SLA centric management processes in place, is usually more of a challenge than most of us can handle.

At the IT management level you'll be replacing bodies because what you need is an outward, service oriented, focus to replace the inward, utilization oriented, focus in place - and you're just not going to get it with people promoted under the existing system.

And the complication? it's been my experience that senior executive commitment to change seldom lasts long - so once you get them on side, you typically have between four and six months to get your IT changes set in stone because otherwise the little picture players in the organization will gut your efforts and leave the organization worse off than it was before.

Topic: CXO

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • RE: The real meaning of the service level agreement

    Blah Blah Blah SLA Computers junky software are useless
  • RE: The real meaning of the service level agreement

    Always the simple reasons. Unfortunately, Rudy reality is always more complex than you want to believe.

    First my sincere congratulations for making it through an entire column without sniping at Windows, OOP or any other 21st century phenomena.

    While you have characteristically turned at interesting topic into an impenetrable wall of text, SLAs and outsourcing have led to marked changes in IT.

    SLAs are generally a good thing for both internal and external providers. They basically define what you are going to get and provide a tool to enforce it (essentially not paying them if they don't meet goals).

    The problem with it that outsourcing brings, is that you may have no expertise left in your organisation to evaluate the SLA in the first place. You can of course outsource for some consultants to give their verdict on other vendors' SLA proposals, but it starts looking like "Turtles all the way down". You also run the risk of hiring consultants with bees in their bonnets, who see all problems through their own looking glass - yes I'm referring to you Rudy ;-)

    The desire to save money, which usually results in the opposite and makes more money for your vendors is the main thing driving the cloud hype at the moment. However, rational heads see clouds as essentially exactly the same "helpful" IT department, except it's now private, deals with thousands of clients and has no responsibility for your business, besides its SLA. Better still you now have another weak point to worry about - your vendor's company, which is now inescapably intertwined with yours. No real problem if it's MS, but a real worry if it's a new cloud vendor who may go bust for any number of reasons.

    So by all means enter into SLAs and even use cloud vendors, but make sure you retain some expertise in your own company to be able to evaluate these agreements.
  • RE: The real meaning of the service level agreement


    The A in SLA stands for AGREEMENT. Most SLA's (about 99%) are put in place for the protection of the people PAYING for the server, software or service. The only protection for the server/software/service people is against UNREASONABLE expectations. Unreasonable being things such as unobtainable, unreasonable, or requiring an additional(unexpected) capital outlay.

    The other point you seem to miss about SLAs, are that they are NEGOTIABLE and can be changed(with agreement of both parties) and can be unique to each companies needs and expectations. Before agreeing to an SLA, people need to have a set SLA review in place(yearly is appropriate)

    SLA's are about accountability, expectations and needs.... nothing more nothing less.

    That being said... it pays for a company to have the metrics in place that are important to THEIR company or THEIR department, after all they are the ones usually PAYING for the servers/software/service. This way both sides can see the starting point and where they may need to go... and where they need work on.

    People who argue against SLA's fall into one of several categories and shouldn't be trusted to provide a server/software or service to you, because they are basically trying to avoid any accountability of the things they may be promising that they can deliver. Those who don't want to be accountable, tend to be those who have cut corners... or don't have the skills, or are overstating their(or their hardware/software/processes/peoples) ability. AKA... they have an agenda...

    What's your agenda Paul?
  • SLAs are important

    Just going by ITIL, you first need to define all of your services in a "Catalog of Services". This is good since you need to sit down and access just what you can provide (and at what cost). These services are "flow through" IOW there are SLAs between internal groups (called OLAs). Whenever a SLA is not met, you can drill down and find out exactly which OLA was at fault and do Problem Management on the issue.

    This isn't a case where SLAs confine you into "not doing more" for your customers. The costs are built into the SLA, and if your customer wants more - it will cost more - pretty simple. You can always give more service than is paid for - which makes you look like a "miracle worker" (in Scotty's parlance), but it always bites you in the end. Exp. The SAN goes down and 100 servers are wiped out. Which one do you bring up first, second, etc.? If you go strictly by SLA, then that "super service" customer may need to wait - which is NOT what he expects from you. Hey, it happened at Ford - and some servers were out for 3 days (they had to restore the entire SAN from backup - we're talking over 100 Tb).

    After that, every customer wanted to know EXACTLY where "in line" they were when things went south. We looked at ranking everyone by business impact - but I had a better idea. He who pays the most, gets the fastest service! It makes a ton of sense since critical apps SHOULD be paying more for support (use eBay-style bidding!).

    In the end, no one backed me up and the ranking was relagated to "future study" i.e. nothing was done.
    Roger Ramjet
  • An aside

    Murph, have you talked about the way Oracle is jacking up prices on Sun? Those SLAs are close to doubling (12% of server price per month I believe). It's driving my new employer to Linux RAC - without any Sun equipment.
    Roger Ramjet