6.7. Architecture
This section builds on the section on technology options (x-ref), and offers different styles of technical architecture that we can use when constructing an MLE design.
When designing system architecture, it is usually a good start to look at what existing architectural 'styles' are in vogue, and to see if they apply in your case. By choosing a basic approach that is commonly understood in the broader technology industry, its usually much easier to source products, tools (and personnel) that understand what you are trying to achieve.
There are five basic styles of architecture with relevance to an MLE, outlined in the sections below.
6.7.1. Service-Oriented Architecture
The most pervasive model in the industry today is the service-oriented architecture. In a service-oriented architecture, we take the standard n-tier model of software...
...and add another layer, called the Services Layer, which is interposed between presentation and business logic:
Just as in the n-tier architecture, the business logic layer prevented the direct dependency of presentation logic on the database, so a service layer prevents the direct dependency of the presentation layer on the business logic. Separating presentation from data representation allows changes to be made to the database without affecting presentation; separating presentation from business logic allows the applications that deliver functionality in the architecture to be modified or replaced without affecting the presentation layer.
Or, to put it another way, you can replace or update applications without affecting portals or websites.
In an MLE, the services would tend to be things like Authentication, Authorisation, Course Management, Grading, Content Management and so on. An example service-oriented MLE might look something like this:
Note that, for the operation of the portals and applications at the top layer, the applications used to provide the service are invisible, and these can be replaced without any recoding or redesign taking place. It is also possible to add on more applications and portals at the top layer without requiring any changes deeper down the stack, which is a problem that affects more traditional EAI approaches (see below).
Service-oriented architectures are almost always based on the use of web services, and this is one of the primary models used in Microsoft's .Net architecture. As a result there are a great many tools, websites and books available to support it. It is also the style of architecture favoured by the Open Knowledge Initiative at MIT and the IMS Global Learning Consortium in its Abstract Framework.
6.7.2. Enterprise Application Integration
EAI is a fairly traditional sort of architecture, with its roots in enterprise computing back into the 1980's. In EAI architecture, our primary intent is to integrate the set of existing primary applications to allow sharing of data and capabilities. In an MLE this usually looks something like this:
There are some problems with this approach, however. One particular issue is that it entrenches the division of functions into particular silos in the organisation, and does not address issues such as duplication of services or data. Instead, the approach is to replicate data between the set of systems so that they try to remain in synchronisation.
Also, while the problems of integration remain tractable provided the number of systems is very small, as soon as other services need to be integrating - like calendaring, resource management, repositories, finance, HR etc. - then the number of interconnections and replication activities becomes unmanageable,
There are a number of toolkits that assist in EAI; particularly in the areas of data replication and transformation - a number of the JISC MLE projects also used architectures like this one, and developed their own toolsets to assist with integration.
6.7.3. Message-Oriented Middleware
A variant of EAI is to use message-oriented middleware (MOM) to provide a framework for handling the data integration issues. A MOM provides routing and transformation capabilities in a central service, reducing the complexity of the interrelations between applications, and enables the MLE to scale. Examples of MOM software include Microsoft BizTalk, Sun ONE Integration Server (Sun's iPlanet Integration Server), and IBM's MQSeries. There is also an open-source MOM toolkit being produced by the SHELL project.
The EAI+MOM model looks something like this:
MOM approaches are a substantial improvement over standard EAI approaches, and may represent a good logical step forward for existing EAI-type MLE implementations that are facing issues of manageability and scalability.
6.7.4. Data Warehouse
A data warehouse model is a very different kind of architecture, which may be chosen to supplement an MLE (or to provide a different sort of MLE entirely).
A Data Warehouse approach involves the integration of data to provide the capability for conducting analyses that support decision making. Data warehouses do not offer any kind of integration at the operational end of the architecture, but instead provide a way to bring together the results of operations for strategic assessment.
A data warehouse relies upon a number of special data modelling techniques (star schemas, also known as multi-dimensional databases or query-optimized databases), high performance data stores, and a great deal of data transformation. Warehouses also require specialized analysis and data-mining tools to conduct assessments of the data and to support strategic decision-making.
Overall, data warehouse architecture looks something like this:
Data warehouses are extremely costly, and do not have an effect (directly at least) on integration at the operational level. However, large organisations that need to react quickly to changing market environments find them a worthwhile investment; educational institutions on the whole have not investigated their use (MIT being a notable exception).
6.7.5. Portal-centric architecture
A common architectural model used in MLEs to date has been to provide a presentation-level integrated view using portal technologies to aggregate various data sources. In practice this tends to resolve itself into an integrated presentation layer on top of either a service-oriented or EAI-type middle layer:
Portal-centric architectures use technologies such as uPortal and associated standards such as the Web Services for Remote Portlets (WSRP) specification to define XML-based 'channels' for each information source.
Portal-centric approaches to architecture need to incorporate a view of how the underlying architecture provides integration, or all that you end up with is a bunch of frames showing inconsistent data and poorly joined up systems on the same web page.
On the plus side, portal technologies generally provide a good framework for thinking about the presentation layer, and integration between either the presentation layer and the services layer, or directly with application logic or (even less advisable) databases.
6.7.6. Other approaches
These styles, while representing the vast majority of integrated platforms 'out there', aren't necessarily the only answers possible. Requirements analysis may reveal a set of demands that call for a different approach.
...And finally, the Single Big Vendor System architecture
Any section on MLE architecture wouldn't be complete without a mention of another rather (too) common architectural model - the Single Big Vendor System architecture. In this model, all system parts are sourced from a single vendor as a single integrated application.
This has advantages in the sense that it (usually) works reasonably well at installation, but locks the institution into a single vendor, and usually a single technology platform. (This isn't the same as using a single primary vendor to integrate various systems using EAI or a Service-Oriented Architecture).
Follow this link for key resources for this section (these open in a new window)
