5. Technology Options
A version of the core material comprising this section is available for download as a printable version in pdf format. (The Adobe Acrobat Reader to allow viewing of pdf files is available for download here).
Who should read this:
The first part is written for senior management, governors or council members as it concerns strategic decisions for the institution. The remainder is intended for staff from IT services, purchasing departments and potential developers.
Outcomes:
On completion you should have an understanding of the technology choices that need to be made, and the issues which need to be considered in making them.
Approach:
The aim of this section is to enable you to make the right choices for selecting and implementing the technologies needed for creating an MLE at your institution. It looks at the key issues which need to be addressed in selecting architectures and components of the MLE to ensure that they will fit into the growing MLE and continue to meet the institution's needs in an environment where the MLE is changing, the technology is changing and the institution's needs are changing.
Overview
So far you have been looking at whether or not to implement an MLE and if so what the requirements are.
Once you have gathered the requirements and resolved conflicts and prioritised them you start to think about their feasibility and cost, and then how they can be implemented.
One aspect of this is the technology choices that have to be made. These fall into three categories:
Whether to develop in-house or use a third party including outsourcing the entire operation
The overarching architectures to be used.
Selecting the individual components.
Each of these is discussed below.
This section looks at the technology options available for implementing an MLE. The choices made here will have a long term impact on the MLE as no technology or system will support everything that you might wish to do at an affordable cost.
It is assumed that by this stage you have already identified the requirements for the MLE, and you are now looking at the technologies and processes that are needed to support this. It is likely that not all your requirements will be fully met whatever technology is chosen so that you may have to re-visit the requirements or re-consider priorities.
Issues that need to be considered include:
How the technologies will integrate with existing systems at your institution
How the technologies will integrate with systems at partner institutions
How the systems will adapt as your requirements change
How well the systems meet the requirements
Total cost of ownership including: purchase, adaption, support and training
Long term viability of the systems
It is often easy to look at the purchase price, and to balk at some commercial prices. It is however essential to look at the total cost of ownership, which may be high if a large number of skills (and therefore people) are needed to support the system in-house.
In this section we first look at who needs to be involved in making these decisions, then at who needs to be involved in the various decision making processes, and the outcomes that will be achieved from the technology choices. Finally there is a brief discussion of the approach taken.
The rest of this section looks at two fundamental questions that need to be addressed at the start of the technology choice process before looking at appropriate methods for selecting the right technologies and systems.
A precursor to the MLE infoKit was a set of JISC MLE briefing papers. You may find it useful to read the technical paper from this set.
Types of approach
There are four basic ways in which the technology can be selected for building an MLE and a decision between these needs to be taken early on and at a strategic level.
The four are:
Outsource: this involves handing over all responsibility for IT (hardware, software and support) to a specialist company who run it on your behalf for a fee. Common in industry and government and used in colleges and universities in the US it is not widely used in FE or HE in the UK. The key advantages are that specialist organisations operate the systems and it is their core business, while IT is not your institution's core function.
Turnkey: Responsibility for the development of the systems, including hardware, is given to a single company which then has responsibility for ensuring that systems work before handing them over to you to run. The main benefit is if something doesn't work then there is a single place to turn to rather than the vendor of each subsystem (hardware, operating system, and individual systems) blaming the others for the problem. Turnkey approaches may cost more and have reduced flexibility.
Integrate - This involves buying the best individual systems that meet your needs, and then developing (either yourself or through a systems integrator) the functionality needed to link the systems together. The key advantage is you can select the systems that best meet your needs, the main disadvantage is the complexity involved in linking together disparate systems which work in different ways.
Build - Using open source software, or starting from scratch, it is possible to build all the systems you want to meet your precise needs. The advantage is that it can do exactly what you want it to, but at the price of having to bear the full development and support costs and not having a community to share problems with. Few institutions will want to entirely build their systems and will in reality purchase and integrate some of the systems they use.
Who should be involved and why
We now look at who needs to be involved in determining which of these approaches is most appropriate in the context of your college or university.
An initial strategic decision as to how the development should be carried out - between outsource, turnkey and integrate/build needs to be made at the most senior level. This is a decision which has implications for you and your institution for many years as both an outsourcing agreement and systems that are developed are likely to last for several to many years. As such it needs to be made by senior management, in conjunction with the Board of Governors or Council.
It is however rare for the full range of options to even be considered as individual systems are purchased as one-off decisions. It is equally rare for the IT director to be keen on outsourcing their empire. The result is that the decision is made by default to build / integrate in house.
If it is decided to go for outsourcing or a turnkey solution then a small team of senior managers will have to make the selection, supported by staff from IT services and purchasing and advised by the same people who will be more actively involved if an integrate / build approach is taken.
We now look at who needs to be involved if the decision is to build or integrate systems in house.
Two types of decision need to be made here:
System architecture - primarily whether to go for open standards or a proprietary architecture.
Individual systems - the components that make up the MLE.
As with so many aspects of the creation of MLEs involving the right people will be critical to ensuring their buy-in to the project, and thus its continuing success. Most people are resistant to change, but when they have been involved in the decisions they are much more likely to accept the system and work with it, making the implementation and embedding considerably easier.
Unless you are going for a turnkey solution, where all the systems and their integration are handled by a single supplier (who may use their own products or integrate other people's) there will be a series of decisions to be made covering the architecture and the individual systems that will be included within it.
There are therefore three types of technology / vendor selection that can be made:
Turnkey solution
Architecture selection
System selection
This is a massive, strategic decision, which will cost millions of pounds to implement in a university and hundreds of thousands to millions in a college. As such decisions will have to be made at the highest level, involving principals or vice-chancellors (or their deputies) and boards of governors or their equivalents. Because an MLE cuts across nearly all departments in an institution, and must meet all departments needs (and some of their wants) it will be important to involve the key decision makers in all areas including:
Turnkey solution
learning and teaching - MLEs have a significant impact on learning and teaching and the head of learning and teaching will need to be actively involved to ensure that the system actively addresses the institutions learning and teaching strategy. An MLE provides opportunities for improving student support, assisting with progression and addressing e-learning.
registry - many of the systems that will be integrated within an MLE are owned by the registry, and there will be a big impact on how they work as the development of the MLE changes the nature of the way systems operate and who has access to and may enter and amend information.
student services - Creation of an MLE will have a fundamental effect on student services. More and better information from disparate sources will be available as needed, and delivery can be integrated with other functions.
estates - if automated timetabling and space allocation is included within the MLE then estates should be involved.
council / board of governors / senate - a decision of this magnitude which will have a significant effect on the institutions's medium term development, and council or the governors should have a significant say in such an important decision.
IT services - should have an advisory role. This is not primarily a technology decision, and it would be a mistake for IT services to allow itself to lead the project here. While the technology is important and IT services need to have an input the development of an institutional MLE is about driving the institutional strategy and thus the project needs to be led by strategic decision makers and not from the technology.
Users - Users should be involved in all stages of the project. If the system does not meet their needs then they will resist, and in some cases may be able to put the project at risk through non-cooperation. As in all areas care needs to be taken to include more than just a few keen people and to draw in staff from a variety of departments and levels of interest in the work.
Representative from partner institutions - closer integration of systems in regional consortia is growing, it will therefore be useful to involve someone from one or more of the partners to ensure that the systems can interoperate successfully. If you have a "round table" then it would be advisable to use that too. Follow this link to read more about Roundtables.
While the selection of the architecture is primarily a technical issue it will have a major impact down the line as it limits the systems which can then be integrated. One area where many institutions are trying to rationalise is on the operating systems used for central services, with some trying to move to a Unix, and others moving towards Microsoft. Either of these systems will limit the systems which can then be used to those that can be implemented on that architecture. Even the selection of standards will impose a limit on the possible selection systems. Thus, architecture selection is not neutral and everyone needs to understand the effect that these early choices will have on the MLE down the line.
Architecture selection
The selection of the architecture will have to be led by IT services staff who have the competences to understand the technologies involved and their implication for the development of the MLE. However, members of other departments need to be involved to ensure that they are happy with the results and their implications. A couple of examples will illustrate this. The security architecture needs to meet the needs of all departments, and some - such as registry - will need to be comfortable with the decisions made if they are going to make their information available to users elsewhere.
You also need to think about future requirements e.g. does the architecture allow for users to update as well as read data from central databases? You may start out by having centralised data input but there is likely to come a time when the automated input of student marks from VLEs or directly by teaching staff is required. The architecture must enable this even if the functionality is not initially used.
The closer integration of institutions in regional consortia is growing and this involves closer integration of supporting systems including those that make up the MLE. If you have regional pertners it will be useful to involve your partners to ensure that your systems can interoperate successfully.
System selection
Systems selection is covered in a seperate infoKit. The issues are little different when the systems are part of an MLE. There is, however one difference to be borne in mind. The integration of systems is fundamental to the MLE and the numbers of departments and users involved goes much wider than in choosing standalone systems. Follow this link to view the System Selection infoKit.
