If we look at most “Managed Learning
Environments” today, whether implemented or
planned, they tend to look something like figure 1:
Figure 1: Architecture of a Managed Learning Environment today
So, we have three main systems occupying
the main vertical spaces within an
institution, and maybe some portal that links the functions together at the end-user level.
There is usually some amount of communication between the components, which
becomes more obvious when we open up the boxes to see what these components
actually contain as shown in figure 2:
Figure 2: Architecture of a Managed
Learning Environment today, expanded to
show the components they contain
The communication going on between the
components is often because there is
considerable overlap of functions and data within the components. Each system tries to
manage authentication (making single sign-on more difficult), and each system
maintains a complete picture of courses, groups and student enrolments. These
overlapping functions mean a lot of data replication is needed to keep the parts in
synchronization.
Figure 3 shows the effects of moving the
shared functions out of the applications and
making these common functions, available to any application that needs them.
Figure 3: Architecture of a Managed Learning Environment with common services
moved
out of application
Several things have now changed:
- There is no need to replicate data – all the applications are using the
same common
data sources
- The individual parts of the MLE are a lot smaller – therefore they contain
a lot less
actual code, so should be cheaper and easier to write and maintain
- The shared parts of the MLE need to have very well defined interfaces so that
our
main application components can all make use of them.
Now, it may not be the case that we physically
remove all the packages of functionality
from the applications – we may simply choose to let one system provide each piece of
functionality as a service instead. It may also be the case that we can’t make some of
these common functions into shared services - for various reasons - within a particular
institution (for instance, because some of the existing systems cannot interface to
external applications in this way due to their design or because their particular
requirements are not addressed by the common service).
When we embark on this kind of analysis,
identifying the parts of the MLE at a more
granular level than monolithic systems, then we eventually end up with a framework of
service descriptions. We are no longer interested so much in replicating data between
large systems, but instead focus on what kinds of services are needed in the overall
architecture to provide certain kinds of behaviour from applications.
What advantages does this approach have
over the “giant components” approach we
started out with?
First, we reduce the risk of our investments.
MLEs, including VLEs, are still very young
and rapidly changing. However the costs of changing components is very high as the
lack of a common framework and subsequent architecture means that replacing
components as needs change is complex and difficult because of the large amount of
work that is needed to integrate the replacement into the existing architecture.
Second, we no longer specify the actual
architecture of an MLE in terms of its
components, but only concern ourselves – at a JISC level - with the shared services that
provide its functions. This means that institutions have the flexibility to build an MLE from
components of any size and aggregation and yet still take advantage of standardisation
efforts.
Third, institutions, vendors and the open-source
community can contribute solutions
from a much lower cost base. Because components can deliver a small set of functions
yet take advantage of a great deal of shared services (e.g. Authentication, Authorization,
Course/Student information) the application code is smaller, easier to develop, easier to
maintain, and easier to port between institutions which have been using the framework
for their service infrastructure. At the moment, every application has to effectively build a
replica of the institution infrastructure internally. This also means we enable applications
to be developed that support a broader range of user tasks, including those tasks that
span multiple areas of responsibility (teaching, information management, administration).
Fourth, Because of the reduced cost of
entering the market as developers do not need
to build all the services needed for their application there will be a greater diversity of
services available to meet a wider diversity of needs.
Fifth, we begin to share a vocabulary
with which institutions can discuss the technical
aspects of an MLE, enabling sharing of best practice, and facilitating collaborative
development.
Finally, by opening up the “black
box” of the VLE and other major components, we make
possible a far more diverse range of approaches to e-learning within institutions without
sacrificing either interoperability or the ability to collaborate and reuse resources and
software.
