Service Level Agreements White Paper - A Summary

1
Service Level Agreements White Paper - A Summary

• Quality of Service Task Force
• The Open Group
• Presented by Jon Saperia
• saperia_at_jdscons.com

2
Presentation Overview

• Focus of presentation is on discussion points -
  not the raw data in the white paper.
• Survey Methodology.
• What we learned and should investigate further
• About the importance of services and SLAs.
• SLA metrics management.
• Marking and measurement.
• Organizational issues.
• Other areas for study.
• Concluding thoughts and Discussion.

3
Survey Methodology

• Goals
• What is a service and an SLA
• How important are they to enterprises
• What technologies do they use to mark, measure,
  manage and control them
• Lean about inter and intra-organizational issues
  as they relate to SLAs
• What can the Open Group do to contribute - what
  needs to be done
• Web-based questionnaire
• Telephone follow-up

4
Services and SLAs What we Learned

• General consensus about what an SLA is.
• Strong agreement about the central role of
  services and SLAs.
• If a service is important enough to be deployed,
  it is important enough for an SLA.
• There is no dominant technology used for SLAs -
  it is probably too soon. People use what they
  have.

5
Services and SLAs Whats Next

• Form of the SLAs - are there opportunities to
  create a standard for high-level network
  services? Is this desirable?
• What would enterprises want from a technology to
  help with SLAs in their network environment?
• To what extent does the management software
  problem inhibit new services?
• Are there trends for technologies for services
  and can the Open Group help codify these? For
  example using one or more technologies to deliver
  VoIP.

6
Services and SLAs Whats Next Continued

• SLAs are more useful by traffic or application
  type yet many do not have this ability. We
  should investigate further the cost/benefit of
  technology deployment to meet this need.
• Definition of terms used with technologies used
  for SLAs mean different things for users and
  technologists. We need to better understand terms
  like marking and metering so that SLAs can be
  more accurately written.

7
SLA Metrics What we Learned and Whats Next

• There is consensus about what happens (versus
  what should happen) when an SLA is met or not
  met.
• No clear metrics about what should be used for
  specific services
• Range of services is broad. Is there a list of
  high-level services that are emerging for which
  standard metrics might be useful?

8
SLA Management What we Learned

• Management is really a problem. There are too
  many non-integrated pieces. This makes it hard
  to provision and monitor services and their SLAs.
• Even basic data is not as available as people
  would like.
• Much of the data that is collected is collected
  via manual means such as web forms that users
  fill out to describe their (dis)satisfaction with
  services.

9
SLA Management Whats Next

• How to increase the availability of management
  statistics such as latency, MTBF. Less than half
  the respondents had what they wanted.
• How to create standardized metrics and values
  for different high level services so that more
  effective SLAs can be written.
• Determining what factors about extant management
  software are so inadequate and creating an
  industry RFI to describe what is needed by the
  enterprises.

10
Marking and Measurement What we Learned

• Few companies mark traffic using any of the
  newer technologies like DiffServ.
• URL identification is most common. Most often
  certain Web pages go to dedicated servers.
• Marking and measurement are terms that users and
  technologists use differently. They most often
  mean dedicated resources are assigned to specific
  traffic.

11
Marking and Measurement Whats Next

• 77 of the respondents indicated that they did
  not mark traffic
• Was it not needed?
• Too expensive?
• Too difficult to deploy?
• Used unknown technologies?
• How does this square with large percentage that
  said they would mark in the next 12 months?

12
Organizational Issues What we Learned

• Many of the same concerns/justifications for SLAs
  within an organization are similar to those when
  the SLA is provided by a service provider.
• Some telephone respondents indicated internal
  SLAs help justify department budgets and keep
  work inside rather than being outsourced
• Organizations that look at the infrastructure as
  a cost center and not a competitive advantage
  seem to outsource more.
• Those that see infrastructure as key and a
  competitive advantage use internal resources for
  internal SLAs

13
Organizational Issues Whats Next

• What are the types of SLAs enterprises would like
  to have with their customers - the most often
  cited external organization that would have an
  SLA
• Can service providers bridge the trust gap and
  offer more services, what do they need to do
• With 73 reporting that personnel consequences
  can be the result of a failed SLA, there seems to
  be an incentive not to offer strong agreements

14
Other Areas for Study Whats Next

• Collect more data from the doers rather than the
  managers - this might change some of the
  responses
• An economic look at over-provisioning versus new
  technologies like DiffServ?
• Application-specific information was highly
  valued but not widely available
• What applications are of concern
• What application specifics are needed for each
  application

15
Other Areas for Study - Continued

• What are the economic factors that would cause a
  migration from over-provisioning to technologies
  that prioritize resource utilization
• Security was described as a concern in some
  telephone responses. What are the specific
  security concerns for both internal and external
  SLAs.

16
Concluding Thoughts

• SLAs are becoming ubiquitous - help organization
  manage internal agreements
• SLAs are key to the functioning of many
  enterprises
• SLAs between enterprises and their service
  providers are also now common, many have real
  teeth
• SLAs are not dependent on technology, though
  technology can help.
• Over-provisioning rules

17
Concluding Thoughts - Where to Improve

• Enterprises care deeply about how well the
  services and SLAs for them are functioning but
• New technologies are not being adopted at a high
  rate
• Manual methods of service verification still
  dominate
• We have a long way to go to understand how to
  write and manage SLAs in an efficient manner -
  much more work to be done.
• We have work to do in the area of basic
  definition of terms.

18
Discussion Topics

• Other analysis of the survey
• Where do we go from here