5.4. System Selection
5.4.1. Introduction
Selecting the systems and technologies to be used is one of the critical stages in MLE development. It is little different from the selection of systems and applications that you have already been doing. The difference is the importance of the systems working with other systems within and beyond the institution with the additional requirements that this brings and the wider set of stakeholders involved. Follow this link to the System Selection infoKit.
Selecting requirements is not a one time operation, and is best thought of as an iterative process as shown in the diagram.
You will need to consider the user requirements, the flexibility of the system, trends in hardware and software (including standards) and the legal requirements. Using these to evaluate the systems and select what you want. The systems will then need to be implemented (and this includes modifying the software to your needs and almost certainly modifying some of your processes as well). having implemented the system you will then over time want to optimise it in various ways to meet your needs better. There should then be a review process and the cycle starts again.
5.4.2. Functional requirements
Clearly, the most important (but not the sole) selection criterion must be the functional requirements for the applications. Unfortunately, it is most unlikely that any system will meet your requirements precisely and that you will have to either adapt your requirements to the available systems or modify the systems to meet your needs. Typically there will be a bit of both adapting the systems and adapting requirements to the systems as the cost of making the adaption to the software may not be cost justifiable.
5.4.3. Long-term support and development
It is important to ensure the long term viability of any systems selected, whether built in-house, developed from open source systems or bought from a vendor.
- In house
- You must ensure that you not only have the requisite skills to build the system but that you will be able to retain them to continue developing and supporting the system.
- Open source
- Care is needed if you select open source systems. The vast majority of such systems do not develop a large user base and ultimately stop being supported and developed. In looking at open source systems it is therefore important that you look at the size of the installed user base and the amount of activity in support of the systems. Almost all open source systems have discussion boards etc. associated with them. A good idea of the level of support can be obtained by looking at these. look for the level of activity but also the speed of response to queries, problems and bugs. With the most popular systems the response time is usually much better than from commercial software. Thought also needs to be given to the development of the system. Of course, development and adaption can be done in-house (and as with in-house development you will need the requisite technical skills), but good open source software has a large community of developers who are continually improving and upgrading the software. However, this may mean that you have little control over the direction that the software takes.
- Bought from a vendor
- Besides all the usual things that one has to consider (such as the viability of the company, provision of support etc.), it is essential to look at their development plans for the system. Many of the systems you are looking at will be designed for other markets as well as education. If education (and in particular your sector) are not a major part of their market then are things that are a priority for you going to be a priority for them. For instance, when the funding bodies change the reporting rules will they be in a position to amend their system accordingly?
5.4.4 Integration with other systems
Creating an MLE is more about linking systems together than anything else so the ability to integrate a system with other systems that make up the MLE must be one of the key criteria.
5.4.5. Integration with partners
The area of working with partners both within sector (FE-FE and HE-HE) on a regional basis and between sectors (FE-HE) is an issue of growing importance, this will increasingly mean that the systems of these institutions will need to work together. We are already seeing courses jointly provided between FECs and HEIs and where this involves the use of VLEs (as it increasingly will) there is a need for the systems at all the partners to communicate with the chosen VLE (or more likely VLEs). Further, to support progression and cross charging there will be a need for a variety of systems to work together.
It will be very difficult to add this in later, if it is not considered when choosing the technology, and strongly suggests the need to use open standards, unless all the partners agree on some other approach.
The standards will be needed at a variety of different levels:
Transport mechanisms for exchanging data (such as SOAP)
Data formats (such as XML specifications from IMS)
Semantic (what data will be transferred)
An approach which might be considered is the use of web services which are specifically designed as a standards based approach to creating shared applications.
Students and staff will also increasingly be working for several members of the consortium there are therefore considerable advantages in using common systems / components.
Systems may also need to work with those of local industry, funding councils, HESA etc.
5.4.6. Fit to strategic requirements
We have already seen the importance of establishing strategic and user requirements. However when selecting the technologies there are likely to be a number of compromises which have to be made because of the nature of existing systems and the availability of suitable technologies. For instance, it may be technically necessary to do some of the low priority (from an institutional viewpoint) developments first in order to derive the greatest benefits elsewhere.
The most obvious example here is the necessity of developing the directory systems which underlie so many of the other systems and is an essential part of building an MLE. It is worth noting that in the Building MLEs in HE programme every project is using an authentication service based on, or compliant with, LDAP. More generally there is a need to recognise that progress towards an MLE is evolutionary and that the may be a need to switch out some systems earlier or later because of their technologies and how they can therefore be integrated into the MLE.
