UCISA / UKOLN / CETIS Workshop:
Principles For IT Developers And IT Service Providers

About This Document

This "Principles For IT Developers And IT Service Providers" document provides a draft set of principles which are designed to help ensure that institutions can manage potentially disruptive technologies and easily deploy useful technologies into an effective service environment.

This document was discussed by participants at the Joint UCISA/UKOLN/CETIS workshop on "Initiatives & Innovation: Managing Disruptive Technologies" held in Warwick in February 2006.

Please note that an MS Word version of the document is available.

Draft Principles

For Service Providers:

• User Focus: Providers of IT services acknowledge that their role is to provide a service for the users.
• Avoiding Dogma/Ideology: IT service providers may choose to implement policies in appropriate areas (e.g. use of standards, open source software, preferred vendors, etc.) but should recognise that such policies may need to adapt to changing circumstances and should not be used as a means of avoiding engagement in dialogue with the user community.
• Willingness to Respond to Changes: IT service providers should be willing to change to reflect the diversity to be found within higher education and developments to the environment due to technical, political or cultural changes.
• Importance of Good Communications: IT service providers will ensure that effective communication channels are established and will monitor the effectiveness of the channels.
• Learning: IT service providers recognise that the user community within the HE sector will be continually seeking to enhance the quality of their teaching and learning and research services through use of innovations in IT.

For Developers/Innovators:

There is a need for developers and innovators to recognise that Service Providers - who may, if not now, sometime in the future be expected to provide a large-scale, resilient and robust service based on the developing technology/application - have genuine concerns about:

• Scalability: IT developers should recognise that although experimental approaches to new technologies which may work well on a small scale such solutions may needs changes to the technology or infrastructure if the prototype is to be deployed into production service (or, indeed, may not be usable in a large scale production environment).
• Sustainability: At developmental/experimental stages, developers often put in long hours both in development and in supporting the small, pilot user community. When the service transfers to production, similar support services must be in place - or the service is likely to fail. Similarly, developers can often 'find their way' around systems because of their very close contact and deep knowledge. Other users have to rely on help systems, effective navigation schemes, appropriate use of metadata, etc - these must be in place.
• Reliability: During development activity, a 'beta' quality of service is often quite acceptable - only the development team suffers and they are willing to pay this price. Service users do not expect and will not tolerate service interruption or low performance.
• Integration: During development, data entry can often be performed 'manually'. When a service targetted at, say, students moves into production there must be an effective, timely and reliable way of transferring appropriate student data to populate the new service.
• Consistency: Service providers may be supporting many disparate - but linked - systems. They much prefer systems which have some consistency of user interface and navigation since this considerably reduces the number of support calls. Similarly, the new service should integrate into any naming and authentication scheme which operates across existing systems. Finally, there is a tendency for systems to have overlapping features (many systems, for example, have some form of messaging built-in). Users can be confused by having several messaging schemes in the various applications they use - and need either firm guidelines on what systems to use for particular message types, or preferably the ability to turn some of these components off on a global level.
• Security: Service providers want to see that issues of security have been addressed. The nightmare scenario is of a new service being added which creates or exploits vulnerabilities in existing and hitherto secure systems.