Agility puts control into the hands of an organisation's administrators through its support for pluggable policy. Policy is a set of rules or guidelines that direct an organisation's behaviour. Within an Agility Server, Policy is structured as one or more Policy Modules. Multiple Modules can represent different aspects of an organisation's policy, or represent the interests of different actors within the organisation, or be concerned with particular events. For example one Policy Module might be concerned with legal aspects, another with financial auditing, and yet another with green issues.
Policy in Agility has two functions, the first of which is the management of Service Agreements.
Policy interacts with the Agility Server through a Policy API. By this means Policy Modules can control which Service Agreements are to be entered into, how they may be modified over time and under which conditions they may be terminated.
A change to a Service Agreement proceeds as follows:
The Policy API requires that each Policy Module implements a listener which is capable of accepting the 'Proposed change' and 'Finalised change' events. All Policy Modules registered with an Agility Server receive those events and all may vote in the outcome of any 'Proposed change'. Modules must vote 'accept', 'reject' or 'ignore'. The proposed change will be accepted if at least one Module votes 'accept' and no modules vote 'reject'. By this means all Policy Modules within an organisation get the opportunity to have their say in any proposed change. That said, particular events will be of concern to particular Policy modules only and it is the default behaviour for a Policy Module to 'abstain' with regard to changes which are not of direct interest.
Policy's second function is the management of the organisation with respect to Service Agreements.
Policy can interact with the organisation in order to report on the progress of the organisation with respect to its Service Agreements and/or to modify the behaviour of the organisation in order to ensure conformance with its Service Agreements. The implementation and behaviour of Policy Modules are not restricted by Agility, beyond the requirement that the Policy API be supported. Policy Modules can interact with other Policy Modules, processes, human users and data in whatever way they see fit. The overall behaviour of the organisation will however need to be directed by the organisation's requirements to meet their Service Agreement obligations and the understanding of the business, financial and legal implications of failing to do so. Agility does not in any sense 'enforce' Service Agreements or define how the organisation should behave. Agility simply records and reports on changes to Service Agreements as they occur.
Policy Modules may be added, replaced and removed at run-time. The addition or replacement of Policy Modules within two organisations can enable them to communicate with forms of agreement not envisaged when the system was first deployed. For example: new Policy Modules which are able to consider energy consumption could be added dynamically to reflect the organisation's responsibilities with regard to new carbon-reduction legislation. A new Feature 'Max Daily Energy' could then be added to the Service Agreement between two organisations and used to agree the maximum daily consumption of energy consumed by the provider with regard to that Service Agreement. This Feature would be ignored by previously registered Policy Modules but would only be considered by the new energy consumption aware Modules. The new modules would enable agreement to be reached on energy consumption and could implement monitoring capabilities to enable reporting of usage, and ultimately could even be used to influence the choice of resources utilised in order to reduce energy consumption e.g. by choosing modern, low-power servers in preference over older ones.
This ability to extend and modify the semantics of agreement is an essential feature of Agility, enabling the organisation to cope with inevitable change. For Agility it has been a deliberate design decision not to attempt to create a universal ontology for Service Agreements. Systems which attempt this approach tend to be hard to adapt and maintain, because there are an impractically large number of things on which agreement might need to be reached and even when a small set exists between a set of parties it is (almost) inevitable that changes to that set will be required over time. That said Agility does not prevent a group of organisations from utilising, or even enforcing, the use of their own specialised ontology.
