6. MLE Design

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:

people who have been charged with delivering an MLE to an organization. It will also be of significant value to a project manager wanting to acquaint their development teams with the key differences from other systems development and design approaches.

Outcomes:

On completion you should:

have an awareness of the key issues and concerns for the designer,
be able to outline a flexible design process,
be able to identify key tools and approaches, and
be able to identify key deliverables

Approach:

This section aims to provide you with a set of concepts and tests that can applied when designing an MLE. These concepts and tests have been derived from a wide range of experience in the design of MLEs and related systems.

Introduction

The process of design in IT terms is very often treated as an engineering problem much in the same way that a bridge might be built. The idea of having one goal right at the start does not fit into the reality of MLE design. This fixed goal construct can lead to a number of problems in the design of a MLE.

The major problem that you will have when designing a MLE is keeping an eye on the ball. The MLE is not a single thing; it is a delicate and often conflicting web of technical, social and political issues which have to be resolved to an acceptable level. In very few circumstances will a single technical solution actually deliver a useful product for your institution.

The development of a MLE is like a very long term plate spinning exercise. The trick is to get all the plates spinning and keep them spinning throughout the development process. All elements of MLE development are linked together and a successful design is a product of successful implementation of all the other stages both before and after. It is more useful to think of your project in layers that interact rather than solely in stages. This is the inverse of the waterfall model where stage 'a' follows stage 'b' and more difficult to explain and model.

As we explore the design process only the key interactions will be highlighted, you must remember that all the plates must be kept spinning and that the process is highly individual. The amount of effort you need to put into keeping each plate spinning will vary for each institution depending on a wide variety of factors. The level of organisational integration will have a big impact - if the institution is highly centralised then some plates will need more attention, if the institution is highly distributed, again a different balance of effort is required. The other top level thing to bear in mind is that there is no one magic technical bullet to solve the problems, as each institution is different.

The design process itself needs to be constantly in a state of change. The design of an MLE needs to reflect the user needs, and institutions never stand still. Even though we talk about design, this means different things to different people; and there are a number of elements you need to consider in thinking about it.

Firstly, what is in a design? The answer is that there is never only one design but a whole raft of different views of the architectural whole. In the world of architecture, for a new house, we could expect to see an overview for the clients, a plumbing diagram for the plumbers, a wiring diagram for the electricians and so on. The problem with an MLE is that it is not one single thing but a series of agreements between systems, all of which may be evolving at the same time.

In this section we will look at different ways to manage the design process to generate the required outputs to drive the development processes. This may sound like a linear process but the truth is that design, build and the other stages are constantly being reintegrated as new pressures emerge and are resolved, so design changes user expectation, which changes other systems and so it carries on.

These core topics provide a high-level view of the design process, from sources of input through to deliverables:

Design Inputs: This is an overview of the inputs to design - organisational, technical, user and so on.
Design Criteria: This section covers some of the core criteria for MLE design, including usability, user requirements, security, and some of the constraints on design such as legacy systems and legal issues.
Design Process: This section looks at some of the broader design issues such as architecture, interfaces, and design methodologies.
Design Outputs: This section looks at the deliverables of the design process, such as specifications and documentation.; The following topics cover some specific areas of design important for MLEs in more detail, including practical advice, and resources such as design patterns that can be applied to a number of situations.
Tools and techniques: This section looks at tools that can assist in the design process, including the use of the Unified Modelling Language for diagramming.
Domain Models: This section provides an overview of how the outputs of the requirements process are translated into models that can inform implementation.
Architecture: This section provides an overview of some common patterns for technical architecture, which can be used as the design template for the architecture of an MLE or be the focus of discussion about the overall technical direction of an MLE design.
Interaction Design: This section covers the design of the interactions between users and the MLE, including usability, labelling, navigation and structuring issues.