5.5. Risks
In an area developing as rapidly as this the selection of technology has a a range of risks associated with it. It is important to consider these risks and what can be done to mitigate them when selecting technolgies.
Risks fall into three categories:
Technology
Supplier
Environmental.
These are discussed in turn.
5.5.1. Technology
Speed of change of technologies
Technology is changing with enormous speed. In the last few years we have seen the explosion in the use of XML, the development of specifications in learning technology standards, the dramatic growth in the use of wireless networking and the continued dramatic improvement in price / performance of computers.
There is therefore the danger that any system selected will be rapidly overtaken by some new technology which renders the choice a dead end and result in the need to acquire a new system in the relatively near future.
The risks come from a number of areas:
Hardware - although this is changing and improving rapidly everyone is in the same position and therefore suppliers have to make their systems backward compatible or very few in the market will be able to use it. The major risk is that existing systems become unsupported and have to be replaced. This is not peculiar to MLEs and should be part of any standard risk analysis.
Operating systems - much the same as with hardware, except that it is at the operating system level that some systems will be interacting and there may be issues when large numbers of different operating systems (or versions of operating systems) are in place. It may be a particular issue in areas like disaster recovery where having a number of versions of the operating system can significantly affect the costs. Again, this is not peculiar to MLEs and should be part of standard risk analysis.
Languages - Many of the languages being used for developing systems are themselves evolving. If you are acquiring systems (and the supplier or other third party is maintaining them) then this is not a major issue. However, where you are developing or adapting existing systems then there are two major risks:
The lack of skills - There is an enormous shortage of skilled programmers and education is not a noted good payer. Recruiting and retaining the right skills can be difficult and this matters for a system which is mission critical
Adapting code to changing languages - As languages change some features may be withdrawn, or worse behave differently. However, it may not be possible to stick with old versions of the language. As systems grow this can become a major problem.
Poorly defined standards
This is covered in greater detail in the section on standards, but it is worth reiterating here. One of the fastest areas of change at the moment is the interoperability specifications, in large part because they are not yet fully defined. This has two serious consequences.
Things that claim to be following the same specifications may not actually work together. Currently it is essential that actual interopability is validated between any systems that are being considered. Even if they can demonstrate that they are following the standard (which is doubtful given the nature of the validation tools) this does not mean that the various suppliers are interpreting them in the same way.
The change in the standards. Most of the relevant standards are rapidly evolving as requirements are being better defined and further refined. This means that systems acquired at different times will almost certainly be using different (incompatible) versions of the standards and it is therefore likely that you will have to keep upgrading systems in order to make them work with new systems that you are installing.
Gaps and overlaps between systems.
When systems come from different vendors there can be gaps between what they offer, and there will almost certainly be overlaps.
As John Heap wrote in UCISA Update (June 2003) 'the number of overlapping feature sets becomes confusing and daunting - especially for the hapless end users. Let me give you a couple of examples. Within our particular version of a Management Learning Environment, we have adopted WebCT as our Virtual Learning Environment and SCT Luminus as our portal technology. Both of these have messaging facilities. This means that together with our email system, it becomes possible to send messages to students via a number of routes. The poor staff who happen to communicate with students thus end up wondering which of these routes is most appropriate for a particular type of message to a particular group of students. We have recently had to offer guidance on the appropriate use of these various messaging tools. Similarly, within our MLE, we have adopted CMIS as our timetabling system. We recently had a demonstration of CMIS v2 and, lo and behold, they have added a range of features which would normally exist within a student record system. This means that we have to be careful either to disable such facilities or to ensure that our end users do not start to populate these with duplicate student data.'
5.5.2. Supplier
Supplier viability
Supplier viability is a major consideration in any software or hardware purchase and there is nothing special about MLE components in this respect. However, many people are using open source systems as part of their MLE and as such they need to take the same care in looking at the long term viability of the systems. There is a long and unfortunate history of software being developed, released to the community and dying. A small number of systems will continue to be supported. The problem is to identify them.
A few pointers are worth mentioning here.
The size of the user community - the larger the community the more likely that people will continue to develop the system.
The importance of the system - even if the community is relatively small if the system is essential to some members then it is more likely that they will continue to support it (though not necessarily in a way which meets your needs)
Lack of alternatives - if there are good alternatives then other users will be more likely to switch and see less need to continue with the system.
Lack of cooperation between vendors of different systems
In the field of MLEs suppliers clearly need to work together at the moment as they are unable to provide all the parts of the solution that users need. This forces them to cooperate. However, you need to be clear as to the nature of this cooperation. Few systems vendors will have the resources to work with all the vendors producing complimentary systems. Although the systems may be made to work together now what guarantees are being offered that this will continue to be the case?
If one of the suppliers is extending the range of systems that they offer they may even have a reason to want to end interoperability with what will become competing systems. This is less likely if there is some formal relationship between them. Unfortunately that is unlikely to be the case between all the systems that you want to make work together as each of the relationships have to be built pair-wise while you want many systems to work together.
