---

CHAPTER 14

Service-Level Agreements

In this chapter, you will learn about

• The role of service-level agreements (SLAs)

• How SLA requirements are discovered

• What to include in an SLA

• Service-level targets that pertain to networked AV systems

---

In this chapter, you will become versed in a decidedly IT practice for documenting the design, performance, and maintenance of networked systems: the service-level agreement (SLA). AV and IT professional have established methods of discovering and documenting end user needs. When AV systems touch the enterprise network, AV service providers need to be able to function within the established IT framework.

Learning about SLAs and the overall IT documentation processes will help you better understand existing network documentation, capture realistic system needs and expectations, and identify early any potential conflicts between your system needs and network policies.

Put simply, there will be less conflict between system designers and network managers if they’re speaking the same language.

Get Acquainted with Service-Level Agreements

Implementing a networked AV system requires a high level of coordination—and perhaps even negotiation—among IT and AV service providers. Everyone has to work together to ensure the customer gets a system that meets their needs, at an acceptable quality level, and for an acceptable price.

In order to be successful, stakeholders need to agree on such things as which ports will be opened, which protocols allowed, and how access control will be managed. They must also set performance targets, guaranteeing a certain level of uptime, latency, and available bandwidth. Ultimately, service providers (AV and IT) and end users must have a shared understanding, given network and organizational constraints, of what level of networked AV system performance quality they can expect. In other words, for example, will the video calls that ride the organization’s network look great, or good enough? All the communication and compromise that go into addressing such expectations are necessary, but they mean little if they aren’t documented and enforced.

Traditionally, the AV industry has documented user needs and expectations in a program report. Requirements for network services are documented in a somewhat more formal, technical document called a service-level agreement (SLA).

 

---

NOTE As you will recall from Certified Technology Specialist (CTS) prep, a program report is a document that describes the client’s specific needs, a system’s purpose and functionality, and the AV designer’s best estimate of probable cost—in a nontechnical format—for review and approval by the owner. It’s also known as the AV narrative, discovery phase report, return brief, or concept design report.

To review, a program report, something rooted in the architecture field, is written after completing a needs analysis, which includes one or more program meetings. Ideally, a program meeting includes the system owner, end users, and all design team members, including architects, AV designers, HVAC engineers, network service providers, and interior designers. The purpose of the program meeting is to discover what the customer wants to do in the space where an AV system will be installed, and how they want to do it. The meeting also provides an opportunity for design team members to discuss how aspects of the project will impact one another.

 

---

NOTE An SLA is used to document agreements between an IT service provider and a customer. It describes the services to be provided; documents service-level targets; and specifies the roles and responsibilities of the service provider(s) and the customer(s). An SLA may cover one service or many, and may apply to one customer or many.

The formal SLA discovery and documentation process is defined by the Information Technology Infrastructure Library (ITIL). The ITIL is an IT management best practice framework, developed on behalf of the government of the United Kingdom, which has become the de facto standard for IT industry documentation.

Traditional AV system design focused heavily on the physical space—where the system would be used. The approach to discovering and documenting user needs reflects this focus, and the program report is still the best tool for capturing the required functions, features, endpoints, and devices of individual rooms and AV systems.

That said, the physical space is just one part of a networked AV system: the bottom layer (see Figure 14-1). Often, networked system users aren’t tied to any physical space. Their display is their laptop or cell phone; their viewing environment is their hotel room. An SLA is designed to capture requirements, responsibilities, and points of conflict at every layer of the OSI model. That’s why it’s the better tool for capturing the network requirements of the AV system.

 

---

NOTE For more information about program reports, the InfoComm Standard ANSI/INFOCOMM 2M-2010 Standard Guide for Audiovisual Systems Design and Coordination Processes describes the contents of the traditional AV program report and program phase in detail.

SLAs Set Expectations

Here’s a hypothetical situation. You’re getting ready to install a new networked AV system and attempting to gauge your customer’s expectations. Casually, you ask the following questions. Just as casually, the customer answers.

Q: How often do you expect the system to work perfectly?

A: All the time.

Q: How long do you expect the system’s functionality to last?

A: Forever.

Q: How much loss of speed or quality would be acceptable during peak usage?

A: None.

Q: Whose fault would it be if the system stopped working?

A: Yours, of course.

Q: How soon would you need the system to be fixed if it stopped working?

A: Yesterday.

Unreasonable, you say? Perhaps, but we probably don’t need to tell you that it’s the default mind-set of many customers. To its credit, the AV industry has learned to be very responsive to customer demands. Problems happen, and leading AV firms know high-quality, professional service plays a big role in earning follow-on business and valuable referrals. If something is perceived as a flaw in an AV service or system, the typical AV pro leaps to fix it—whether or not the flaw is within his control.

This state of affairs cannot continue indefinitely, especially when it comes to networked AV systems. Not only do networks introduce a fresh set of variables that could impact service, they also usually involve another separate set of professionals (the IT staff) whose job it is to monitor service throughout a network—and your AV system is just one part of that network. You don’t want a customer who gets fed up with a system’s failure to meet expectations; and you don’t want to find yourself unable to keep up with the customer’s demands. At some point, you must address, define, and document the availability, quality, and speed of service your networked AV system will provide. You also need to spell out a process by which failures will be addressed. That way everyone is (contractually) on the same page.

 

---

TIP The SLA embodies a revolutionary concept for the AV industry: the customer is not always right. Both the customer and the service provider (you) must be protected from unreasonable expectations, or everyone will end up angry, broke, or both.

Service Providers

Service providers don’t have to be contractors who operate independently of a customer. When it comes time to craft an SLA, it’s important to know who might have input and who might be crafting their own SLA in parallel. There are three main levels of service providers:

• Type I, internal service providers, work within a single business unit, such as the training or the sales department. Even small to medium-sized organizations may employ several Type I service providers.

• Type II, shared service providers, are internal service providers that provide services to several business units. For example, they may respond to help desk tickets or maintain the contact management system for an entire enterprise.

• Type III, external service providers, exist independently from their customers and provide services by contract.

You may even have all three in your own home. A teenager who troubleshoots only the entertainment system would be a Type I provider. A spouse who makes repairs to whatever breaks around the house would be Type II. A roofer hired to repair a leak would be Type III. Most organizations utilize some combination of all three types of service providers, and all three may require input into the organization’s various SLAs.

Types of Service-Level Agreements

An SLA may cover one service or many; it may cover one customer or many (see Figure 14-2). If you’re asked to draw up an SLA for your networked AV system, understand which type you need.

• Service-based SLAs cover one service, for everyone who uses that service. They are used when all customers have similar needs and access to the same infrastructure. Service-based SLAs may also use multiple classes of service to differentiate between customers with different needs or access (think of your broadband service, which you could speed up if you paid for a higher service tier). In general, a service-based SLA offers fixed levels of service to a wide range of users—standardized services offered at standardized prices.

• Customer-based SLAs cover all the services provided to a particular group or business unit. They are used when a single department requires several related or interdependent services. Clients often prefer them because they keep everything in one place. Customer-based SLAs offer services that are specific to the customer’s needs, and they are not necessarily transferable to another class of customers. AV professionals may be asked to contribute details to a customer-based SLA that cover the performance of a networked AV system.

• Multilevel SLAs are used by large enterprises with complex needs. They may include one set of SLAs that apply to the whole enterprise, a set of customer-based SLAs detailing the services provided to particular departments, and a set of service-based SLAs defining unique services.

Choose the type of SLA best suited to the nature of the customer, service provider(s), and service(s) involved.

Discovering SLA Requirements

As mentioned earlier, the process of producing an SLA is similar to the process of producing a program report. There is a round of meetings including all system stakeholders. The purpose of the meetings is to discover user needs and determine how they will be supported.

What makes the SLA process different is the focus on measurability at every stage. All parties to the eventual SLA must continually ask, “How can it be measured?” The process goes a little like this:

• What does the user need to do to use the system...and how can you measure how often the task is done or how well the services support it?

• What service targets do providers need to meet to support the systems…and how will those targets be measured?

• Who is responsible for providing each service…and who will measure and report on each service?

• Once the system is running, how often will its performance be measured...and who will see the reports?

• What do the measurements tell you about the success of the system...and the accuracy of your targets?

Let’s look more closely at the five stages of the SLA process, as shown in Figure 14-3.

• Stage 1: Needs analysis At this stage, service providers, including AV professionals, work with the customer, especially end users, to discover exactly what they need the system or service to do. What business process is the customer hoping to improve? The service provider then identifies which systems or services would best help the customer accomplish their goals. Finally, the service provider identifies the devices, functionality, and infrastructure required to achieve the user’s goal. If the customer needs to collaborate better, a videoconferencing system may be in order. And if the customer has offices overseas, the system may need to traverse the Internet.

• Stage 2: Service-level target negotiations Next, service providers and customers work together to identify achievable service-level targets for the requirements discovered during the needs analysis. How much latency will the customer tolerate from that videoconferencing system? All targets should be objectively measurable. Each target should include provisions for how and when it will be measured, and you should plan for test measurements in order to validate targets and confirm measurement capabilities. At this point a draft SLA, which defines the services, targets, and measurement and reporting procedures, is normally produced.

• Stage 3: Assignment of roles and responsibilities Now is the time for service providers and customers to determine who will be responsible for every task in the SLA. Clearly define the responsibilities and expectations for both internal and external service providers. If Type III service providers will be involved, now is the time to determine pricing structures. Once complete, the appropriate customer and service provider representatives sign the SLA.

• Stage 4: Measurement and enforcement of the service-level targets Everything agreed to in the SLA should be measurable. The measurement methods should have been tested during stage 2 and should reflect the way the customer perceives the service. Once the SLA has been signed, target performance levels should be measured as agreed upon. In the beginning, it’s a good idea to produce operational reports weekly. And remember, if there are any problems, customers are also responsible for reporting them in a timely fashion.

• Stage 5: SLA review SLAs are not guarantees. Performance targets may change over time due to fluctuating budgets and emerging customer needs. The team should hold regular review meetings to discuss performance and problems, and to make any necessary changes to the SLA. Operational reports should be aggregated into an interim report that can be circulated a few days before a review. This report shows the service-level targets, the service levels actually achieved, and any steps being taken to improve performance. The review meeting is the time to discuss any incidents that fall short of the SLA and to determine what caused them and how to prevent them from recurring. Don’t forget to ask the customer about future needs—or changes in the way users operate the systems and service—that may require changes to the service and the SLA. If necessary, set new service targets and revise the SLA, making clear what new actions are the responsibility of the customer and/or the service providers.

The AV Pro’s Role in an SLA

You may be wondering about the role of an AV professional in the SLA process. Should you be writing these documents? Signing them? Developing specifications for them? It depends. An AV professional can assume many different roles in the SLA process, as shown in Figure 14-4.

In many cases, an AV professional’s role with respect to the SLA will be that of an end user rather than a service provider. The AV systems use the same network services as the enterprise’s other data. In this case, your role in the SLA process is to make sure the service targets meet the AV systems’ needs and to raise potential issues. You need to be sure that the customer’s SLAs can support the networked AV system. For example:

• Does the ISP guarantee adequate bandwidth and latency on the WAN?

• Does the data storage service provider offer adequate storage, backup, and redundancy for AV media?

• Will you have access to the network metrics you need in order to troubleshoot networked AV devices?

If, however, you provide any hosted AV services, then you may be the customer and signatory on SLAs for the services you need to support the hosting effort. If you host VOD content, for example, you may be the customer on an SLA, with the ISP guaranteeing adequate bandwidth, latency, QoS, availability, and access to the storage for your customers.

In some cases, you or your organization, as a service provider, will write and sign an SLA. If you offer ongoing support, content development and/or propagation, or remote monitoring services, those services should be defined in an SLA. Documenting your service’s functions and requirements in an SLA helps ensure that they are taken into account as changes are made to the network.

Components of a Service-Level Agreement

An SLA’s length and level of detail varies according to the complexity and importance of the system or service. But there are certain elements that every SLA—large or small—should include.

• Parties to the agreement The SLA requires input from and detail about the expected actions of several different parties. All the people who weigh in on the definition of services should be listed at the beginning of the SLA. Try to list actual individuals rather than titles or groups; eventually, someone will have to sign the SLA.

• Detailed definitions of the services to be provided The definition of services makes up the bulk of the SLA, and it’s the hardest part to pin down. The SLA should identify all the services that go into creating and supporting a successful system. It should also dig deep into what demands users will place on the services and define the services in terms of measurable outcomes.

• Roles Who is responsible for providing each service, and if applicable, how much will they be compensated for doing so? Note that compensation, if listed, shouldn’t be an estimate of probable cost, but a true chargeback system. The customer gets what they pay for.

• Monitoring procedures The SLA should spell out how and when information about service performance will be gathered and who will monitor that information. Monitoring is central to SLA enforcement. It also creates a historical record that all parties can use to write better SLAs in the future, allows service providers to assess charges to the customer, and helps maximize resource usage and plan for the future.

• Renegotiation date SLAs should be revisited at least once a year to make sure they still accurately capture customer needs and expectations. In reality, they probably need to be examined more often, especially when it comes to new systems. If your service definitions are significantly out of sync with actual monitored usage and performance for more than a month or two, get back to the negotiating table immediately.

The next section details everything that could go into an SLA, along with everything that should be included.

SLA Template

What follows is a sample SLA template. It contains a list of information you should consider including in your SLA. Not every SLA needs to include all the information listed, however. The actual contents of an SLA will be determined by the project at hand.

Areas of AV Focus in an SLA

Whether you’re involved in an SLA as a service provider, customer, or end user, you should have input on the service-level targets that affect your system. For networked AV systems, bandwidth, quality of service, and latency will be significant concerns. The AV professional should be directly involved in discussions about how those three factors will be reflected in an SLA, especially as they pertain to the AV system.

Bandwidth

As a reminder, AV professionals may think of bandwidth in terms of hertz, but in this case we’re talking about data throughput, measured in bits per second. Network traffic—especially Internet traffic—is “bursty.” Even if on average you’re using only half your network capacity, at peak traffic times the pipe can still get very full. There has to be enough bandwidth to withstand peak traffic onslaughts, such as when a whole office needs to stream a video presentation from the CEO (or during the lunch hour, when workers relax to YouTube videos or burnish their skills viewing online training).

You should specify no more than 50 percent of a network’s ready capacity for average use. Understanding how much bandwidth is available to your AV system will factor into any SLA covering that system. (And, to be fair, the bandwidth requirements of your networked AV system could possibly affect the SLA for other network applications.)

In order to determine how much bandwidth you’ll need to achieve an acceptable level of service, there are a host of application-specific considerations. For instance, in video streaming applications, what is your desired resolution? How many channels will the system stream and how many will users typically watch concurrently? All of this was compiled in your needs assessment and is reflected in your system design. It now needs to be incorporated in the SLA. Refer to the networked device inventory you created (see Chapter 9), which should describe the functionality of all networked AV devices and list peak and average throughput rates for each.

 

---

TIP When detailing bandwidth requirements for an SLA, remember all possible bottlenecks. The LAN is faster than the WAN, and some networked AV systems, such as a videoconferencing system, may need to traverse both. One of your earliest steps in identifying usage targets for the SLA is to pinpoint the speed of the WAN. As much as possible, optimize your system design to keep high-bit-rate traffic within the LAN and minimize the number of high-bandwidth streams that must be sent over the WAN.

Quality of Service (QoS)

QoS helps a network decide what data to throw away or delay if bandwidth runs out (see Chapter 5 for a review of QoS and differentiated service). For on-demand AV applications, you may be able to get away with letting the audio and video buffer or download a little at a time through whatever bandwidth is available. For interactive applications, this won’t work. If you’re transporting data by UDP, not having enough bandwidth will destroy a stream’s quality. QoS is critical to any interactive or streaming data application, including conferencing, voice over IP (VoIP), and video streaming.

During the needs assessment, you should determine how important AV data delivery is to the customer’s enterprise. Is it more important to some users than others? What other data is of a higher priority than the audio and video streams?

Then you will have to work with the customer’s network manager or IT service provider to determine how classes of service are defined on the network. The network manager may expect you to assign a class of service for AV data. If so, consider whether timeliness, detail and quality, or reliable delivery best supports the client’s need. If the network manager will assign the class of service for you, work with her to determine what information she needs to assign the right class to your AV systems.

If the customer and/or the customer’s network manager choose not to allocate adequate bandwidth for guaranteed delivery, or they insist on assigning AV traffic to a low QoS class, they must acknowledge in the SLA that lower quality and higher latency may result.

Latency

Latency is the response time of the network. It’s expressed as the amount of time (in milliseconds) between the time an application transmits a data packet and the time it’s presented to the user at its destination.

For many applications—interactive ones especially—latency has a powerful, direct impact on the quality of the user’s experience. Too much latency results in packet loss, reordering, and jitter. Several factors affect how much latency is inherent in a network, and these factors therefore need to be reflected in the SLA. When evaluating latency targets for an SLA, particularly as they apply to networked AV systems, consider the following:

• QoS works by prioritizing some network traffic over others, and different kinds of traffic may have differing latencies.

• Because packet shaping works by buffering content, it may increase latency.

• TCP signal transportation resends dropped packets, which means no information is lost. However, resent packets can increase latency.

• At the Presentation Layer, encoding and decoding AV signals introduces some latency into the system. If the signals need to be encrypted, the encryption and decryption processes also take time.

When it comes to conferencing systems, low latency requirements are a given. But determining latency requirements for other streaming applications can be nuanced. In the end, it comes down to what the user wants to do with the system. IPTV can tolerate a lot more latency than emergency notification, for example. No one cares if they’re watching Dr. Phil 7 seconds out of sync, but if the building’s on fire, they need to know right now.

Packet Loss

Packet loss occurs when some of the data traveling over the network fails to reach its destination. Several issues can cause packet loss: lack of bandwidth, signal degradation, faulty hardware, and incorrect configuration, among others.

Packet loss is perhaps the most difficult service target to pin down. Ideally, you want all the network data to reach its destination. In reality, however, customers are rarely willing to commit the infrastructure required to provide guaranteed delivery of all AV traffic.

In the SLA, the packet loss target may need to state harsh facts. You need to determine how many packets your application can be expected to drop given the network environment. This entails

• Calculating the application’s peak and average bandwidth consumption

• Comparing the application’s bandwidth requirements to peak and average available throughput in the application’s traffic class

• Assessing the impact of dropped packets on quality

• Reserving bandwidth or reducing the application’s scale, if necessary

Determining a packet loss target is a balancing act between the customer’s expectation of quality and the sheer expense—in terms of equipment, bandwidth, and network configuration—of ensuring packet loss doesn’t occur. If you can’t reserve the required bandwidth, strive to set the customer’s expectations accordingly. If the customer finds the agreed-upon packet loss target unacceptable, then he can’t say he wasn’t warned. Setting realistic packet loss expectations increases the odds that the customer will come to you when it’s time to upgrade the system.

Chapter Review

Be aggressive about getting involved in the service-level agreement process. For existing networks, thoroughly review the existing SLAs and raise potential conflicts or shortfalls early. For new networks, work with the customer and network manager to get a seat at the table during SLA meetings, when service targets are defined.

Consider using a separate SLA to define the targets for your networked AV system. Remember, it can be as formal and detailed, or as informal and brief, as the situation demands. The most important aspect is ensuring that service targets are consistently measured and reviewed after implementation. That way, the system and your relationship with your customer can be continually improved.

Now that you’ve completed this chapter, you should be able to

• Define the concepts of service, service provider, and service-level agreement

• Describe the process of discovering, documenting, and reviewing the SLA requirements relating to your projects

• Identify the information that should be included in an SLA for a given project

• Describe the basic considerations for identifying bandwidth consumption, QoS, latency, and packet loss service targets

Review Questions

1. The formal service-level agreement (SLA) discovery and documentation process is defined in the _____.

A. Information Technology Infrastructure Library (ITIL)

B. ANSI/INFOCOMM 2M-2010 Standard Guide for Audiovisual Systems Design and Coordination Processes

C. Open Systems Interconnection (OSI) model

D. Program report

2. What type of service provider operates independently from its customers and offers services on a contract basis?

A. Type I

B. Type II

C. Type III

D. Type IV

3. True or false? An SLA might document a networked AV system’s limitations.

A. True

B. False

4. At which stage of the SLA life cycle should you take test measurements to validate service targets and confirm measurement capabilities?

A. Needs analysis

B. Service-level target negotiations

C. Assignment of roles and responsibilities

D. Measurement and enforcement of the service-level targets

E. SLA review

5. Which of the following should always be included in an SLA? Choose all that apply.

A. Responsibilities

B. Service descriptions

C. Change procedures

D. Service limitations

E. Points of failure

6. Customers are ____ willing to commit the infrastructure required to provide guaranteed delivery of all AV traffic.

A. always

B. usually

C. rarely

D. never

7. If a customer insists on assigning a low QoS class to AV network traffic, the AV professional should _____.

A. make a better case for a higher QoS class

B. propose alternate solutions for ensuring a high level of networked AV performance

C. make sure the customer acknowledges the possibility of lower AV quality in the SLA

D. not sign the SLA

Answers

1. A. The formal service-level agreement (SLA) discovery and documentation process is defined in the Information Technology Infrastructure Library (ITIL).

2. C. A Type III service provider operates independently from its customers and offers services on a contract basis.

3. A. True. Documenting a system’s limitations sets expectations and may lead to future upsell opportunities.

4. B. During service-level target negotiations, you should take test measurements to validate service targets and confirm measurement capabilities.

5. A, B. An SLA should always include sections for responsibilities and service descriptions. Sections for change procedures, service limitations, and points of failure may also be included, depending on the system and the circumstances, but they are not always required.

6. C. Customers are rarely willing to commit the infrastructure required to provide guaranteed delivery of all AV traffic.

7. C. If a customer insists on assigning a low QoS class to AV network traffic, the AV professional should make sure the customer acknowledges the possibility of lower AV quality in the SLA.