SLAs: Do they hit the mark?

By Jeb Bolding
Network World ASP Newsletter, 07/16/01

The ASP market is a perfect example of how technology is becoming more tied to the business process and the emphasis xSPs place on service level agreements is indicative of that.

The general consensus is that service level agreements (SLA) focus on availability and performance but in most cases, those two metrics are different sides of the same coin. When a performance problem occurs, it's likely that availability also will be impacted.

The nature of how SLAs are defined shows that technology is no longer merely part of a back-office process. However, my concern is that as ASPs focus on technology-oriented SLAs, they risk forgetting what's actually important to their customers - or at least, what I believe their customers think is important.

For instance, SLAs should focus on who in an organization would be impacted by a performance or availability problem and what process (business, not technology) users are attempting to access. Above all, what's the impact of a problem to a company's bottom line?

Undoubtedly, these issues are as important to internal enterprise IT staff as they are to ASPs. However, ASPs are generally held to a higher standard of technical achievement and so they should focus on addressing the business as well as the technical issues of their enterprise customers.

I'm not sure that any vendors are solving all these problems, though. They are pretty big issues to address, and also highly customized. Business process costs and management issues are varied enough from enterprise to enterprise to require a significant amount of process consulting.

I have run across an interesting company, Indurasoft, which addresses at least the first two issues with its ePerform product. The software has a reasonable Web-based GUI front-end that allows customers to monitor the performance of their service providers.

What I like is that each aspect of the Web interface to an application can be set up as a 'business function.' For example, 'browse catalog,' 'login,' 'course registration' and 'my schedule' are all business processes that have either content or transactions attached to them. For each of these functions, the administrator can determine thresholds for performance and port access, and look for text patterns.

Assuming a problem occurs, an event is generated that describes the troublesome business function, such as " catalog search is performing below the 5 second threshold. " Just as important, the event also generates information about the user who was affected.

Instead of waiting for an end-user to call in with an application problem, the help desk can proactively solve a problem that is beginning to appear within the system.

In some cases, if there are repeat user problems, this is a great tool to determine if the issue is at the system or desktop level. Looking at historical user problems, desktop IT support can determine where the issues are and fix those at the desktop.