Tom Peruzzi's thoughts on digital, innovation, IT and operations

Even if processes do not or only fragmented exist, people start writing weird SLAs with implicit and explicit definitions of services without any service catalogue, portfolio or even without any understanding of what differs between infrastructure, app and a service …

What happens then? They start to build their opinion like “Hey, we have an SLA framework … ” or “Hey, we have a service catalogue ..” Asking them about how services are defined, build, maintained, monitored and reported results in answers like “this ist still done on a manual and on demand basis … ” or “… we are working on that topic …” or “hey dude, we still have to go a long way, keep on waiting …”

To be clear, thinking about SLAs is quite important to the organization and defining a structured aproach (aka SLA framework) is a really good way to go but:

• if your service support is still foggy, a major SLA part will be foggy too
• if your ownerships are not defined, a major SLA part will be undefined
• if you do not have any process about what and why is an offered service, you will define either customers wishlist or a very technical perspective

We will be able to list 100 or more additional blamings, but it is not our goal to do so. The goal should be the answer on what’s a better or more appropriate way?

I would suggest the following:

• Know your Service Support processes
• Get an Service Responsible/Representative in
• Know what you will be able to monitor and report
• Define your Service level internally, know what you are able to deliver (aka OLA)
• If possible show numbers, eco values mostly help by talking to your (even internal) customer
• Only define achievable goals/metrices
• Only define countable goals/metrices, at best they should be monitored and reported automatically by systems/machines

Start by defining the most valuable (business) processes for you customer and always think in terms of your customer and his potential end-2-end view. And  – maybe the essential point – communicate the SLA to all engineers which are needed to run the service. Defining is step1, running is 2 and running is king!

You can use frameworks like ITIL, CobiT and others to get an understanding of what and how you should define within an SLA and how the process can look like (how to come to a service portfolio, catalogue and the associated SLAs) but potentially this will be pretty to much at first step and business pressure will not allow you to run a one-year-project just for a bunch of SLAs.

So keep in mind, go as defined as possible, know what you can deliver and how to measure, agree on internally first, know your support processes, escalations and at last go to your customer. Assure, that your customer is familiar with those processes too and start defining the mutual understanding of the service (the SLA). At end communicate the results to your IT department and start implementing. And don’t forget to monitor not only the values, monitor the SLA too… (is it still valid, useful, anything to define better …)

All the best with your SLAs!