Planning An End User Service

Background

For some projects, it will be clear from the start that the intention is to transition the project into an end-user service, either hosted by the project itself, or by another host such as a national data centre.

Other projects may have the potential for development into a production service, but without this being a declared aim of the project.

In both cases, it is sensible to think carefully about how the system might fit into a service environment at the planning and design stage, to avoid costly re-engineering and retro-fitting of features later on.

Software Environment

The software regime that may seem most appropriate for an experimental development environment may not be the best choice when running a large-scale end-user service. Issues to think about include:

• Software versions; does the software development environment you are intending to use match the versions that are in general use on service delivery platforms?
• Do you have a strong reason for using commercial products (e.g. database management systems)? If so, check to see if there are likely to be high costs when employed in an environment with large numbers of concurrent users. Try to select industry standard public domain products for preference.
• Are the systems you are intending to use supported by the major national service providers? This will be an important issue if they are expected to adopt your project and host it for you.
• Is your project likely to have to integrate with a family of similar products or services? If so, try to ensure that they have compatible operating environments.
• When in doubt, consult with others. Make sure that you do this before development work starts to avoid costly reversals of policy at a later stage.

Consultations

A key factor in the success of any project is careful preparation and planning. If you intend your project to develop into an end-user production service, it is worth spending time and effort in the early stages of the project testing your ideas and designs. It is easier to rewrite a specification document than to re-engineer a software product.

Depending on the nature of the project, some of the following may be worth considering:

• Surveys: Carrying out a survey of needs and expectations from typical potential users/customers.
• Brainstorming sessions: Getting together a group of people interested in the outcome (representing your customers) and carrying out exercises to identify the features and facilities that are most important to them.
• Consult other JISC service creators: Their experience may help you avoid pitfalls.
• Wireframes: Mocking up a series of screens with active links so that the general functionality of the service can be demonstrated is a powerful way of testing the structure of the service before committing to a full implementation.
• Prioritising: Not all functions and features will be equally important. Rank them so that you ensure that the most important ones are implemented first. You may decide to relegate some of them to a 'further development' phase.
• Document your design: Ensure that all parties concerned agree to a written specification of what you are aiming to create.

Authentication and Authorisation

Controlling access to your service may not be an issue when it is in an experimental or development phase, but will become an important consideration if it is released into service.

Some issues to review include:

• Is your service likely to be free or charged for? If it is likely to be free, is this open-ended, or does it depend on central funding? If the latter, what will happen when the funding stops? Will you then need to introduce a subscription fee and, therefore, access controls?
• Even if you expect your service to be free, there may be restrictions on who can use it. For example, the funding of the project may require you to limit access to UK only or higher and further education only.
• Bear in mind that, even if the service is free to UK users, there may be an option for charging for access by non-UK education sector users.
• If you decide you do need to build in access control mechanisms, are you going to use Athens?Athens [1] now supports single sign on (AthensSSO), meaning that users can access several different compliant services with only one password challenge.
• This is a developing area and, depending on the timescale of your project, you may need to keep a watching brief on issues such as the potential for using digital certificates, and Internet 2 related activities such as Shibboleth [2].
• Are any of the remote resources your service depends on IP authenticated? This can cause confusion for users, especially if they are accessing the service from off-campus.
• Even if you don't expect your project to become a service with controlled access, it would be wise to bear in mind that this could happen in the future, and to structure your service so that an access control mechanism can be easily fitted in at a later stage.

Legal Issues

When your project reaches the stage of being turned into an production service with large numbers of users, consideration will need to be given to issues which are less important during the development phase.

It is helpful to be aware of these at an early stage in the planning and design of the project to avoid difficult problems later. Some things you should think about include:

• Copyright material: are you thinking of incorporating items such as images, artwork, extracts from publications, sound or movie clips. If so, are there going to be copyright or IPR implications of making this material more generally available? This can apply not only to Web site material but also printed promotional material. If you have a choice, try to select clipart etc that is in the public domain.
• Accessibility: there is government legislation that needs to be taken into account when designing a new system. You need to think carefully about how your system might be used by those with special needs or disabilities. The JISC TechDis service [3] provides information on how to make your Web site conform.
• Consult the appropriate QA Focus document on Accessibility Testing [4] and the JISC Legal Information Service [5] for a range of advice on issues such as Data Protection, Freedom of Information, Disability and the Law, Intellectual Property and much else.

Planning for Maintenance

It is to be expected that a Web-based user service will require maintenance, revision and updating during its lifetime. There may be requests for new features, or for modifications to the way existing facilities work.

Bear in mind that the people doing this work may not be the original project team that created the service. It is important that the end-products are designed and structured in such a way as to allow parts of the system to be modified and updated by others who are less familiar with the system without unexpected consequences.

Therefore, when starting to develop a new system:

• Ensure that you structure the system in a modular fashion.
• Document as the work proceeds, not after the project is complete.
• Note any software environment dependencies or support products including versions/releases.

References

1. Athens access management services,
   <http://www.athens.ac.uk/>
2. Internet 2,
   <http://middleware.internet2.edu/>
3. TechDis,
   <http://www.techdis.ac.uk/>
4. Accessibility Testing, QA Focus briefing paper no. 2, UKOLN
   <http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-02/>
5. JISC Legal Information Service,
   <http://www.jisclegal.ac.uk/>