Network Computingwww.networkcomputing.com

Other articles by David Willis

Finally! A Light at the End of the Tunnel, Features, December 1, 1998 Fax on the Network: Pedaling as Fast as It Can, Columnists, January 11, 1999 Voice Over IP, The Way It Should Be, Workshops, January 11, 1999 LMDS: Is It a Little Too Much, a Little Too Late?, Columnists, February 8, 1999 Switching On Frame Relay SVCs, Workshops, February 22, 1999

Other Columnists

Business to Business By Brian Walsh On the Edge By Art Wittmann

Company Directory

Browse our directory to get data, starting with a particular company.

Reader Service

Allows you to request additional product information from our advertisers.

Print The Full Article

ClickHere

E-mail this URL

ClickHere

Buy the Book

It's hard to tell exactly what people are talking about anymore. The lazier trade press (which is to say, not this publication) can take partial blame for the confusion, parroting messages from the many vendors that have tried to align themselves with the popular service level movement.

As a result, my description of service level and your description of service level are likely to be quite different. Unfortunately, lots of folks are simply using the term the wrong way. For example, I've seen low-level device-performance-statistic trends touted as essential service-level data. That may be good network management, but it's not the stuff of service levels. It's simply what we should have been watching all along.

Used correctly, service level now seems to carry three broad meanings. First, we have the "plumbing" service level, which specifies targets for technical performance of system elements. Second is the "application" service level, which focuses on a specific application's performance, with all of its dependencies on the network, servers and client code. Third, we have the "business process" service level, weaving technological innovations into new ways of running the business: By most estimates, this is the Holy Grail of service-level management.

Back to Basics Fundamentally, an SLA (service-level agreement) describes a contract between a consumer and a provider, expressed in the terms the consumer understands and cares about. For as long as I can remember, IT has expressed its own service quality in its own preferred terms--the technical language of the systems it manages. We quote network-utilization percentages, host-transaction processing rates, and perhaps response times measured between a few chosen points. Armed with a litany of isolated numbers captured element by element, systems may appear to be healthy, even as customers complain about service.

This isn't a big surprise, because we're simply using the best numbers our equipment will dish up. And though fine-grain system-level data is practically worthless in any customer-relations situation, we whip out the reports whenever we're asked to explain why some application is performing poorly, or when we need to explain an outage. "Remote users have problems with busy signals? Impossible! Look at how often the ports are free!"

Out come these assertions that we're not responsible for the problem, that it's not my network. Or, not my host. Not my database. Not my application. Maybe you're just using the application incorrectly, you idiot. These are the times when everyone around the table is pointing fingers, and not just index fingers, I might add. The bottom line: If you're using system performance numbers defensively, you've lost the customer-relations game.

My Partner Doesn't Understand Me Take a look at the numbers you use to track your department's performance, and consider whether they mean anything to your customers. If you're reporting some technical nit about how many bytes per second a host can process, ask youself why any customer would care. Everyone--including your customers--has too much data to comprehend as it is. Are these numbers helping your partnership, or just feeding your irreconcilable differences?

Furthermore, if you're proudly reporting technical detail to disinterested customers, you're selling short your department's potential. If you let IT be viewed as a basic utility like the power company, you'll be the one in the dark when the big stuff happens in your organization. Nobody consults the power company when they make a strategic decision, they just expect it to follow suit. So relying on plumbing service-level metrics as the principal measure of your worth will prevent you from leading innovation.

You can quote network-utilization statistics all you want; what end users care about is whether their applications are running and if they'll stay that way, making application service-level agreements much more important to the business.

Keeping an application running probably seems like a simple request from the user's perspective, but it's not. Consider all the cross-functional dependencies supporting an application--a reliable network, trustworthy end systems, well-crafted application software, responsive training and support, and so on. It's why an automobile warranty guarantees your transmission or driveshaft will keep running, but it doesn't commit to getting you to work every day.

Application SLAs are an admirable goal for a well-organized IT department, but will likely fail without equal commitment from all involved. The strongest network can't keep a weak application from failing, just as the reverse is true. If users aren't trained, or vendors don't deliver equipment on time, or the helpdesk never picks up the phone, you've got trouble.

So an end customer's application-SLA contract may spawn a whole series of contractual agreements between disciplines, and that's where things get tricky. It's going to be painfully obvious when the organization isn't running on all cylinders. These subcontracts can quickly become a blame-defense tool to protect one area from the blundering of another, or to protect IT from the customer--completely changing the spirit of the agreement. Further, if the business is a complete mess, with ill-defined processes, you'll have little success making them more efficient--and if you try, your reward may be getting the blame for the user department's failure.

The View From Here Monitoring application service levels over a distributed network is notoriously difficult. Most people begin with data collected at the data center, but this probably isn't the best view. In a network of 1,000 users, there are 1,000 perspectives on how well the system is working. Chasing down a problem on any given user is not only difficult, it is often a contentious battle. Ideally, we'd have a way to verify what the user sees from the perspective of their very own seat.

Response Network's VeriServ is one of the few products that actually deserves to call itself "service-level management." VeriServ puts small agents on client machines, and tests applications on the fly from the perspective that matters the most--the end user's. VeriServ measures application availability and response time, feeding data periodically to a central point where it can be summarized and reported. By spawning application-level performance routines at the desktop, SLA metrics can be measured from the user's perspective. VeriServ agents can launch database requests or send pings to a specific TCP/UDP port address, and will soon do the same for applications like Exchange or Notes. Operating alongside applications, it's not exactly measuring real user response time, but it's as close as you can get without modifying your applications.

VeriServ's stealth approach to service-level management consumes very few resources on the client, and contrasts with what most network and system management products attempt to do. Instead of gathering vast amounts of data over time and attempting to make sense of it all, VeriServ simply measures what is most important. If problems occur, you can bring out any number of mature products designed to isolate and troubleshoot problems.

Keeping applications running is important, but providing a means for new applications that change the way the business operates is the ultimate target for the IT business process SLA. Instead of just providing plumbing or supporting an application, IT can lead business-process changes. It's not an easy thing to attempt, especially for the thin-skinned and/or diplomatically challenged. This type of change requires a solid commitment from the top down and side to side. Business process SLAs underscore IT's commitment to business over technology, and the faith of the business in its IT department. To borrow a cliché, power shared is power squared.

To keep this from sounding too theoretical, let me illustrate my point with a simple example. Imagine your company owns a string of handgun vending machines, which would surely be wildly successful on the Texas honky-tonk circuit. Each week, your company loads up trucks with an assortment of 9mm Glocks and Rossi .38 Specials and makes the rounds, unsure what stock needs to be replenished.

By putting radio-based telemetry devices in the machines and reporting their current contents in real time, drivers can carry just the amount of inventory they need--reducing warehouse space and radically reducing the distribution cost. These systems might even collect and correlate data between the host bar and its vending machine to better predict trends. For example, we might discover that Zima sales typically track with those of Lady Smith revolvers, and we can plan accordingly.

Dramatic technology-based improvements can't occur without the initiative of both IT and the sponsoring user department. It requires the kind of relationship that is nearly impossible to outsource, where a smart and responsive IT department becomes a core asset to the company. It's hard to beat a bilateral commitment that not only allows technology to support the business, but also allows business methods to change with technology.

Send your comments on this column to David Willis at dwillis@nwc.com.