SLAs Simplify Support

Service-level agreements (SLAs) were nearly nonexistent when I started in IT. Those of us involved in online systems implementation were too focused on keeping terminal-based applications operational and tolerably responsive to worry about such things; furthermore, no one had heard of them. There wasn’t much pressure for an SLA either, because end users were infatuated with the very existence of online systems, a vast improvement to the punched-card, batch-intensive way of business processing. Everything’s relative, and being able to sit at a terminal, bring up screens, enter data and interactively see the results was astounding.
 
But over time tolerable became intolerable, and end-user management realized response time, availability, and application design and delivery were vital to staff productivity and effectiveness. They demanded a say in online performance and accessibility, as well as the IT budget as IT chargebacks sapped their budgets. Much to IT’s dismay, the two department’s fates became interlaced, and accountability was imperative. Thus evolved SLAs, a negotiated pact between IT and it’s users. More generally, an SLA is a written contract between internal and/or external service providers and consumers as regards payments for provided services.
 
SLAs are no longer limited to computer performance and operating hours, but have expanded to include such service measurements as quality, responsibilities, turnaround time, help desk responsibilities, reporting requirements and other germane desires of the two (or more) parties involved. Nor are SLAs limited to IT and end-user departments anymore; they’re used between clients and outsourcers, consultants, and/or vendors. They’ve become pervasive, because they greatly simplify interactions between different enterprises, departments, ventures or any group of two or more organizations, customers, or providers.
 
While SLAs are ubiquitous these days, I’m limiting my discussion to IT (computing and network facilities), outsourcer (technology and consulting service providers), vendor (software and hardware product installation and problem resolution), and end-user SLAs. Here are some considerations in creating and executing SLAs:

SLA Structure 

An SLA is a contract, so the wording must be precise, clear, specific, thorough, comprehensive and complete—a document that leaves no question unanswered. Here’s how an SLA might be structured:

• Title page with “Service Level Agreement” followed by both parties’ names and contact information, followed by mission statement and document purpose
• Table of contents
• Introduction, purpose, background and scope
• Definition of terms, abbreviations and acronyms
• References and supporting documentation
• Overview
• Participants
  • Signatories
  • Departments involved
  • Contacts
  • Key participant responsibilities
• Client issues and concerns
  • Desired improvements
• Service objectives and measurement methods. Service objectives are a list of current metrics collected and desired improvements, including but not necessarily limited to:
  • Operational hours
  • Availability
  • Reliability
  • Exceptions to normal processing
  • Performance metrics
  • Capacity metrics
• Ratings and values of current service objectives
• Measurement details and reporting
• Additional considerations
• Supporting information
• Pricing and penalty assessment structure
• Index

Identify the Issues

A good starting point for SLA creation is to identify end-user issues and what is within IT’s capabilities and scope to provide. It’s an ideal opportunity for IT staff and end users to understand the other’s perspective and underlying needs. Here are some examples of items included in an IT SLA:

• Response time. Response time almost always plays a prominent role in SLAs. It’s directly related to productivity, both in terms of employee keying speed and train of thought. Optimum response time also provides superior customer satisfaction by minimizing wait time required to satisfy a customer’s request or order.
• Availability. System and application availability are equally vital to user productivity and effectiveness. Today’s business day for many firms is 24 hours in a round-the-clock global market. Regardless of the time, customers want answers, and a high availability, fully functional business processing system provides maximum customer satisfaction. Many IT departments also allow their staff to work from home on a part-time basis.
• Application development and delivery. SLAs are often used as a method of defining and formalizing the relationship between end users and the people who create, design and produce their computerized business processes. What’s the user’s role in application development? IT’s role, especially the developers? What documentation will be provided by each party? What meetings are to be held, and by who? What testing responsibilities does each party have?
• Vendors and outsourcers. These SLAs differ from the previous SLA in that the IT SLA was intraorganizational, while an SLA with external participants are interorganizational, requiring a contractual agreement. The negotiation must include financial compensation, and must be mutually approved and accepted.
   

An IT SLA might also include:

• Network bandwidth and capacity management, performance, and availability
• Response time for problem resolution
• Reimbursement for vendor or outsourcer equipment defects, software outages or failures
• Backup and recovery services
• Offsite fallback configuration
• On-demand peak workload capacity
• Operational assistance
• Security services implementation, investigation, identification and restoration
• Customer satisfaction facilitation and administration
• Software distribution

The list goes on, based on need.

Compliance Must Be Measured  

For an SLA to be effective, the service levels it monitors must be measureable, so those services must have characteristics that are quantifiable. Sometimes, such as with response time and availability, the measurement is time—seconds, hours or days. Others, like capacity or bandwidth, are measured in utilization percentage. For application programming, metrics like number of defects or program pathlengths are quantifiable, and for security metrics, items like number of attempted and successful breaches, antivirus currency, and patching can be tracked. Some research may be needed by both parties, but metrics for virtually any service can be identified and implemented.

Negotiating an SLA  

Negotiating an SLA is similar to bargaining in any other business transaction, and the first step is to become thoroughly prepared to discuss any topic. A good place to start is to survey involved departments and IT technical staff, document and quantify concerns, and prioritize issues in monetary terms and impact. Solicit documentation, compare proposals and do thorough background investigations on bidders whose proposals are under consideration. Rank applicants based on cost/benefit analysis, and schedule interviews with the top competitors.
 
Then it’s time for face-to-face discussions with contenders, preparing for the meetings by organizing the information to be easily accessible, then comparing concerns and opinions with key IT technicians, decision makers, and end users. It’s vital that end users be equal participants, because that engenders a sense of ownership on their part, and the mutual support creates a strong commitment to success. The best decision is one that all parties support, which will no doubt require some give and take, but the result will be a team effort strong enough to overcome the rough spots that will inevitably occur.

An SLA May Require Changes 

It’s very likely system and structural changes will be needed to implement an SLA, such as creating a full- or part-time administrative position to manage the SLA and interface to the SLA vendor. Software may be needed to monitor, collect, store and report necessary metrics and are also extremely useful when it comes to finding bottlenecks, balancing resource consumption, and other tuning. They may also reveal previously undetectable system defects and provide analytic tools that evaluate performance in new ways—such as online monitoring and graphical analysis—that provide deeper understanding of system characteristics and archival facilities that reveal historical trends.

SLAs Eliminate Ambiguity and Confusion 

An SLA is a way of formalizing performance expectations, of revealing needs and identifying performance obstacles—not only in computer systems and application processes, but also in how people use those systems and strive to satisfy their customers. An SLA is, in a sense, a health checkup for the entire organization. It streamlines processes involved when something goes wrong, precludes misunderstandings and greatly improves all parties’ knowledge of the mechanisms that drives their business. It’s an evolution of the business world to enhance the mechanisms of business processes.

---