MS thesis

UNIVERSITÀ DEGLI STUDI DI PAVIA
FACOLTÀ DI INGEGNERIA
CORSO DI LAUREA SPECIALISTICA IN INGEGNERIA DEI SERVIZI
OPTIMAL RESOURCE ALLOCATION FOR B2B
NETWORK SERVICES:
A SERVICE PROVIDER PERSPECTIVE
TESI DI LAUREA DI
LUCA MATTIA FERRARI
RELATORE
PROF. GIANMARIO MOTTA,
UNIVERSITÀ DEGLI STUDI DI PAVIA
CORRELATORE
PROF. SUBODHA KUMAR,
UNIVERSITY OF WASHINGTON
ANNO ACCADEMICO 2007-2008

i
Table of Contents
ABSTRACT........................................................................................................................................2
1 INTRODUCTION......................................................................................................................2
1.1 MANAGING SERVICE LEVELS...........................................................................................................................................2
1.2 DEFINITIONS OF SERVICE LEVEL MANAGEMENT..........................................................................................................3
1.2.1 Elements of Service Level Management...................................................................................................................5
1.2.1.1 Service Level Agreements....................................................................................................................................5
1.2.1.1.1 Structure of SLAs............................................................................................................................................7
1.2.1.1.2 SLA lifecycle ................................................................................................................................................11
1.2.1.2 Operational Level Agreements...........................................................................................................................14
1.2.1.3 Underpinning Contracts .....................................................................................................................................15
1.2.1.4 Reporting............................................................................................................................................................15
1.2.1.5 Service catalogue................................................................................................................................................16
1.2.1.6 Technology and toolsets.....................................................................................................................................18
1.2.2 The benefits of Service Level Management ..........................................................................................................19
1.2.2.1 Quantifying the benefits of Service Level Management ....................................................................................20
1.2.3 Current service management problems ................................................................................................................23
1.3 SLA METRICS...................................................................................................................................................................26
1.3.1 Business & IT alignment..........................................................................................................................................27
1.3.2 Metrics are not SLAs................................................................................................................................................30
1.4 RESEARCH OBJECTIVES & KEY FINDINGS.....................................................................................................................32
2 LITERATURE REVIEW .......................................................................................................34
3 PROBLEM DESCRIPTION & MODEL ..............................................................................36
3.1 QOS AND SERVICE DIFFERENTIATION...........................................................................................................................36
3.1.1 Best Effort Service ....................................................................................................................................................37
3.1.2 Integrated Services...................................................................................................................................................37
3.1.3 Differentiated Services.............................................................................................................................................39
3.2 SELF-SIMILARITY IN TELECOMMUNICATION................................................................................................................42
3.2.1 Using Fractional Brownian Motion in self-similarity modeling......................................................................44
3.3 RELIABILITY ENGINEERING............................................................................................................................................48
3.4 NETWORK MODEL............................................................................................................................................................54
3.5 PROFIT MODEL..................................................................................................................................................................55
3.6 REVENUE MODEL.............................................................................................................................................................56
3.6.1 Usage-based pricing................................................................................................................................................56
3.7 COST MODEL.....................................................................................................................................................................57
3.7.1 Performance cost ......................................................................................................................................................57
3.7.2 Availability cost.........................................................................................................................................................58
3.7.3 Fixed cost...................................................................................................................................................................59
3.8 OPTIMIZATION PROBLEM................................................................................................................................................59
4 SOLUTIONS AND RESULTS ...............................................................................................60
4.1 CLASSIFICATION OFTHE PROBLEM................................................................................................................................60
4.2 PATTERN SEARCH ALGORITHM......................................................................................................................................62
4.3 PARAMETERS SETTINGS ..................................................................................................................................................65
4.4 SENSITIVITY ANALYSIS...................................................................................................................................................66
4.4.1 Parameters Qperf, Qavail.............................................................................................................................................67
4.4.2 Parameter pmM ........................................................................................................................................................70
4.4.3 Parameters crouter, cswitch...........................................................................................................................................72
4.4.4 Parameter A...............................................................................................................................................................74
4.4.5 Parameter TSLA ..........................................................................................................................................................76
4.5 OVER-PROVISIONED CASE ..............................................................................................................................................77
4.6 UNDER-PROVISIONED CASE............................................................................................................................................84
4.7 FLAT-RATE PRICING.........................................................................................................................................................88
4.8 BUFFER VARIABLES.........................................................................................................................................................90
4.9 AVAILABILITY MODE.......................................................................................................................................................95

ii
4.10 PENALTY MODES..............................................................................................................................................................98
4.11 PERFORMABILITY ANALYSIS........................................................................................................................................105
5 CASE STUDY ........................................................................................................................108
6 DISCUSSIONS & MANAGERIAL INSIGHTS.................................................................111
7 CONCLUSIONS & FUTURE RESEARCH DIRECTIONS.............................................113
8 REFERENCES.......................................................................................................................115
Index of Tables
Table 1: Problem parameter values....................................................................................................66
Table 2: Qperf and Qavail variation.......................................................................................................67
Table 3: pmM variation......................................................................................................................70
Table 4: crouter and cswitch variation......................................................................................................72
Table 5: A variation ...........................................................................................................................74
Table 6: TSLA variation.......................................................................................................................76
Table 7: Real Time traffic load variation...........................................................................................78
Table 8: Mission Critical traffic load variation..................................................................................78
Table 9: Best Effort traffic load variation..........................................................................................78
Table 10: Single CoS variation ..........................................................................................................81
Table 11: a and H variation................................................................................................................82
Table 12: Under-provisioned case variation ......................................................................................84
Table 13: Single CoS under-provisioned case variation....................................................................86
Table 14: Flat rate pricing variation...................................................................................................88
Table 15: Buffer variables variation ..................................................................................................91
Table 16: Redundant architecture variation.......................................................................................95
Table 17: Proportional penalty variation ...........................................................................................99
Table 18: Exponential penalty variation ..........................................................................................102
Table 19: Performability variation...................................................................................................106
Table 20: Case study traffic classification .......................................................................................108
Table 21: Case study self-similar parameters ..................................................................................108
Table 22: Case study variation.........................................................................................................109
Index of Figures
Figure 1: Achieving end-to-end guaranteed service levels might be hard...........................................3
Figure 2: Example of an SLM framework (ITILv3)............................................................................5
Figure 3: Role of the SLA....................................................................................................................6
Figure 4: SLA lifecycle......................................................................................................................11
Figure 5: Relationship between SLA, OLA and UC .........................................................................15
Figure 6: Example of SLA violation report .......................................................................................16
Figure 7: Service portfolio (ITILv3)..................................................................................................17
Figure 8: Types of service provided by an IT enterprise (ITILv3) ....................................................18
Figure 9: SLM may help identify sooner the causes of outages (ITILv3) .........................................21
Figure 10: SLM can help identify the best solution for service restoring (ITILv3) ..........................22
Figure 11: Metrics chain ....................................................................................................................30
Figure 12: Metrics process flow chart ...............................................................................................31
Figure 13: RSVP and IntServ ............................................................................................................39
Figure 14: DiffServ............................................................................................................................42

iii
Figure 15: Required link capacity (Y axis) as a function of a (X axis) with m = 2 Mb/s and H = 0.5,
0.7, 0.9................................................................................................................................................48
Figure 16: Failure function ................................................................................................................49
Figure 17: Reliability function...........................................................................................................50
Figure 18: Operating profile ..............................................................................................................51
Figure 19: Series configuration..........................................................................................................52
Figure 20: Parallel configuration .......................................................................................................53
Figure 21: Availability as function of reliability, maintainability and supportability .......................54
Figure 22: Network architecture of the model...................................................................................55
Figure 23: Problem classification tree ...............................................................................................62
Figure 24: Two iterations of pattern search algorithm.......................................................................62
Figure 25: Steps too long...................................................................................................................63
Figure 26: Steps too short ..................................................................................................................64
Figure 27: Qperf profit variation..........................................................................................................68
Figure 28: Qperf variables variation....................................................................................................68
Figure 29: Qavail profit variation.........................................................................................................69
Figure 30: Qavail variables variation ...................................................................................................69
Figure 31: pmM profit variation ........................................................................................................71
Figure 32: pmM variables variation...................................................................................................71
Figure 33: crouter and cswitch profit variation ........................................................................................73
Figure 34: crouter and cswitch variables variation...................................................................................73
Figure 35: A profit variation..............................................................................................................75
Figure 36: A variables variation.........................................................................................................75
Figure 37: TSLA profit variation .........................................................................................................76
Figure 38: TSLA variables variation....................................................................................................77
Figure 39: Profit variation, system highly loaded..............................................................................78
Figure 40: Profit final values .............................................................................................................79
Figure 41: Percentage of allocated bandwidth variation....................................................................79
Figure 42: Network components variation ........................................................................................80
Figure 43: Profits for one CoS model................................................................................................81
Figure 44: Number of network components with one class of traffic ...............................................82
Figure 45: Profit variations, a and H parameters ...............................................................................83
Figure 46: Number of network components, a and H variations .......................................................83
Figure 47: Profit variation from over to under-provisioned case ......................................................85
Figure 48: Number of network components from over to under-provisioned...................................85
Figure 49: Profit variation one CoS from over to under-provisioned case........................................86
Figure 50: One CoS under-provisioned case final profit ...................................................................87
Figure 51: One CoS network components variation from over to under-provisioned ......................87
Figure 52: Profit variation, flat rate pricing .......................................................................................89
Figure 53: Bandwidth allocation, flat rate pricing.............................................................................89
Figure 54: Profit variation for the three CoS, buffer variables ..........................................................92
Figure 55: Profit final values, buffer variables ..................................................................................92
Figure 56: Bandwidth allocation, buffer variables ............................................................................93
Figure 57: Network components variation, buffer variables .............................................................93
Figure 58: Buffer allocation, buffer variables....................................................................................94
Figure 59: Profit variation, redundant architecture ............................................................................96
Figure 60: Profit final values, redundant architecture .......................................................................96
Figure 61: Bandwidth allocation, redundant architecture ..................................................................97
Figure 62: Network components, redundant architecture ..................................................................97
Figure 63: Profit variation, proportional penalty, β=0.1 ....................................................................99
Figure 64: Profit final values, proportional penalty.........................................................................100

iv
Figure 65: Bandwidth allocation, proportional penalty ...................................................................100
Figure 66: Network components, proportional penalty ...................................................................101
Figure 67: Profit variation, proportional penalty, β=1 .....................................................................101
Figure 68: Profit variation, exponential penalty, β=1 ......................................................................103
Figure 69: Profit final values, exponential penalty..........................................................................103
Figure 70: Bandwidth allocation, exponential penalty ....................................................................104
Figure 71: Network components, exponential penalty ....................................................................104
Figure 72: Profit variation, exponential penalty, β=2 ......................................................................105
Figure 73: Profit curve, performability ............................................................................................106
Figure 74: Bandwidth allocation, case study...................................................................................109

ACKNOWLEDGEMENTS
I would like to thank firstly my family for always supporting me; no matter
which event happens or what decision I take, they are always there for me.
I would also like to express all my gratitude to my two thesis advisors, on
the opposite sides of the ocean, for helping me reach this important goal.
I would like to thank my friends for all the support given to me during
these five years: I could never have made it without all of you.
Last but not least, I would like to express my appreciation to the University
of Pavia for giving me all the opportunities I had and for still providing a
quite solid corpus of knowledge in these gloomy times for Italy and for the
Italian University system.

1
Abstract
Network services nowadays are fundamental in every business area of the company. They can be an
internal connection or an external one (outsourcing), they can be the main business (network service
provider) or they can support the main business (web service provider, content provider…). As any
other service used or provided by companies, it needs some regulation or contract. What is used in
this case, and in many other situations, is a Service Level Agreement. This is a contract between a
Service Provider and a Customer and the whole relationship between these two actors is specified in
it, from the beginning (the negotiation) to the end (termination). This document includes both
qualitative description of the contract and quantitative measures for the description of the level of
service. Usually a SLA also details pricing for the service and penalties incurred for not complying
with the established level of service.
No matter what type of service is provided, this document is of capital importance for the SP,
because most of its profits or losses depend on it (especially when B2B relationships are at stake).
The activity of Service Level Management is then crucial and most of the research in this field has
dealt with optimizing the SLM in different ways. The common goal of the researches in SLA has
been standardizing SLM, automating SLM and optimizing SLA. My research deals with the last
issue.
Optimizing SLA means finding the best solutions for different SLA environment with the aim of
maximizing Service Provider profit, Customer profit or both. In this case, we analyze profit
maximization from the SP point of view.
We start from a simple LAN network environment and model the problem on the assumption of
self-similar traffic. Differently from other researches, my model accounts both for performance and
availability SLA constraints. The goal of this research then is both investigating the trade-off
between Performance and Availability limits and finding the most profitable mix of service for the
SP. The model computes the profit as the difference between variable or fixed revenue, coming
from providing bandwidth, and costs (variable for penalties and fixed for network resources). We
assume the SP will contract different levels of service for different Classes of Service. Solutions for
the model are found using a global optimization algorithm.
The solutions show that it is generally more profitable for the SP to offer a largest share of highly
demanding services.

Section 1 - Introduction
________________________________________________________________________________
2
1 Introduction
The pervasiveness of the Internet provides a platform for organizations to offer and buy electronic
services, such as financial information, hosted services, or even ERP applications that can be
integrated in a customer’s application architecture. A service relationship also constitutes a business
relationship between organizations, defined in a contract. An important aspect of a contract for IT
services is the set of quality of service (QoS) guarantees a service provider gives. This is commonly
referred to as a Service Level Agreement (SLA), a formal definition of the relationship that exists
between a service provider and its customer. An SLA can be defined and used in the context of any
industry and is used to specify what the customer could expect from the provider, the obligations of
the customer as well as the provider, performance, availability, and security objectives of the
service, as well as the procedures to be followed to ensure compliance with the SLA. SLAs are
often used when corporations outsource functions considered outside the scope of their own core
competencies to third party service providers [1].
Today, SLAs between organizations are used in all areas of IT services—in many cases for hosting
and communication services but also for help desks and problem resolution. SLAs are also used
within large companies where different business units negotiate their relationship as if they were
independent organizations [5].
The benefit of the SLAs is that they are used in a global, automated management system. It
responds to the dilemma: improve the service provider’s ability to meet the more and more complex
SLA commitments while making optimal use of the more and more complex network. In this
context, the SLA management appears as a key differentiator in the Service provider offer [2].
Service provider differentiation will depend largely on the reliability of their SLA management and
monitoring, and the resulting increase in customer trust. Each service can be differentiated by the
SLA, which defines parameters such as the QoS and the required bandwidth. SLAs have no real
value in themselves, their value lies in the way in which they are managed in the network. It is
essential to improve the service provider’s ability to meet the contract with the customer, as defined
by the SLA, in order to make optimal use of the network while minimizing any penalties from non-
compliance [3].
1.1 Managing Service Levels
Business relationships involving the trading of services require mechanisms that manage the levels
of service. While acceptable service levels promote further business interactions, poor service levels
are likely to have negative influence on the relationships between service provider and customers.

________________________________________________________________________________
3
This could result in the termination of the affected relationship. If the provided services do not meet
the customer’s expectations, further transaction between the two parties are unlikely to occur.
Ensuring that services meet, and perhaps exceed, the customer’s expectations, requires accurate and
constant management. Further trading of services is negatively affected if the management of those
service levels is deficient or absent. In today’s ICT environments, the offering of services with
agreed service levels has become essential.
Before service levels can be managed, they have to be set. In order to establish service levels, the
customer’s expectations and the provider’s capabilities need to be aligned. This process also
requires the acknowledgement of the provider’s capacity to provide services, the identification of
the customer’s requirements and then the marrying of these in an environment that promotes the
development of a sustainable business relationship.
Figure 1: Achieving end-to-end guaranteed service levels might be hard
1.2 Definitions of Service Level Management
There are a number of definitions of SLM. These many definitions show how broad the area of
SLM is. These definitions originate from a focus on the services, the customer or the provider.
With the focus on service, SLM is seen as the process of negotiation, SLA articulation and
development, provision of checks and balances, and reviews between provider and customer
regarding the services and service levels that support the customer’s business process. In light of
this, an SLA is seen as a contract between a provider and a customer that documents the business
processes as well as the supporting services, service parameters, acceptable/unacceptable service
levels and liabilities on the part of the provider and the customer, and actions to be taken in
specified circumstances. SLM is therefore seen as the process of identifying, defining, negotiating,

________________________________________________________________________________
4
agreeing, implementing, monitoring, reporting and managing the levels of customer service, with
the targets being documented in SLAs.
With a customer focus, SLM involves the definition of customer expectations, the satisfying of
those expectations and the perpetual refining of the business agreement. SLM is therefore seen as
the process of setting, measuring and ensuring the maintenance of service goals. SLM helps
organizations make sure that their key targets for service success are being met. SLM is a process
for delivering services that constantly meet the customer’s requirements. Performance management
is a key function of SLM and this includes the definition, measurement and assessment of services,
as well as the setting and monitoring of service objectives and service levels. Allied to these
function are the associated activities of reporting, customer interaction, Customer Relationship
Management (CRM) and negotiating SLAs. Good SLM leads the refinement and improvement of
services. A further benefit of managing service levels involves gaining customer loyalty and trust.
In order to do so, the managing of relationships with customers is an integral part of SLM.
From a service provider’s perspective, SLM can be seen as a set of people and systems that allow
the organization to ensure that agreed service levels are being met and that the necessary resources
are being provided efficiently. This relationship exists between people and system, but system
further separates into technology or tools and processes.
SLM is therefore seen by the provider as a disciplined, proactive methodology used to ensure that
required levels of service are delivered to customers in accordance with business priorities and at an
acceptable cost.
In practice the focus on services, customer or provider, depends on the actual business strategy. For
instance, a corporate focus on maximum customer satisfaction may result in a service management
focus on the customer, whereas a corporate focus on cost saving may result in a service
management focus on measurable and matching services.
SLM may be defined then as follows:
“SLM is a cyclical and collaborative process. It is initiated by the verification of the service
provider’s capacity to deliver and manage services according to identified service levels. This is
followed by the process of understanding and refining a customer’s requirements, the negotiating,
creating, deploying and refining SLAs and the real-time monitoring and reporting of service levels.
This is done within a framework of accountable costs, continual service level improvements and
perpetual development of the business relationship.”

________________________________________________________________________________
5
Figure 2: Example of an SLM framework (ITILv3)
1.2.1 Elements of Service Level Management
The primary goal of every ICT service provider should be to provide services that are aligned with
and support an organization’s business strategy and objectives. Since many of today’s businesses
operate in a dynamic environment, this goal has become increasingly elusive. The only way ICT
service providers can continue to hit the moving target of supporting business needs is by having an
SLM strategy in place.
While SLM is an overriding process, it has six key elements:
1. Service Level Agreements (SLAs)
2. Operational Level Agreements (OLAs)
3. Underpinning Contracts (UCs)
4. Reporting
5. Service Catalogue
6. Technology and toolsets.
1.2.1.1 Service Level Agreements
An SLA is a legally biding document between the service provider and the customer that specifies
the expectations and obligations that exist in a business relationship between them. SLAs are
therefore contracts between service providers and customers that define:

________________________________________________________________________________
6
 The service to be provided
 The metrics associated with these services
 The acceptable and unacceptable service levels
 The liabilities and obligations on the part of the service provider and customer
 The actions to be taken in specific circumstances.
Although an SLA is an excellent expectations-management mechanism, it is important to manage
the expectations of what the SLA can realistically accomplish. An SLA is frequently incorrectly
viewed as a complaint-stifling mechanism or a quick fix to a troubled relationship; however, suing
it for such purpose creates more problems than it solves. Instead, an SLA should be viewed as a:
 A communication tool – the value of an agreement is not just in the final product; the very
process of establishing an SLA helps to open up communications.
 A conflict prevention tool – an agreement helps to avoid or alleviate disputes by providing a
shared understanding of needs and priorities. If conflicts do occur, they tend to be resolved
more readily and with less damage to the relationship.
 A living document – an SLA is not a dead-end document meant to be filed and forgotten.
At a pre-determined frequency, the parties to the SLA review the agreement to assess
service adequacy and negotiate adjustments. This is one of its most important benefits.
 An objective basis for gauging service effectiveness – an SLA ensures that both parties use
the same criteria to evaluate service quality.
As SLA is an agreement between the customer and the service provider that quantifies the
minimum acceptable levels of service required by the customer. An SLA is probably the most
important document in a service provider/customer relationship. An SLA, when properly written, is
distinguished by clear, simple language and focuses on the needs of the customer’s organization.
Creating a sound, mutually agreeable SLA is a matter of appropriate diligence by both parties.
Figure 3: Role of the SLA
To be effective, an SLA must incorporate two sets of elements, namely, management elements and
service elements. Management elements are issues such as reporting, regular meetings, conflict
alleviation and delivery monitoring. Service elements include items such as precise levels about
specific services. These two elements can be included in two ways:

________________________________________________________________________________
7
1. the management elements for the relevant services are contained in the Master Service
Level Agreement and the quantification of the service is contained in an Operational SLA
or
2. both are contained in a single SLA.
The management and service elements are sometimes classified as Agreement clauses and
Schedules respectively.
Not only there are different models for SLAs, but there are also different models for constructing
an SLA [26].
1.2.1.1.1 Structure of SLAs
The exact form of an SLA will depend on the two entities that are entering into the agreement or
contract. In particular, the form of the SLA will be different (especially in the area of penalties)
whether the SLA is between an enterprise and an external party (e.g., service provider), between
internal parties, or between the enterprise and its customers and partners.
An SLA is, in general, a part of (as an annex) or in its own right, a legal contract between the
parties, especially for SLAs between an enterprise and external parties. It is therefore important to
consider taking legal advice as to the exact form of the contract and the language used. If the SLA is
to span international boundaries, legal advice that has an understanding of the differences in
contract law, environmental, employment, and any relevant regulatory environment in the relevant
countries should be considered. Even internal SLAs, where the SLA spans international boundaries,
may have to take these issues into consideration. The language and terminology used should be
appropriate to the audience. A glossary may be necessary to explain common terms, but in
principal, the SLA should be written in a manner such that it can be read by someone versant in the
particular service or technology in question.
It should be considered whether any parts of the SLA (the existence of the relationship, the contract
itself, reports, in total or part) will be considered confidential. There may be competitive advantage
in either the service offered or the application supported. Those areas considered confidential
should be clearly identified and the duration of the confidentiality stated.
When a provider defines a service for the first time, an SLA template will be defined that forms the
basis of all instances of the SLA.
An outline of the main topics for inclusion in an SLA is discussed in the following sub-sections.
The exact form of the SLA will depend on a number of factors, including whether the SLA is a
separate contract in its own right or forms a part (annex) of a larger contract. If the latter, some of
the sections that follows may not be required. It may ease further negotiations if annexes can be

________________________________________________________________________________
8
added to the SLA for new services without having to re-negotiate the main body. If this is likely,
then the SLA should be written appropriately for the first service.
Introduction
This section should document the relevant parties that are entering in the SLA agreement.
The introduction should also contain a brief overview of the need for the SLA and the
application or services it serves.
Customer Requirements
This section should document how the customer is to use the service such that it is clear
what the service must support. For example, if the requirement is to support a round trip
time of less than 1 sec. for a transaction, it will be necessary to understand the peak value
and length of any bursts of transactions that are anticipated. It may be necessary to
determine how the service should respond when (in this example) the transaction rate is
exceeded.
Overview of Service
This section should describe the service including the location of the physical and logical
interfaces between the two parties, who owns which part of the interface, number of
locations, and any other information that describes the service or product adequately.
Term
This section should detail the period over which the SLA is valid, perhaps with a
commencement date.
Responsibilities
This section should detail the responsibilities of both the customer (to the provider to ensure
conformance) and those of the provider (to the customer). Expectations from both sides can
be detailed in this section.
Details of Service
This section should describe the parameterization of the service in terms of the (KPI), as
they will be reported to the customer. It should clearly show the levels of acceptable
performance and non-conformance, and out-of-specification conditions.
Exceptions
It is likely that exceptions need to be included and clearly documented in the SLA.
Downtime for upgrades or routine maintenance may be necessary but need to be described
with notice periods, etc. in the SLA. In multi-site environments, care must be taken to ensure
that the downtime is explicit. For example, if the SLA is between an enterprise and a service
provider providing connectivity between a corporate HQ and its branch offices and the total
maximum downtime is say 10 hours per month, it is likely that you may want to define the
maximum downtime of the HQ and each branch (as in principal they may be different).

________________________________________________________________________________
9
Sampling and Reporting
It will be necessary to define how often the SLA KPIs are measured as a measure of
conformance and how often they are collated in the form of a report or to calculate the
application Key Quality Indicator. The method of reporting (web, paper, etc.) may also be
necessary. Reports for non-conformance (out-of-specification) may require a different
frequency (instantly, within an hour, etc.) bypassing the normal collation process. The
method of reporting non-conformance (e.g., pager) may also be different and should be
documented. The reporting of asynchronous events, alarms, alerts, traps . . . may also be
different and should be replied to. It may further be necessary to establish what frequency of
asynchronous events can be tolerated by either the customer or the provider.
Sample reports should be agreed and included with the SLA document. If the SLA
performance data is required to determine performance metrics in either real time or near-
real time, then the format of this data, the interface (e.g., SQL, XML, CORBA, etc.) and the
support, availability, integrity, and confidentiality of this interface needs to be defined.
It is possible that tiers of reports may be available in an online (web) and offline form. For
example, a user may be able to view the reports for the SLA for his/her own use. Access
control would have to be agreed and verified. How long these reports are stored, either
online or as an archive, should be defined.
Penalties
The penalties for non-conformance should be detailed, but emphasis should be made
motivation rather than to antagonize the situation. These may range from notification of:
• Lost fees
• Repayment of fees
• Compensation for lost earnings
• Termination
• Combination of the above
Invoking penalty clauses does not necessarily gain great benefit, in that the damage is
already done and any monetary penalty is unlikely to compensate even partially for business
lost or damage to brand image. Terminating and moving to another provider may not
necessarily improve matters; such action will lose the goodwill (if any) and cumulative
knowledge gained between the enterprise and provider. For internal parties, penalties will
not necessarily act as an incentive to remedy the condition once failed. Incentives to rectify
the problem as quickly as possible should be considered to offset any penalties, to encourage
co-operation at a likely stressful time and bonuses for over-performance.

________________________________________________________________________________
10
Dispute Resolution and Escalation
This section should document how differences of opinion on the SLA in the contract, its
reports, or performance are resolved. It may be necessary to provide contact details for these
instances and also to document how the situation will be escalated to senior management if
the situation cannot be resolved. For SLAs between external parties, arbitration may be a
quicker and more cost-effective remedy in many cases. For internal parties, this section is
likely to be absent and resolved within the normal management process.
Change Requests
This section should detail the procedure for how change requests to the SLA will be made
and handled, with any expense detailed. Frequency of change requests should be detailed,
with terms like ‘not to exceed’ such that an understanding of the total cost of such requests
can be determined. Notice periods for change requests should be documented. Performance
of these change requests may be subject to the penalty clauses.
Termination
It is likely that either side may wish to terminate the SLA for a particular reason. These
reasons may need to be documented and notice period for termination and any costs
associated detailed. The notice period may differ for supplier-to-customer and customer-to-
supplier. It should also be considered what would happen in the event that one of the parties
is acquired by another party or acquires another enterprise such that the service requirements
may be very different. Consideration should be given to whether the SLA should terminate,
continue as-is, or be renegotiated.
Relevant Law
This section should detail which is the relevant law to be considered for the SLA and under
which jurisdiction any breach of contract will be detailed.
It is likely that this section may be missing between internal parties unless the two parties
are international and there are significant differences in relevant law pertinent to the
operation and performance of the service between the different countries.
Confidentiality
This section should detail and highlight any aspects of the SLA (its existence, performance,
reports, and report data) that are confidential.
Warranties
Areas that are covered by any warranty conditions should be highlighted. Where warranties
already exist for some service resources, how these affect the SLA should be detailed.
Indemnities and Limitations of Liability

________________________________________________________________________________
11
It is important to understand who is liable in the result of failure of the SLA, either the
provider or the customer.
Signatories
The SLA should be dated and signed by relevant signatories from both organizations [27].
1.2.1.1.2 SLA lifecycle
The TeleManagementForum has outlined the SLA in order to provide the organized approach
needed. The SLA life cycle consists of the following phases:
1. SLA development
2. Negotiation and sales
3. Implementation
4. Execution
5. Assessment
Development
Good business practice drives most service providers to develop a product definition or go through
a more extended product development cycle. When they are integrating SLAs into the product mix,
service providers must understand and account for the importance of good product definition up
front. A strong product development process should specify, define, test, and cover (or uncover)
every aspect of a prospective product or service offering. Strong contract and entitlement
development processes are more important for products covered by SLAs.
SLA
Lifecycle
Development
Negotiation
& Sales
Implementation
Execution
Assessment
Figure 4: SLA lifecycle
Contrary to common practice, not all products are truly suitable for use with SLAs. Attributes that
are specific to service level agreements, such as customer needs, contractual entitlements, terms and

________________________________________________________________________________
12
conditions, reporting requirements, and SLA pricing may initially be derived from the information
accumulated as part of the product development cycle. From that point forward, SLAs differ
substantially from products in several ways:
o There may be a one to many relationship among several SLAs and a single product or
product bundle.
o Service level agreements may be bundled with a product, unbundled from the product, or
even be selectable, with several optional levels of QoS.
o Service level agreement life cycles do not necessarily run concurrent with the underlying
product.
Service providers must take these differences into account when they are developing SLAs. The use
of SLAs potentially exposes the service provider to a financial downside (in the form of penalties)
beyond the normal risks associated with introducing a new product. Because the potential for
sustaining losses greatly exceeds that for making revenues, service providers should give careful
consideration to numerous factors when making SLA deployment decisions; for instance, they
should understand the impact that introducing a new SLA may have on the profitability and life
cycle of the underlying product.
From an accounting perspective, for example, SLA penalties paid out to customers have to come
from somewhere. The logical place is the product’s monthly recurring charge (MRC), which is
normally used for penalty calculation anyway.
On the other hand, a well-thought-out SLA can provide a revenue boost, and a service provider may
elect to provide customers with several SLA options for bundling with a product.
Specific terms and conditions should be defined that detail when and how the services are to be
performed or delivered and the responsibilities of the parties; the agreement should also stipulate
the exact frequency, locations, and methods through which the performance is to be measured and
reported.
Negotiation and Sales
Once an SLA has been fully developed, it is put on the market with or layered on top of the
underlying product. In some instances, the SLA may be in a template that has been defined in such
a way that it is a take it or leave it proposition.
This is usually done in the most generic and technically routine service offerings, or when the
service provider is developing the standard or lowest level SLA in a multitier SLA offering.
In most other cases, the customer or service provider may want to modify terms, conditions, or
pricing related to the SLA. In some cases, the customer requirements may be so stringent or unique
that the SLA is actually developed during negotiations. Many SLA offerings have also been created

________________________________________________________________________________
13
after the initial SLA development cycle was performed in response to a request for proposal (RFP)
from a potential customer.
The expected outcome of the negotiation and sales phase is an executed agreement. The products
and services, terms and conditions, metrics, measurement, and reporting, as well as financial (such
as price and penalties) and legal considerations (such as recourse and means to settle disputes, that
is, arbitration) should be stated and agreed upon by both parties.
Implementation
During this phase, the services are ordered, activated, and configured for SLA compliance. This
may mean that certain baseline measurements are taken, new monitoring capabilities installed,
thresholds set, additional reports configured, or almost any number of other possibilities.
While SLAs may be negotiated and agreed to for a large number of products or services, the actual
provisioning process usually calls for service to be ordered and turned up individually. This means
that implementation is actually on a per instance basis, as opposed to the prior phases of the SLA
life cycle.
Each instance of the service will normally be tracked by a unique identifier, such as a telephone
number, circuit ID, Common-Language Location Identification (CLLI) code, Internet protocol (IP)
address, and so forth, and have other discriminating parameters, such as the SAP.
Likewise, each instance may have unique SLA requirements that must be configured, measured,
and reported on individually through the execution phase of the service. Like the service itself, the
SLA compliance measures taken should be “signed off” on or accepted by the customer before
billing for that instance is allowed to begin.
Execution
The execution phase is the normal day-to-day operation and associated activities related to the
service being delivered. This includes measurement of SLA entitlements on an ongoing basis.
Extraordinary events such as circuit degradation, outages, maintenance downtime, and even failure
of the capability to measure performance (Operations Support System (OSS) downtime) should be
recorded and measured and the impact to the business assessed and reported.
Reconciliation should be performed on those SLAs that have immediate or real-time penalty
requirements, while those that have historical or aggregate statistical reporting requirements should
be archived for later (periodic) reconciliation.
Assessment
The SLA should be assessed periodically. There are two types of assessments: customer-focused
assessments and provider-focused assessments.
Customer-focused Assessments

________________________________________________________________________________
14
Customer-focused assessments concentrate on the service provider’s performance from the
customer’s viewpoint. The key metric in this type of review is SLA compliance (primarily
availability) and customer satisfaction.
Provider-focused Assessments
Provider-focused assessments concentrate on the execution of the SLA as a business case within the
overall SLA strategy. The intent behind this type of review is to optimize the use of the SLA by the
service provider in order to improve profitability through achieving better compliance or reducing
penalty exposure by changing the commitment contained within the SLAs. The key metrics in this
type of review are delivered QoS, SLA profitability, and recommended improvements. [36]
1.2.1.2 Operational Level Agreements
SLAs are not enough to ensure the timely delivery of service as needed by the business. Operational
Level Agreements (OLAs) need to be put in place between related ICT departments in order to
unify ICT service delivery throughout an organization prior to executing customer SLAs.
OLAs establish specific technical, informational, and timeframe requirements needed for each ICT
department to provide the services that will be delivered to the customer. For example, the email
administrator might require specific information, as well as a 48-hour span of time to create an
email box for a new employee. This needs to be documents and approved by all impacted ICT
departments before the Service Desk establishes an email provisioning SLA with the customer.
Without OLAs in place, SLAs will frequently promise services that are impractical at best or
impossible at worst. Clearly defined OLAs prevent unkept promises to customers. Additionally,
OLAs present a more united ICT service provider to the customer. On many occasions, the exercise
of building through OLAs can iron out long-standing feuds that have been based on
misunderstandings. Ultimately, OLAs hold each group accountable for their service, and also build
understanding of each group’s contribution to the overall delivery of service.
Key performance objectives and internal incentives need to directly relate to OLA compliance.
Since the entire goal of an ICT service provider is to service the customer, well-defined OLAs
should provide a template of objectives that show managers those activities that are most
appropriate to monitor, report, and reward.
Lastly, OLAs need to serve as benchmark any time SLAs need to flex to meet business
requirements. If a specific service is required faster or differently by a business unit, the OLAs
show exactly which groups need to be consulted, and which services provided by those groups
ultimately affect the delivery of the desired service. If the providing group can agree to change how
their service is delivered, then the SLA can be changed, and the OLA can be altered accordingly

________________________________________________________________________________
15
1.2.1.3 Underpinning Contracts
For any services provided by third-party vendors or service providers, Underpinning Contracts
(UCs) need to be put in place. UCs are similar to OLAs in that they complete the chain of
accountability and control for seamless service delivery. ICT service organizations may put
contractual agreements in place with their entire SLA process. As service needs change with the
business units, ICT service providers negotiate any changes with third-party vendors as needed, and
modify the UC accordingly.
Figure 5: Relationship between SLA, OLA and UC
1.2.1.4 Reporting
Reporting efforts need to complement the key measurements in SLAs, OLAs, and UCs. Reports
that show the overall SLM performance must be communicated upward to ICT management, as
well as to the customer’s management. Effective SLM reporting demonstrates the value of ICT and
business alignment. A thorough understanding of ICT service capabilities can help guide business
planning. Conversely, ICT can scale back or enhance services to meet business needs in future.
Additionally, effective performance reporting is an excellent management tool, as well as providing
performance incentives to staff. When you are measuring and reporting the right things,
performance reporting can efficiently modify service behavior, provide incentive, and reward the

________________________________________________________________________________
16
achievers in a consistent fashion throughout ICT. The net result is a more satisfied and effective
workforce.
Figure 6: Example of SLA violation report
1.2.1.5 Service catalogue
In the same way, a restaurant menu sets initial expectations for a customer and provides the basis
for a personalized service, the Service Catalogue enable ICT organizations to market and commit to
achievable levels of service at a predictable cost or planned price. A Service Catalogue clearly
defines what services are available from the ICT service provider and aligns those services with
business goals and needs. The Service Catalogue focuses specifically on documenting and
articulating all the ICT services provided by the organization. This includes the necessary service
requirements that are usually detailed in an SLA. However, at its simplest level, a Service
Catalogue is a record of all the services offered within the organization that will contribute to the
success of SLM. With this focus in mind, a Service Catalogue is developed in order to do or support
the following:
 Define and publish all available ICT services and SLAs provided by the service provider
that align with business needs
 Standardize service fulfillment processes
 Establish achievable service levels

________________________________________________________________________________
17
 Determine the associated costs
 Manage performance.
From a high-level perspective, the objective of SLM is to lead ICT service providers through the
design of a Service Catalogue, the development of detailed service descriptions for their services,
and the development of an SLA for their major, mission-critical services that are well defined,
measureable, and in a negotiable state. These services are then documents in a Service Catalogue.
From an ICTSM maturity perspective, the goals of an organization using a Service Catalogue are to:
 Detail an inventory of all ICT services that are provided by the service provider
 Enable an optimized, service-focused organization
 Describe and document a well-defined and effective set of tailored processes and methods
that are supported organization-wide and are continuously improved
 Provide an integrated set of people, process, and technology that is well established, can be
integrated into the organization, organization-wide, and continuously improved as needed.
Specifically, one area that denotes SLM maturity within ICTSM is the development and
maintenance of a Service Catalogue that includes identifying and qualifying the types of services
being provided and integrating Service Level Objectives (SLOs) and agreements information that
employs a business and customer service focus.
Figure 7: Service portfolio (ITILv3)

________________________________________________________________________________
18
1.2.1.6 Technologyand toolsets
Since SLM is almost entirely based upon processes, many ICT service managers make the mistake
of assuming that SLM can be done manually and through effective communications alone. This is a
mistake and a common reason why SLM initiatives fail. SLM is an ICT organization-wide initiative
that is much too complex to monitor and maintain manually. The flow of data alone is much more
than can be handled manually. Appropriate SLM creates a stream of data that shows the flow of
every service transaction through the SLM process. The levels of service are then compared with
the SLM, OLA, and UC where appropriate, and the pertinent data of the vent is logged for
reporting.
An SLM tool provides analytical data to analyze the environment on a real-time basis and raise
alerts when service levels are in danger of slipping lower than the agreed-upon levels both for
incidents measured individually and multiple incidents measured cumulatively over time. The
benefits of SLM are virtually amputated if it is implemented manually. Inferior enabling technology
is a key delaying point for a successful implementation of SLM. A robust toolset (including those
for reporting), however, paves the way for the provider organization to manage services.
Figure 8: Types of service provided by an IT enterprise (ITILv3)

________________________________________________________________________________
19
1.2.2 The benefits of Service Level Management
Improvements in service quality and reductions in service degradations as a result of effective SLM
can ultimately lead to significant financial savings. Less time and effort is spent by ICT staff in
resolving fewer failures and ICT customers are able to perform their business functions without
adverse impact. The following are key benefits of SLM:
 ICT services are designed to meet service level requirements
 Improved relationship are fostered with satisfied customers
 Both parties to the agreement have a clearer view of roles and responsibilities, avoiding
potential misunderstandings or omissions
 Specific targets are noted, against which service quality can be measured, monitored and
reported
 ICT effort is focused on business priorities
 ICT and customers have a clear and consistent expectation of the level of service required
 Service monitoring allows weak areas to be identified, so that remedial action can be taken,
thus improving future service quality
 Service monitoring also shows where customer actions are causing the fault and so identify
where working efficiency and / or training can be improved
 SLM underpins provider management
 In some cases where services are outsourced, the SLAs are key part of managing the
relationship with the third party. In other cases, service monitoring, allows the performance
of providers to be evaluated and managed
 An SLA is used as a basis for ht charging and helps demonstrate what value customers are
receiving for their money
The cumulative effect of the benefits listed above leads to a gradual improvement in service quality
and an overall reduction in the cost of service provision. In addiction, SLM establishes, and keeps
open, regular lines of the communication between service providers and customers. The beneficial
impact of this should not be underestimated.
There are five groups of SLM benefits: business, financial, employee, innovation and internal.
Business benefits
The business benefits centre on the improvements in the quality, reliability and predictability of
business operations. This leads to better working relationships and satisfaction between customer
and provider.
Financial benefits

________________________________________________________________________________
20
Long-term financial benefits are associated with a cost-justified ICT infrastructure. These include
improved reactions time, preventive measures and service continuity expenditure.
Employee benefits
Employees have clearer role definitions. They experience increased motivation, job satisfaction and
increased productivity. The ICT provider’s reputation can also improve.
Innovation benefits
The clearer understanding of ICT requirements and service levels provides for greater flexibility
and adaptability within services. Improvements are noticeable in the ability to recognize changing
trends and to adapt quickly to new requirements and market developments.
Internal benefits
Associated with the improved metrics and management reporting are the improvements in
information and its communication to decision makers. Clearer role definition and view of current
ICT capabilities lead to process maturity, providing repeatable, consistent and self-improving
benefits.
1.2.2.1 Quantifying the benefits of Service Level Management
In quantifying the effects when ICT resources fail or are inaccessible, a corresponding loss of
business revenue usually occurs, the associated lost opportunity costs are also accompanied by other
losses due to regulatory penalties and market share loss to competitors, it is also important to
consider that the cost of downtime varies significantly by industry, acknowledging that financial
services companies have extremely high costs associated with even the smallest disruption in
service.
In quantifying the impact on business revenue, an understanding of the critical business systems and
the associated revenue gained by those systems on annual basis is required. This information can
then be extrapolated to an hourly rate, and by assessing the increased service availability due to
proactive SLM, a corresponding benefit can be calculated.

________________________________________________________________________________
21
Figure 9: SLM may help identify sooner the causes of outages (ITILv3)
SLM benefits can also be demonstrated by showing the direct impact of outages and service
degradations on end users, demonstrations of which also include the additional time that users are
productive based on the increased availability. These improved productivity calculations and
forecast can further strengthen the case for proactive SLM.
Potential SLM implements can also use their newly acquired data in future business applications,
workloads and service levels to forecast the necessary ICT architecture and assets needed to deliver
on those requirements, this guarantees that adequate captivity will be available and also supports a
policy of just-in-time upgrade. This approach helps deliver better return on capital employed,
recognizing that the net present value of deferring hardware purchases can be calculated along with
any associated costs for maintenance charges for upgrading software licenses.
Proactive SLM also leads to higher utilization levels of ICT components because of more accurate
service quality measurements and the ability to balance workloads more efficiently across available
resources. These improved levels of utilization permit ICT service providers to defer the need for
upgrading hardware and software. Being proactive can also encompass monitoring the service to
anticipate and prevent service degradations.

________________________________________________________________________________
22
Figure 10: SLM can help identify the best solution for service restoring (ITILv3)
True SLM means going beyond the historical and reactive aspects of the process, suggesting that it
requires becoming proactive and focusing on continuous service improvements. Being proactive
means that an ICT service provider:
 Has developed a thorough, tested, comprehensive program for backup and recovery,
including complete and tested disaster recovery
 Monitors the service to anticipate and prevent service degradations
 Thoroughly controls the flow of demands for the service.
The benefits of a successfully implemented SLM strategy are clearly evident for both the customer
and the provider. These benefits relate to the improvements in communication between customers
and providers, increased levels of service and the refining of business practices. Employees of both
the provider and customer organizations experience increased productivity and motivation. These
benefits of SLM can be grouped into two broad categories:
1. Improved customer relationship management – SLM leads to improvements in
managing and satisfaction of the customer’s expectations. An effective SLM strategy
includes the relevant planning, procedures and practices that focus on the customer
and the satisfaction of their expectations
2. Improved business practices – SLM provides a framework for improving service
quality and reducing costs. The process also empowers ICT staff, as the focus on
SLM improves the marketing of the ICT services. It further facilitates an
organization’s ability to respond resourcefully to the dynamic ICT environment.
It is clear that the reasons to implement an SLM framework are substantial. The case for SLM is
convincing for both the provider and the customer. The benefits of a successful SLM program will

________________________________________________________________________________
23
ultimately impact on the bottom lines of the companies who implement it successfully. The
improvements in customer relationships, the reduced costs and the improved business practices
have significant financial benefits.
1.2.3 Current service management problems
Unfortunately, many SLM initiatives fail. Failure can be attributed to a number of factors, most
prominent of which is the lack of knowledge and understanding that plagues SLM. A number of
problem areas impact negatively on SLM, mostly concentrated around the confusion surrounding
the use and value of SLM, the inappropriate application of SLM, the manner in which services are
measured and managed and the lack of skilled practitioners in the field.
Misinformation and misunderstanding
Whole the benefit of integrated management of service levels is significant, the foundations on
which they are built, are increasingly fractured and lacking in standards support. While SLM,
including Quality of Service (QoS), SLAs and service assurance, are currently topical in ICT
circles, a great deal of misinformation surrounds the topic. The cause of this misinformation and
misunderstanding stems from five SLM myths:
Myth 1: SLA equals SLM
Managers often mistakenly assume that SLM is the same as SLA. SLM can be successful without
SLAs, yet, on the other hand, SLAs in the absence of SLM are meaningless.
Myth 2: SLAs will make users happy
SLAs are not a magic potion, an SLA is a way to set expectations and communicate about the
services that are being delivered.
Myth 3: SLAs will result in higher service levels
By itself, an SLA cannot directly produce any changes in the levels of service delivery. However,
improvements in service levels sometimes coincide with the establishment of SLAs. This is due to
the paying of closer attention to services and the improvements in customer / service provider
communication during the negotiation phase. An SLM program is the reason for any resulting
increases in levels of service.
Myth 4: penalty clauses in an SLA will guarantee service levels
Penalty clauses act as incentives to service providers as well as define appropriate compensation
when service levels are not met. However, it is very difficult to negotiate penalty clauses that meet
these two objectives. Difficulty exists in extracting these penalties without the assistance of costly
legal action.

________________________________________________________________________________
24
Myth 5 SLAs are not necessary when outsourcing ICT functions
Many companies do not have SLAs with their outsourcing partners. This level of trust is both naïve
and could be considered as negligence on the part of the managers.
Developing service agreements
Developing SLAs is a most difficult problem and must be addressed. SLAs must be consistently
and accurately defined, documents and monitored, with regular reviews. If not, then potential
service improvements are not realized and SLAs may fell into disuse. It is more difficult to resurrect
them or to re-launch SLM. Consequently, it is far better to recognize the potential difficulties in
advance by putting correct development procedures in place.
SLAs establish a negotiated and agreed upon two-way accountability for service. They build
credibility for the service organization by indicating how serious they are about providing support.
Yet while many organizations understand the vital role played by SLAs, many are unaware or
unwilling to dedicate the amount of resource required to maintain them.
Reporting
Reporting efforts need to complement the important measurements in SLAs. Reports that show the
overall SLM performance must be communicated to ICT management and ICT middle
management, as well as to the customer’s management structures. Effective SLM reporting is the
medium of communication that demonstrates the value of ICT and business alignment, serving as a
management tool.
Reporting customers about performance is a key monitoring aspect of SLM. Unfortunately, much of
today’s ICT reporting is of limited worth as the associated reports are usually filled with technical
data that has little, or no value to the customer. Reporting can be done periodically or in real-time,
the latter enjoying first priority. A critical aspect of SLM failures is lack of attention given to the
development of reporting structures.
Semantic disparity problem
There are methods and challenges regarding SLM, however, the crux of SLM involves two
competing strains, referred to as the semantic disparity problem:
 Parameters that are easy to measure for ICT specialists do not translate well into parameters
that are readily understood by customers.
 Parameters that are easily understood by customers are not easy to measure for ICT
specialists.

________________________________________________________________________________
25
People issues
People issues are a big challenge to implementing and improving SLM. People issues include
training, workflow and role definition, and management of change.
Fluid business / static service
The business processes that are supported by service are in a state of constant flux. Yet the provider
continues to offer the same service in the same way. The services offered previously may have
become ill adjusted to the business needs, and / or have not kept pace with the change. The
business, on the other hand, may have embarked on changes to stay competitive. The result has
been a widening gap between the services offered and their usefulness to the business units.
Inefficient or non-existent change management
Change requests that come to ICT from the business units should be managed through a formal,
customer facing change management process. Often, however, internal ICT groups circumvented
this formal process.
Disunity
A problem with change management is that it is often a symptom of a deeper cultural problem.
Because there is no unified vision for ICT service and support, each group forms its own vision and
ends up stepping on the vision and goals of other groups. The result is that, over time, political
barriers for that can lead to cumbersome procedures that are often burdened with protective hidden
agenda. As ICT groups hoard their knowledge, support often takes longer, and as a result, the true,
united capabilities and service value of ICT are unknown to ICT or its customers.
The deception of customer satisfaction
It is important to measure customer satisfaction at the service transaction level. This does not
necessary measure how well ICT services are aligned with business needs. Many ICT support
managers have been deluded by good customer satisfaction scores that dismiss them from hard
work of forming true business alignment by engaging in continuous dialogue with their customers.
The legacy of failure
Many organizations can attest to failed ICT Service Level Agreements. In these organizations,
SLAs often took months to create. The customers are most cooperative in telling ICT service

________________________________________________________________________________
26
providers what they need, and the service provider creates the SLAs. The results are documents that
are somewhat complex, requiring work to monitor and maintain. Additionally, these agreements
called for a system of measurements that are meaningful for the business units, but require data
from the ICT service provider that is time consuming to assemble. Eventually these SLAs are tossed
in a drawer and became dead documents. They are not monitored, and no continuous feedback
process, to stakeholders, is in place. The result is a lack of accountability between all those
involved. ICT service providers must establish a link between service performance and business
performance [26].
1.3 SLA metrics
A metric is just another term for a measure. In IT, metrics have come to mean particular things to
different people. Simply measuring things for the sake of it is expensive and pointless. Metrics
themselves are not an end. Metrics are an important part of the Management System that steers and
controls IT in the desired direction. Metrics must be designed in line with customer requirements,
they must be benchmarked to ensure that they are achievable and they must be monitored to ensure
that they keep within desired thresholds with actions taken to correct any problems. They also are
the target of the Continuous Service Improvement Program, as processes and services are
continuously improved, so are the metrics that measure them. It is important understand what the
business’ objectives are and ultimately arrange that all measuring, monitoring and control is aligned
to attaining these objectives.
Objectives
The aims, or the objectives, of using metrics in IT service Management are:
1. to align business objectives with it:
a. to provide accounting for IT processes and deliverables,
b. to inform stakeholders of IT service Management
c. to assist stakeholders in understanding IT performance and issues
2. to help achieve compliance requirements for business operations:
a. to steer IT operations strategically,
b. to help attain ISO20000, COBIT or other certifications,
c. to achieve Critical Success Factors (CSFs),
d. to minimize interruption of the business
3. to drive operational excellence of IT strategically:
a. to measure IT & process performance,
b. to control IT Service Management processes,

________________________________________________________________________________
27
c. to manage IT tactically,
d. to maximize IT productivity and performance,
e. to prove the value creation of the IT organization.
1.3.1 Business & IT alignment
ITIL is designed to align IT with business needs, as are other Quality Management initiatives, such
as COBIT and Six Sigma. Common to all these is a need to understand the business goals, the needs
of the various stakeholders and what part IT plays in assisting with achieving those goals and
delivering services to those needs.
Metrics as Management Information
The business has to understand how well its business processes are performing. IT plays an
important role in three ways to assist with this.
Firstly, IT nowadays often is responsible for providing accounting, logistical and other direct
services to business processes. Accordingly, the measures are provided in management reports to
the various business units.
Secondly, IT provide service to business processes documented in the Service Catalogue, with the
detail of delivery defined in the various SLAs set up between the Service Level Manager and
business customers. These measures are shown as exception reports to Key Performance Indicators
(KPIs) based on negotiated SLAs. Trends in these reports show how IT is improving its ability to
provide services to high standard.
Thirdly, IT itself is an important business process; a business contingency plan without a substantial
section on IT service continuity is rare. Thus, IT reports on the operation of IT processes are part of
the management information required by the business. This information is, however, business
information, so detailed technical metrics are not appropriate. Rather the condensed results of
measurement of IT processes can be represented in business terms. Ultimately, business measures
are monetary measures so the aim of IT is eventually to provide Return on Investment (ROI),
Return on Capital Employed (ROCE), Economic Value Added (EVA) or any other expression.
Before this can be done, however, IT Financial Management, in ITIL terms, must have reached a
high level of maturity. Until then, measures of process efficiency, along with KPIs against SLAs
provide the most complete picture of IT services to the business.
Once clear and relevant metrics have been designed, it is important that they are presented clearly.
Different reporting methods and different sets of metrics will be appropriate for different audiences.
The naming of metrics is also important so that, if a metric is changed from one reporting period to
another this is made clear.

________________________________________________________________________________
28
If processes are not implemented in a consistent, repeatable manner, the metrics produced by them
will be unreliable. It is important, as ISO20000 emphasize, for these to be a sound Management
System in place with sufficient maturity and process management to be part of an organization’s
way of doing things for metrics to provide useful measurement.
Metrics for management control
When something in business is measured, particularly when this measure is made the responsibility
of a manager or a team of people, the behavior of the people measured changes. If the metrics are
well designed and the objectives of the metrics are in line with business requirements, this behavior
will tend to be in line with these business requirements. In other words, a well designed and
measured metric is a method of control. If a metric is not well designed, is not in line with actual
business requirements or is not measured correctly then this ‘control’ can drive behavior in opposite
direction and harm the operation of the business.
Another problem many organizations have met is indecision. If metrics have been badly designed,
they have to be changed, of course. However, if they are changed to try to address the immediate
problem, rather than carefully designed, the new metrics may prove almost as bad. This will then
mean that they have to be changed again. If metrics are changed every few months, there is no
reason for anybody to work hard to achieve them. People soon work out that they only have to wait
for change, and there will be a new period of uncertainty in which there is no effective metric and
hence no effective management control. An organization under the effect of constantly changing
metrics is likely to be worse off than one with no metrics at all.
The various process metrics enable the IT organization as a whole to measure the effectiveness of
managers in implementing, improving and maintaining the quality of the delivery in their areas of
responsibility.
Metric integration & reporting
Metrics do involve detailed measures of technical matters. This is unavoidable. However, once the
key metrics have been set, these can be reported using the ‘traffic light’ or ‘dashboard’ methods.
This method allows a ‘drill-down’ into the detail to occur when a problem is isolated at the top
level.
If the metrics for different processes are designed in a similar way, the management of these
processes can be compared with each other. Though the Change Management Process is a very
different thing from the Availability Management Process the management, maturity and
effectiveness of these two processes can be compared by having similarly structured integrated
metrics, particularly if these metrics include an accurate measure of customer satisfaction, in which
the ‘customer’ is defined as the main beneficiary from the output of the process.

________________________________________________________________________________
29
Metrics aligned to stakeholders
Communication is a vital part of IT Service Management. If stakeholders are being informed by
metrics, they can contribute to the success if the enterprise by supporting the openness and
transparency, and by seeing the improvement.
This enables appropriate communication of metrics, their results and what these results mean in
terms of delivery of service to stakeholders. Stakeholders need to be an integral part of IT definition
and satisfied with the results they see from their active involvement.
Communication is a two-way process so it is important to integrate requirements from the various
stakeholders and use their involvement throughout to improve service delivery and process
operation. For this to be handled properly, it is important that it is dealt with using a carefully
constructed communication plan, using stakeholders to assist in its construction and review.
Customer
Ultimately, all business effort ought to be directed towards the end customer. IT provides a support
function for the business processes, but sometimes the IT contribution is experienced by the
business, end customer (the ultimate customer) as well.
In these cases, to be sure that we have contributed effectively to the business, the business must
measure the satisfaction of all end customers. This measurement must, however, be handled
sensitively. If we demand surveys too frequently from customers, this activity itself will become a
negative factor to them. If we do not solicit advice on how well we are doing often enough, there is
a danger of not being aware of service incidents for long enough for them to impact our satisfaction
seriously.
User
Since users do not negotiate the terms of their service and do not pay for it, they are not direct
customers of it. However, as stakeholders, their satisfaction with the service is vital. If users are not
satisfied as they are being supplied with poor quality services, eventually our customers will not be
satisfied.
Employee
Employees within IT have the responsibility to deliver service processes. IT, in return, has the
responsibility to supply good working conditions with fair evaluation and reward. If employees are
not satisfied the service level provided will be less than they ought to be, no matter how well
defined the metrics are. Thus, it is an imperative of IT management to measure staff morale and be
sensitive to change that might impact it negatively.
Employees are happier when they feel recognized as a stakeholder. In addition, they need to be able
to identify with their employer, out of positive respect for the business, and approval of the

________________________________________________________________________________
30
processes. Communicating metrics to employees clearly and openly enables them to understand
where IT is doing well and where there are issues that require further effort. Effective
communication enables employees to address issues and to find an inspiration to further effort.
Board
Senior management and the Board have a particular need, as stakeholders. In order for the business
to thrive, they require advance warning of any potentially serious incidents so that urgent corrective
actions can be taken. An open and transparent communication with the Board can help as these
incidents can be identified before they become too serious to remedy.
Other stakeholders (government and shareholders)
Though these stakeholders are important to the business, the correct communication to them is the
Board’s responsibility. If IT has messages that can reassure or warn such stakeholders, it is
important that they are communicated first to the Board. In this way, the Board can decide on the
appropriate channel and method of communication.
1.3.2 Metrics are not SLAs
The agreement between the business organization, the customer, and IT is negotiated by the Service
Level Manager and results in a set of defined Service Level Agreements (SLAs). These SLAs
define what service levels IT agrees to provide.
These SLAs are used by the Service Level Manager to define the Operational Level Agreements
(OLAs) and, where third parties are involved, the Underpinning contracts (UC) that enable the
service to be delivered.
The Critical Success Factors (CSFs) for IT are defined by the OLAs – if you look at it from a
bottom-up point of view. If an OLA is met then the relevant CSF will be satisfied – if the match
between them is good. Actually, OLAs are derived from SLAs, which rely on CSFs, so are broader
in scope than a particular OLA may be. For a member of the organization, though, the CSF can be
seen as the goal of the OLA.
CSFs are the service delivery measures that must be met to satisfy the SLAs. Each CSF can then be
used to define a Key Performance Indicator (KPI) that is a measure of whether the CSF is being
delivered. Thus the entire chain is:
Customer
requirement
SLA
OLA /
UC
CSF KPI
Monthly
report
Figure 11: Metrics chain

________________________________________________________________________________
31
Metrics and KPIs
As we see above, the KPI provides a customer facing metric that measures the success with the
SLAs defined with the customer.
This enables IT management to know each month whether it is doing well or not. IT management
must have measures that show how the organization is operating daily or weekly so that corrections
can be made before SLAs are compromised.
This is where process metrics come in to play. The ITIL approach to IT Service Management
defines delivery in terms of service to customers. This is why the KPI is the proper measure of
service delivery. However, ITIL also defines the operation of the various parts of IT in terms of
processes. Each of these processes can be seen as an engine that takes certain input and processes it
into output.
Service
Improvement
Process
Process
Owner
Internal
Stakeholders
External
Stakeholders
Input
Input
Output
Output
Process
Metrics
Process
Metrics
Metrics
Metrics
Organizations
Process
States
SLA Requirements
End-to-End Service Needs
Satisfaction
Feedback
Process
Service Reports
KPI
SLA Compliance
Service Reports
KPI
SLA Compliance
Change Requests
Figure 12: Metrics process flow chart
The diagram shows the alignment between this process and both external and internal stakeholders.
Darker blocks represent processes and organizations internal to IT whilst lighter blocks represent

________________________________________________________________________________
32
external connections and organizations. As it can be seen, KPIs are defined for the process, these
are measured daily or hourly and triggers on thresholds decide escalations to enable corrective
actions.
Each process, however, working with the other ITIL processes, must be managed by metrics that
can be reported to IT management and to other stakeholders, to contrast the process operation of the
different IT processes. The careful selection and measurement of the process metrics as shown
enables the management of the process, as a process, the measurement of the process owner and,
where relevant, the process team. These metrics include some of the KPIs used by the process
owner. He, however, is likely to use a larger set of metrics, giving more detail of day-to-day
changes in process delivery, thus providing more hands-on management.
Metrics and benchmarking
Over a longer period of time, it is possible to measure previous results of metrics and compare one
month or year to previous months and years. These comparisons can be used to set performance
improvement goals.
There are two problems with this. Firstly, when metrics are introduced, it is not clear what an
acceptable or ideal level of performance might be. In order to establish this, it is necessary to
produce an initial base level or ‘benchmark’. This is often done by running the metrics for two or
three periods and then taking the values produced as a ‘benchmark’ of the minimum requirement
and working from there. The second problem is knowing whether this benchmark compares well or
badly with other organizations. There are two approaches to resolving this. Some research
organizations have produced lists of standard metrics with average results across a number of
organizations. If you measure these same standard metrics then these figures can be used to identify
how your organization sits relative to the average. The other approach is to use either a standard set
of metrics, or a set modified from a standard set. Then it is possible to compare your metrics
directly with other organizations using the same, or very similar, metrics,
A hybrid approach is also possible. If you implement your own metrics, but also measure two or
three of the published research metrics, then benchmarking the research metrics can give an
external view, giving an insight into how well the processes work. [37]
1.4 Research objectives & key findings
What this research tries to investigate is the optimal product mix for a network service provider in
different situations and the trade-off between availability and performance. The main difference
between this and other researches on this topic is the use of self-similar theory for the internet
traffic. The numerical results show that the most demanding Class of Service are usually the most

________________________________________________________________________________
33
profitable and that the Service Provider should always ensure enough resources to satisfy the users’
demand, because this is always the most profitable decision.
The remainder of this paper is organized as follows. Section 2 presents a summary of the previous
research in this area. Section 3 defines the model and its main assumptions. Section 4 shows some
numerical solutions of the problem and a sensitivity analysis of it. Section 5 inspects the model
behavior with real world parameters. Section 6 draws some managerial insights, interpreting the
numerical results. Finally, in Section 7 we conclude and discuss about possible developments for
future study.

Section 2 - Literature review
________________________________________________________________________________
34
2 Literature review
There is a vast research literature on resource allocation and profit optimization in the SLA
environment.
As already stated before, the two most important aspect of an SLA contract are performance and
availability requirements. Performance of a service usually can be evaluated with queuing theory
models, where there is a queue of requests that reach the point of service provisioning at a certain
rate. A request is either not satisfied or served according to the speed of service provisioning. This
is what is assumed in [11], where they present a SLA based framework for QoS provisioning. What
they propose is a pricing model with penalties, but the only constraints considered are the ones on
performance metrics, leaving out availability.
Another possible way of examining the SLA models is with the aid of control systems theory. This
can be a quite effective approach since the model can be generalized to various environments. In [6]
they do so and they propose an approach to automated enforcement of (SLAs) by constructing
information technology (IT) level feedback loops that achieve business objectives, especially
maximizing SLA profits. While in [10] they develop a fuzzy control algorithm that implements hill
climbing logic to maximize profits and handle the stochastics that make profits quite “bumpy.”
Both the models are very attractive because adaptable to different problems but they both do not
consider the availability part into the optimization problem.
Many approaches are possible for finding a solution to a profit maximization problem, we can use
the controller and fuzzy-controller based one, but probably the most effective is the one based on
numerical optimization. We may formulate the optimization problem and then maximize the
objective function, which represents the profit. In [8] they present a methodology for maximizing
profits in a general class of e-commerce environments. The cost model is based on revenues that are
generated when Quality-of-Service (QoS) guarantees are satisfied and on penalties that are incurred
otherwise. They in fact use an accurate representation of a typical SLA with QoS guarantees and
per class limits, although the model is lacking in generality and considers only performance related
measures.
Most of the research in this particular field of application of the SLAs is focused either on
availability or on performance measures, but for network service providers the trade-off between
availability and performance is one of the biggest dilemmas (the so called ‘performability’). In [12]
they propose a policy-driven approach to automate run-time availability management in IT systems,
according to high-level availability and performance objectives. In this model, the availability is

MS thesis

Recommended

Recommended

More Related Content

Similar to MS thesis

Similar to MS thesis (8)

More from Red Hat

More from Red Hat (20)

Recently uploaded

Recently uploaded (20)

MS thesis