[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] definition of SLA
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]