Service Level Descriptions for sysdev-owned services have been updated on the OUCS web site. This is an annual activity, typically falling in May/June, when SLDs for all OUCS services are reviewed, updated, and published. It is an opportunity for us to ensure that any changes to the service level offered are reflected in the SLD so that users and potential users of the service can assess its suitability for any given purpose.
Summary of Changes to Existing SLDs
This year we have focussed on making the SLDs more useful to end-users. With this aim we have improved several of the introductions/overviews to clearly state the purpose (supported business process) that the service is designed for, and to clarify the user support arrangements. The introductions typically include a link to a more thorough description of the service, and identifies (in our case) sysdev as the service owner.
Most of our SLDs now sport a clearer statement of the “Hours of Operation” to make it clear when the service is intended to be available for use, when technical support is available to deal with faults, and the usual schedule for any maintenance work.
Information about major outages is now contained in a “Disaster Recovery” section which provides two key details: (1) the state in which the service will be once it has been recovered (i.e. what data will have been restored), and (2) how long this might take. We hope that these will prove more useful than some dry technical details about what RAID levels and hardware models have been used to deliver this.
Service Levels Descriptions have been written for a number of services that have actually been available from OUCS for quite some time, but until now have not been decorated with the appropriate documentation. In some cases this was because the facility had not actually be recognised as a service, in others it was a simply case of priorities leaving this work far down the list of to-dos.
We have also started to provide a more complete description of each service. The Service Description and Service Level Description documents are complementary, with the first providing information about the purpose of the service and what it offers, while the second details the warranty under which the service is offered so that you can assess whether it is fit to use.
Our work here is not yet complete. During the updates of the SLDs this year we identified further areas for improvement, and there are still some inconsistencies that we are yet to iron out. Although we have written service descriptions for several of our more popular services, some are still missing. Perhaps the largest change is that we are planning to present the suite of services that support identity and access management as just that – a suite of IAM Services – rather than a piecemeal listing of the various technologies on which these sit.