Re: [soa-rm-ra] definition of SLA

Interesting.  In the early pages of the RM, we often talk about constraints and policies as a duo, and later define policy in terms of the word constraint.  Now what you bring up is the idea that configuration happens in response to some information exchanged in initiating the interaction.  This could be the result of policy or technical assumptions or possibly other things.  I think much of this could (but not necessarily does) happen in response to things separate from a SLA.  The response can be noted as part of the discussion of interaction but likely happens without the consumer's explicit knowledge.

So it feels like another loose end.

Ken

On Jan 26, 2007, at 2:31 PM, Danny Thornton wrote:

To add to this comment:

 
So, it would appear that 

- most of these items relate to policy and, as

appropriate, should be referenced in the "policy

section" of the service description
 

The SLA will consist of those things that are

measurable by the computing systems and those things

that are not measurable. This also applies to all

policies/contracts. Looking at the measurables in the

SLA, when the SLA is consumed by the provider's

computing system, those measurables in the SLAs are

translated into policies (probably for a PDP) and/or

configurables.  The configurations are applied to

devices and services during the course of execution. 

The measurables in the SLA that were translated and

given to the PDP are checked at run time and can

result in changes to configurations of devices and

services to stay within the boundaries of what was

defined in the SLA.  The underlying mechanisms that

collect metrics on the system in support of the

parameters in the SLA can consist of many devices and

services.  As for those things that are not measurable

in the SLA, human intervention would be required in

the case of a breach of the terms of the SLA.

An SLA could be distinguished from a policy by stating

that SLAs result in configurables and policies whereas

policies are just policies and not configurables. 

Performance (QoS) is widely used in SLAs so we are

safe with classifying that as part of the SLA.  

Danny

--- Ken Laskey <> wrote:

 
Still chewing on SLA.

Jeff - was the Duke work done with SOA in mind or a

more general idea  

for IT delivery?  The Wikipedia article also seems

to indicate the  

general IT case:

Service Level Agreement (SLA) is that part of a

service contract in  

which a certain level of service is agreed upon. An

SLA is therefore  

not a type of service contract, but a rather a part

of a service  

contract. A service contract can contain zero, one,

or more SLAs. A  

contract containing SLAs is usually referred to as a

performance  

contract.

In practice, the term SLA is sometimes used

incorrectly in the  

context of contracted delivery time (of the service)

or performance.

The discussion of SLA seems to assume there is no

other description  

-- in our case, no service description.

Let's look at the list Danny provided (from

http://www.sla-zone.co.uk/ 

index.htm) because that seems (overly) exhaustive.

Definition of Services - while we haven't finished

tackling the  

details, this is definitely service description. 

However, I've  

recently seen this become another phrase for

requirements.  Other  

than the idea of description-driven development (I

tell you want I  

want and you agree to build it), is there a

rationale for capturing  

what were supposed to be requirements vs. what the

service actually  

does?

Problem Management - this is briefly the "process to

handle and  

resolve unplanned incidents".  This needs more

thought on how it  

relates to SLA.  My initial thoughts are:

1. Some handling of faults are based in the

infrastructure (e.g.  

messages dropped in transport) and need to be

resolved at that  

level.  The power utility does not give me detailed

of how they will  

handle downed transmission lines.

2. The more endpoint related remedies seem to be the

domain of  

lawyers.  To a certain extent, this is where the

UDDI model has run  

into problems because businesses don't get things

from other business  

without laying some groundwork for the business

relationship.   

Someone will have to figure what this means in the

SOA context  

because everything will grind to a halt if we have

to wait for the  

lawyers for every new service interaction.

So let's assume there are some standard answers here

and those are  

either embedded in the cloud, referenced as part of

the service  

policies, or agreed to and incorporated into the

execution context.

Performance Management - Briefly, this "deals with

monitoring and  

measuring service level performance".  I don't think

this can be done  

without reference to some form of NetOps (network

operations) or ESM  

(enterprise service management) that will be the

recognized agent to  

collect metrics.  It does not make sense to demand

things that can't  

be measured.

Customer Duties and Responsibilities - see Problem

Management, item 2.

Warranties and Remedies - definitely see Problem

Management, item 2.

    Service quality

    Indemnities

    Third party claims

    Remedies for breaches

    Exclusions

    Force majeure

Security

    Information Security Policies

    Security Audit and Internal Audit

Disaster Recovery - see Problem Management, item 1.

Termination - if the relationship has the unit of

per interaction,  

then termination is simply no more interactions. 

Beyond that, see  

Problem Management, item 2.

So, it would appear that

- most of these items relate to policy and, as

appropriate, should be  

referenced in the "policy section" of the service

description

- things specific to a particular set of

participants would be  

captured in the SLA, but don't overload this to

include all contract law

- things needing to be measured can be part of SLA

but they should  

coordinate with what can be measured

- things that are clearly description and are

relevant to any  

interaction no matter who are the participants

should captured in the  

service description

Comments?

Ken

On Jan 23, 2007, at 10:23 AM, Jeffrey A. Estefan

wrote:

 
Hey Ken,

This is certainly relevant to our service
 
description and service  
 
management models.  I mentioned SLAs in passing in
 
the service mgmt  
 
model but did not explicitly define it.  Recommend
 
keeping the  
 
adopted defn simple and consistent with our scope
 
(see, for  
 
example, the Wikipedia defn for SLA).  The
 
important point being  
 
that the SLA is "part" of the service contract and
 
not a "type" of  
 
service contract.  It's also important to
 
differentiate SLAs from  
 
OLAs and a decent distinction is captured at
 
http:// 
 
www.oit.duke.edu/oit/sla/index.html.

Cheers...

 - JAE

 

 
------------------------------------------------------------------------
 

------------------

Ken Laskey

MITRE Corporation, M/S H305     phone:  703-983-7934

7515 Colshire Drive                        fax:     

  703-983-1379

McLean VA 22102-7508

 

____________________________________________________________________________________

Bored stiff? Loosen up... 

Download and play hundreds of games for free on Yahoo! Games.

http://games.yahoo.com/games/front
 

 

 
------------------------------------------------------------------------------------------
 
Ken Laskey
 
MITRE Corporation, M/S H305     phone:  703-983-7934
 
7515 Colshire Drive                        fax:        703-983-1379
 
McLean VA 22102-7508