OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]