Agility delivers accountability through its use of service agreements which record the responsibilities of the parties engaged in a relationship. With service agreements in place the organisation can monitor performance and can identify when quality of service is threatened in order to take remedial action. Any action taken may be independent of Agility or may be driven by automated Policy which has been registered with Agility, as we shall see in the next section.
A service agreement is an agreement between two parties and is used to define the obligations of each party typically, though not exclusively, with regard to service offered by one party to another.
Agility represents a Service Agreement as a set of Features, each consisting of a name/value pair. The semantics for the name and value of a Feature are entirely the concern of the two parties involved in the Service Agreement, and are transparent to Agility. Agreement is reached between two parties when both believe they understand the semantics of the Features contained within a Service Agreement, and agree that the agreement being proposed is both achievable and acceptable.
For example, a Service Agreement might contain the following Feature:
Feature: { "name": "Availability", "value": "Medium" }Perhaps this Service Agreement defines the quality of service requirements for a particular set of services offered by one organisation to another, and this Feature defines the required availability of those services. The level required, 'Medium', is pre-defined and known to both parties and might mean, in this case, 99.99% availability during office hours, and 97.5% availability otherwise. Capturing this information as a Service Agreement delivers a clear audit trail and also allows the opportunity for later modification. For example when about to begin a business critical activity the consumer might temporarily propose that ‘Availability’ be set to ‘High’.
The provider organisation will consider this proposal and, if it is achievable and acceptable - presumably involving a higher pre-agreed level of charging - will approve the modification. Once the business critical activity is complete the consumer can reset the level to ‘Medium’.
Service Agreements may be created within the context of another Service Agreement. Such an agreement is termed a 'child' and the agreement providing the context is the 'parent'. Child agreements are ones for which the parent agreement applies, but which may impose further obligations upon the two parties. For example, a child Service Agreement pertaining to ‘ServiceA’ (one of the set of services supported), created within the context of the Service Agreement described above, might contain the following Feature:
Feature: { "name": "DataConsistency", "value": "CorrectToToday “}The meaning of this Service Agreement is that, service A must utilise information that is correct as of today. Perhaps this requires the provider to take some action to actively update the relevant data in order to ensure it is completely up to date. Once again the provider has to ascertain whether the request is achievable and acceptable before agreeing. In figure 2, the parent agreement is the original Service Agreement and the two children agreements shown might concern the quality of service requirements for two specific services.
Agility comes with a portal that lets the administrator view all details of Service Agreements, as in Figure 3. As well as this real-time information Agility delivers a full audit trial which captures all changes to Service Agreements over time.
