End-to-end service assurance
Pipe dream or realistic goal?
Reg Research It may not always seem like it, but wherever IT is responsible for providing applications or communications to end-users, it takes on the mantle of being a service provider.
If, or more normally when, a user calls to report a problem with the app that they use, they’re not calling to report a congested network or server with memory exhaustion or any of the other components that make up the delivery chain – what they are concerned about is the experience they receive at the point of delivery. This makes IT responsible for delivering an end-to-end service, even when there are no agreed service levels.
When delivering end-to-end IT services, approaches can range from best effort, through supporting individual systems, all the way to business service level agreements covering the entire service.
When we look at how things are in the Reg reader base we see that there is quite a varied approach to IT service delivery (Figure 1). This result is likely to be an optimistic one because of the nature of the online survey, where self-selection is likely to lead to an over-representation of those with an interest in service management as a topic.
Thinking about IT as an end-to-end managed service is challenging, no doubt, and may seem unimportant or even unattainable when there are other pressing priorities all competing for attention and budget. A common point of view is encapsulated by a number of comments we received:
“BSM is a nice to have in these tough economic conditions”
“There is a lack of funding for forward looking projects”
But let’s consider this from a “feet on the ground” perspective. However IT is delivered, you have to do end-to-end service delivery – a problem is, after all, a problem and it needs to be resolved or actioned. If the business needs IT to deliver something and it is not happening, then users are unhappy and the business suffers. What makes the difference is the degree to how efficient and effective IT is at resolving issues and whether the business values this.
In the absence of Service Level Agreements (SLAs) things often default to Service Level Expectations (SLEs) that grow haphazardly with use and often have very little bearing on their true value to the business. This can make it difficult, if not impossible, to prioritise issues or requests in an ordered way.
We know from our research that the approach to IT service management is what often makes the biggest difference to the satisfaction of users and the value of IT to the business. When we correlate the data, we see a number of factors that stand out as being important; and together these form a virtuous circle. The order in which these occur can vary of course, but as a rule of thumb a general sequence naturally emerges.
The starting point is getting IT more closely engaged with the business. This is predominantly about talking to the business and getting to know the issues and drivers that the organisation as a whole is facing:
“There is still a disconnect between the 'needs' of business and the 'goals' of IT. The IT goals are not always in support of business which causes a degree of stress.”
The next stage is to take this understanding and turn it into the specifics of what is required of IT by the business. The ideal is a mutual agreement of the portfolio of services to be delivered and the recognition of the investment needed to underpin it. This is a really tough area to get right and requires a commitment from both sides in terms of clarity and predictability as we can see:
“It's hard to meet business objectives when they are constantly being 'redefined'. Where there is consistency in vision there is consistency in service delivery.”
The difference in approach can be a major change, so that at times it can seem that the services of a marriage guidance counsellor may be required to help this along:
“Changing the way of thinking of both IT and the business / users to get the new approach accepted.”
Once the portfolio of services are defined and agreed, the challenge then becomes meeting the expectations. This involves translating the SLAs into a set of policies that can be implemented, managed and monitored.
The basics of service management - such as incident management and change requests - are reasonably well covered, according to the responses we received. However, a lot more effort is still required, with approaches such as performance management and end-to-end-investigation, when it comes to policy definition and tooling for more advanced service management. (Figure 2).
The reasons for this are varied, but are often a result of the ad-hoc evolution of IT leading to variety and fragmentation of the systems and tools that make up IT services. Getting this sorted is partly down to using suitable tools for the job. Those with the most effective service delivery typically consolidate their tool sets down to just one or two primary suites. But assessing and choosing these is far from easy:
“Finding the right product for the job can be very time consuming.”
“Waiting for well integrated product sets to work properly is frustrating!”
Critically, and this is the joint responsibility of both IT and the business, much of the fragmentation in management is down to a lack of will to invest in sorting the issue:
“It’s mainly a budget issue - with the right amount we wouldn’t face any major issue.”
"Money. It’s always the last thing to get funding, but if an emergency arises then it's a no brainer. But that event has a career penalty.”
We find ithat those IT departments that make the investment in service management are often better in tune with the business and receive funding to invest in improving management. It is making the case and fighting for the budget that is vital to kick-start the journey to effective service delivery.
This brings up the hot potato of how IT is budgeted and funded, bringing us into thorny issues such as billing and chargeback, but that discussion is best left for another day.
Sponsored: DevOps and continuous delivery