Service Matters! ITSM & IT Management

Recently I was sitting at the O’Hare Airport, waiting for my flight back to India. There was a coffee shop in the waiting area and the shop lady was serving different items ranging from Mocha, Latte, Muffins to Indian Chai. I observed that the shop lady in between serving the customers was also trying to change the arrangement at the cash counter, in order to handle the customer better during rush hour. She moved the counter position, shifted a few boxes, small items here & there, but during this time she never stopped serving the customers. If it was not for the ease of changes & rearrangements on the fly, she would not have dared to do them amidst peak business hours...

I realized that each business continuously keeps changing, transforming, altering & upgrading just for one reason: to serve the customer better. The key behind any such move is: Do it quickly, Do it smartly & Do it economically. Technology also needs to change, transform & upgrade to support business. Larger is the degree of customizations in a technology environment, higher is the cost of changes. But many times these customizations are much needed in order to exploit the technology for business purposes. That’s why its always conflicting situation in front of Technology Officers (CIOs & CTOs) when they have to make a tradeoff between the cost of the change & need of the change.

I couldn’t help but draw a parallel between the coffee shop lady and the ITSM world. The way she managed changes at the cash counter, does an ITSM tool platform offer same ease & simplicity of changes?

In case of ITSM tools the situation looks little more complex. Most of the ITSM tools are highly customized for various reasons ranging from:

• Varied degree of process adoption across organization
• Organization cultural barriers
• Departmental needs for process
• Technology adoption roadmap

Because of these customizations built into the ITSM tool platform, when it comes to moving to a new platform it becomes very very difficult for Service Management organization to take into consideration all the customization needs while evaluating a new platform. More so when it comes to moving from a traditional client server based platform to a SaaS based ITSM tool.

As you know I have been talking about SaaS in ITSM and its potential in the market, lets look at how customization and configuration become critical factors for an On-Demand ITSM migration scenario.

Customization or Configuration: In a highly code based customization environment, any upgrades or migrations could result into unforeseen high cost making it near case of re-implementation. These codes based customizations invariably calls for signing a maintenance contract with the tool vendors who would take care of the upgrades and rewrite the new codes with the new version. In contrast to a code based customization, a configurable tool offers a great flexibility, ease & comfort in terms of upgrades or migration. Configuration eliminates the cost attached to the changes done through customization in an ITSM tool environment. Many of the software vendors today are promoting a metadata configurability using SaaS and multi tenancy.

The difference between a code based customization and metadata configuration is that in the later an application develops the logic for accepting the metadata and uses it for business processing and transactions. In case of customer specific detailing, all one needs to do is to change the metadata and the same logic picks up the changes. The actual application code doesn’t need to be changed. The metadata changes work outside the application and they communicate with the application logic using APIs. This makes the job simpler both for the application vendor as well as client. ITSM tools that have started aligning to SaaS based platforms; also provide the metadata based configurability. This capability of an ITSM tool can also help in mitigating the risk associated with the End-Of-Life technology scenario which calls for a migration and re-implementation.

Hope this has helped the readers get a view on why configurability is more beneficial than customization, when it comes to “Serve the Customer Better” as I had mentioned in the beginning of my blog.

Posted by Shraddha Tilloo at 06:27 AM | Permalink | Comments (2) | TrackBacks (0)

In my first posting on this topic I highlighted the trend of customers who wish to enhance the maturity and efficiency of their IT capabilities are looking towards their development and test infrastructure. The next part then looked at why such infrastructure tends to be built as an ad-hoc deployment rather than a service.

In this post I wanted to, by example, highlight some of the differences of building a pre-production environments service in contrast to a Production service. I want to take the example of measuring application/service availability, a critical measure of the quality of service to clients.,,,

There are three core challenges with capturing this kind of information in a pre-production Environment Service context. The first and most obvious is separating platform availability from application availability. In a Production environment there is little differentiation between platform and application as far as the users are concerned, the focus is the availability of the end to end system. In a development and test scenario it is critical to separate the two, because fundamentally it is quite possible that a given deployment of an application will actually not work or break during operation, especially in the early test phases. This means that one of the first activities in Incident Management is to determine whether there is a fundamental software code issue or platform issue. A best practice that I have observed is for the Environment Service organisation to take accountability for determining the source of an incident and referring accordingly, much like a traditional service desk, with an oft occuring characteristic that an Incident can be referred back to the client for a fix. The key point here is when the issue has been identified and then confirmed by the client as an application code defect, any service downtime is not attributed to the environment. This differentiation also helps to make a classic tension point between software projects and infrastructure teams transparent, so that the real issues can be identified and fixed.

Secondly ITIL availability is often measured as total user time of a given service, minus total user downtime. In a Production environment user numbers are relatively large, stable and well defined, so total user hours are easy to define to a reasonable level of accuracy per month. In a set of test environments, the user base is not stable and can change from day to day. The location of test users can also change. This makes useful Key Performance Indicators (KPIs) of this nature very fickle and hard to measure in a meaningful way. For example, an environment might be down for 5 days, but if there are no test users working on it, does it actually matter? Is it useful to report that a given environment is down for 5 working days out of 20 (i.e. 25%) that month? What does it tell management? The key is the impact on users, which as described is difficult to track, so management need to recognise this when setting targets and be careful not to set those which might skew the service offered to the users. One solution to this challenge might be to get the clients themselves to fill in a simple web based form that tracks user numbers in a given environment, this can then be used to calculate service availability.

Finally, there tends to be a much higher rate of scheduled downtime for code deployment and data refreshes in a development test scenario. This ‘downtime’ should also be excluded to the point it is delivered within an agreed timeframe. If deployments fall outside of this schedule, then it should be counted as service downtime. It is important, however, to measure the deployment times and seek efficiencies, as often deployments can be very manual and limit the useful time on an environment, which can cause delays to projects. A good target in this area would be to monitor on-going deployment times per application and environment class and seek incremental improvements.

A related topic is how to assess the priority of an incident, as just like the user base changes, so does the priority of certain applications and environments as per the project requirement. This is a topic for another day, but in the meantime I would invite readers to share their experiences around the specific challenges of a test environment service…?

Posted by Bruno Calver at 08:28 AM | Permalink | Comments (1) | TrackBacks (0)