6.2. Design Criteria
In the first part of this plate spinning exercise we have gathered all the information and organisational context together to build a rich picture of the environment both human and technical. In Checklands book the first 2 chapters give another perspective on the problem of modelling situations and particularly about the role of the big picture. The next stage is to set some criteria that you need to achieve. It is easy to focus on the functionality of the design at this stage, and while functionality is vital, there are a number of other criteria which need to be considered. Getting the balance right is a key issue.
6.2.1. User requirements
The key area for design to focus on is the user requirement; does it do what the customer wants? Does/can the customer know what they want? The requirements gathering processes should be tracking these, and a well understood approach needs to be taken to reflect these requirements into the design and at the same time provide timely feedback to the users to identify areas where the costs may be too high or be simply impossible.
The process of ongoing feedback is the responsibility of the project manager and she should be planning a communications strategy to support that. In the case of the JISC project MARTINI they sent out monthly email bulletins to users keeping them up to date on progress.
The process of gathering user requirements is intimately involved with this and these should be integrated to deliver best value. See the section on 'Requirements Gathering' for more.
6.2.2. Usability
An area often overlooked, is usability. Usability is the part of the design process that actually deals with what the user sees. This may be the selection of the taps in a bathroom in a building design or the user interface of your MLE. There are a number of well known approaches to ensuring the thing is usable and projects like the one at De Montford University took a very useful approach to delivering usability for students with a considerable amount of effort being put into the interface design. For an overview of the topic you should read Donald Normans' 'Psychology of everyday things' which provides a very accessible understanding of user centred design. You should also look at the websites for groups working in this area specifically http://www.killersites.com/.
Usability is part of the iterating design and often neglected by technicians who feel that design is a secondary consideration to functionality. Users may not share that perspective and a system the users will not use has fallen at the first hurdle.
6.2.3. Security
Security is a thorny issue; it is a cost on the development effort and has very few obvious end user benefits. However, security is a key problem as much of the data in your MLE needs to be kept secure on both moral and legal grounds. Security needs to be included at the design stage. Almost invariably, if there is a breach in security it is due to later adhoc security measure being added rather than considered at the time.
Most projects do not consider security a design issue, however the De Montford University MLE project provided a very secure approach to transactions with key systems to minimise the possibility of a security breach.
6.2.4. Testing
The design itself needs to include both processes for testing the design, and access points to allow testing as the system is being developed. End user testing particularly is vital as the design plate needs to be kept spinning; testing and evaluation are the key processes to keep that happening. User testing is closely linked to the quality of the interface and for many MLEs the quality of the user interface will define the quality of the testing processes.
A good development methodology will have a rigorous testing process included within it. Follow this link to the Project Management infoKit to read more about User Acceptance Testing (UAT)
6.2.5. Maintenance
Maintenance is a design issue, it is often thought of as the thing that happens after the system is delivered whereas, in fact, it starts on the first day. Maintainability has to be considered as a design goal, if the system cannot evolve to meet the changing user needs then it will die. Maintenance is about designing in processes to minimise the maintenance costs. You can do this by ensuring that documentation is up to date and that there is an agreed process for checking its correctness, this maybe having someone else come in and check it.
Most JISC projects developed or borrowed documentation practices from their organisations or the methodology they chose.
Other areas where you might have maintenance issues may be in the complex interoperability areas. To maintain the system you need to build a process to track the core suppliers and their products for changes, this about ensuring the 'where are we now?' plate is kept spinning and relevant.
6.2.6. Functionality
Finally, there is the functionality of the MLE. So far you will have looked at a number of, what might appear to be, side issues in the MLE, but they are just as important as what the thing does. The user requirements gathering process is the key for functionality criteria, does the MLE satisfy a user's requirements?
You will also gather functionality criteria from all the other process as well. This is a bit unusual as we tend to see the users' needs as paramount. You need to work out what functionality is needed to support all the systems you are integrating, what functionality would be required in a management interface to reflect a change in your institutions organisational structure for example?
At the end of gathering all these criteria you will have to agree a process for sifting, prioritising, removing and reporting all these criteria to ensure that everyone knows what the goal is. Communications with the other spinning plates, and stakeholders (including suppliers) is vital at all stages.
6.2.7. Constraints on the design
There are a number of factors that will constrain the options available to you in the design process. A few common ones to consider are: Legacy applications and procurement cycles. The environment of the MLE will almost always contain legacy applications, which constrains the design options in a variety of ways:
Legacy applications may consolidate a lot of data in a monolithic form, when the desire is to create a component-oriented design
Legacy applications may only support file-based or screen-based interaction, when you want to use inter-application technologies such as Web Services or RMI
Legacy applications may enforce workflows which are inefficient or ineffective
Procurement cycles for some applications can be very long
There are a number of ways to deal with legacy applications:
Incorporate the legacy application and its constraints into the design, compromising in some areas to accommodate it
Encapsulate the functions of the legacy system with new adaptor components, such as J2EE servlets, that expose its capabilities using newer technologies. Eventually, the legacy system can be replaced when all dependent applications talk to the adaptors instead of directly to the legacy system
Plan the replacement of the legacy system within the design
6.2.8. External partnerships and agreements
An MLE does not stand in isolation - any institution will have connections (whether automated or not) with a wide range of partners and associations; for example, UCAS, the FE funding councils, HESA, the NLN, and other official bodies. Also, many institutions operate within local consortia, often of both FE and HE institutions.
Because of these external relationships, there will be constraints on the types of information that you need to gather, store, and provide access to. There may also be constraints on the kinds of process reengineering that is possible, in order to maintain harmony with a broader consortium.
6.2.9. Legal obligations
There are legal constraints that need to be understood within the design process. The main ones relate to freedom of information, data protection, and accessibility (SENDA). Follow this link to the Records Management infoKit to find out more about FoI and Data Protection. JISC Legal is available to give free advice on legal issues.
6.2.10. Capabilities
The technical capabilities of institutions are a factor, as is the degree of outsourcing they are able to manage. Custom software and configurations need to be maintained, so this must be planned for. It may be the case that there will be no capability for supporting custom solutions, so the design is limited to what can be achieved using off-the-shelf products.
Follow this link for key resources for this section (these open in a new window)
