6.1. Design inputs

The design process has a number of inputs from different stakeholders, the organisational profile you have been building will help to identify where those inputs are likely to come from. A good starting point for designing the MLE is to look at the plates already spinning to see what we can gather into the design. The design needs to be continually refined to ensure that it satisfies all the stakeholders' objectives over time.

The area of design inputs and outputs needs to be considered from three perspectives, organisational, technical and user.

6.1.1. Organisational

The organisational drivers for a design may impact at all levels of the design. It is in this area that the profile of your institution becomes very valuable. There may be a set of ownership issues with the data providers. The identification of what data sources exist and how they might be used, is a key input as this may be setting the limits in a number of other areas. The actual structure of your organisation is a good indicator of the types of issues you may face. As a rule of thumb the more distributed the organisation, and by that the number of autonomous systems it comprises of, the less likely you are to spot any organisation wide errors or problems. Conversely in a highly centralised organisation you may spot significant holes in systems though there are a smaller number of systems to actually integrate. It helps to conceptualise the organisation in a number of ways.

Both the GIMIS and INSIDE JISC projects are worth comparing for organisational culture, the first was delivered to a highly centralised organisation, the second integrated a wide range of systems from a highly distributed institution.

In many cases it can help to look at the different ways in which the organisation may be modelled, as this often identifies different key stakeholders and agendas. In 'Images of Organisation' Morgan articulates a number of different models it is worth considering, and Schoen in 'The Reflective Practitioner' provides different ways to think about the investigation of your specific environment. The area of requirements gathering also offers a lot of information on the socio-technical issues.

6.1.2. Technical

At the technical level it is clear that there are a number of different technologies and processes which could be used effectively. This may also be the domain of other systems specialists. The involvement of other technical users is often a 'religious' issue, if you choose a development, tool or language which is not the same as another expert group then there is likely to be some tension. There may be very good reasons why you choose a particular technology but, just be aware at this stage in the design, that this is where lines can start getting drawn.

The heart of the matter in this area is often about self image, this might seem strange from a technical perspective, but just as other ideological beliefs, such as political affiliation, separate people, technology can play the same role. If someone has always been accustomed to a particular approach, or to a technology supplier e.g. Microsoft, they will have invested a lot of personal time and effort in learning those technologies to build a skill set and a professional image. If someone else then comes along and says 'Unix is better', this can be very threatening. It directly calls into question the fundamental platform that the person’s professional ability, and therefore self-image, are based on. There is no single right answer, as all technologies just have different attributes, each has strengths and weaknesses. The key message is, do not assume that your perspective on the applicability of a given technology is shared or that it is fixed. Bearing that in mind and ensuring you are sensitive to these issues, will enable you to reap significant benefits from your MLE.

Pre-existing systems often exist in organisations, even though these may not actually be called an MLE. 'The student web database' may well be a prototype MLE, and as such, sensitivities may be well be present when your project is looking to replace the system. Tread gently with technical staff as often they have a particular view of the world which is not strategic but highly technical and highly creative in that environment. You may well be looking to replace a system that has taken ten years of their lives to produce. Do not expect such a major change to be stress free for an individual.

6.1.3. User

The user has already done a significant amount of work as part of the requirements gathering exercise but in addition it is often worth going back to the users to check details and gather comments, especially when it comes to areas where compromises need to be made. The user is the ultimate customer and the MLE you produce must bring real value to them or it is just a waste of money.

One problem is that we often talk about 'the user' in the abstract, however the diversity of users for an MLE is significant and you need to draw upon previous stages in the development to ensure that the design reflects these diverse and occasionally diverging needs. The actual resolution of conflict in the design will happen as the design migrates based on the iterations of discovery and testing. This is one area where each time this stage is revisited, to 'keep the plate spinning', that additional effort needs to be applied to identify and mitigate both risk and conflict.

As an analogy, consider the development of video camera technology. In the first generation the user had never seen a video camera and was happy to be able to capture footage and play it back on their TV. As experience and familiarity with a system grows then the user starts to demand more, a lighter weight camera, longer battery life etc. So the next iteration takes place. Now this first iteration could only deliver one of the above requested features as they were mutually exclusive, a lighter weight and a longer battery life. At this point you have two groups of users who differ about the most important development direction and so the tension rises. The analogy was designed to be simple but in your MLE the issues are likely to be far more complex without clear boundaries. This is the process where constant references to the other layers will pay off in building the big picture.

6.1.4. Databases

For a successful MLE implementation it is essential that the data sources involved, often databases, are well understood. The structure of the database and documentation of the interfaces is essential as often you will want to pull partial data out of the database for aggregation. Where there has been in-house development this should be easier. For some suppliers the structure of the database may well be one of their most closely guarded secrets. This is for two reasons, firstly there will often be significant intellectual property in the database and it would provide a significant advantage to competitors to know how to integrate products. Secondly, the supplier is often concerned that other developers will inadvertently damage the database being integrated and destabilise their software while attempting integration.

In terms of risk, the least risk is from harvesting data and this is unlikely to cause a problem, unless it places a significant load on the machine. The next highest risk level is from updating the database at this point in the design as people may well start to get concerned, either because you may destabilise the primary application the database was designed for, or you may accidentally destroy real data. The highest risk for database integration in the design is where the design proposes additional data to be stored in the primary application. It is recommended that this is avoided. The chance of destabilising the original application is very high. Often programmers use shortcuts or knowledge of the database structure when writing code. If you add a field to a database those shortcuts and assumptions will become incorrect and may crash the system.

6.1.5. Processes

The design process itself has to encapsulate a number of other processes. The designer in this context is behaving more like an architect in that a number of different design options will need to be assessed, these will then be worked up into a set of plans, with different plans being produced for different audiences, and these plans will be iterated as issues are identified and resolved.

Each institution has a different set of processes but it is worth identifying some of the key ones and providing a simple rule of thumb for the design process.The key processes are again in the organisational, technical and user areas.

In the organisational arena there are likely to be some organisational committees or similar who will want to have sight of the design and their processes and timings need to be taken into consideration. There may be a number of different committees who will have to agree about various aspects of the MLE, such as to agree the impact on the student experience in support of Teaching Quality or Audit requirements. There may be groups which oversee IT in your institution which again may need to be consulted.

There are also probably a significant number of business process which may be impacted by the design, and an understanding of the changes, an MLE will bring to working practices is vital. Follow this link to the infoKit on Process Review.

If there are pre-existing technical partners they may need to be consulted and have the opportunity to bid for any IT development work before the work commences. This is common where there has been a move to facilities management of IT systems and services.

User processes are many and varied, you will have to try and integrate their meetings and agenda into the design. The students union is likely to be very interested in the project and may request representation on the project and their processes may need to also be considered.

6.1.6. Technical specifications

As part of the design there are likely to be a number of technical specifications, designs and plans for existing IT solutions that need to be designed into ensure that return for effort is maximised. If the environment is complex there is likely to be a large number of existing systems. In the case of the INSIDE project, over 50 databases were identified for potential integration.

The diversity of technical specifications may mean compromises in the design due to issues of different technical strategies employed. For example if one database is based on Java and JDBC and another is based on Microsoft’s .NET products there may be a choice in the design over which technology is going to be the main platform for the project. The decision is not actually made at this point, it will usually either be a constraint on the project or it will be decided just before the design is realised.

There is very little advice available in choosing between technologies and the answer is often provided by the environment. It is worth looking to the institutions information strategy to see if there are any clear guidelines on choice. All technical developers will have an opinion on what to use.

6.1.7. Standards and Protocols

Andrew Tanenbaum is quoted as saying 'The best thing about standards is that there are so many to choose from' with regards to network protocols. A protocol is designed to provide a commonly understood and agreed way to conduct a process. These protocols govern many areas of our lives from the mundane, 'on which side does the knife go' when arranging a place setting on a table, to the highly technical protocols of how networks will operate.

Protocols can both help and hinder. In the design it is likely that a number of protocols will be considered for inclusion. These protocols can cover the business process, but are more likely to cover aspects of the interoperability between systems. These protocols are by their very nature not cutting edge. If a protocol exists, it usually exists on different vendors' equipment because it has been around for a while and by definition is not the latest greatest research technology.

The types of standards you may need to include in your thinking are:

• Database standards: ODBC, JDBC, Z39.50, SQL

• Programming Standards: Java, Visual Basic, C++, C, C#

• Network Protocols sets: TCP/IP, DECNET, IPX (Novell), AppleTalk

• File Sharing Standards: NFS (UNIX), ATF (Apple), SMB (Windows)

• Data interoperability standards: IMS, SCORM, MARC, RDF

There are numerous other standards, and all of the above list, are collections of standards rather than single standards. The key is to understand that where a pre-existing standard is in use in the design, there may be a requirement to integrate it and this needs careful consideration.

Follow this link for key resources for this section (these open in a new window)