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

[Danny Thornton <danny_thornton2@yahoo.com>]

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 <klaskey@mitre.org> 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