Integrating Innovative E-Learning Systems: Challenges

and Solutions from LAMS

James DalzielProfessor of Learning Technology, and Director,

Macquarie E-Learning Centre Of Excellence (MELCOE)Macquarie University

james@melcoe.mq.edu.auwww.melcoe.mq.edu.au

Presentation for EDUCAUSE 2006, Dallas, USA, October 11th, 2006

Overview

Part 1• The “All you need is LMS” myth• Incremental and disruptive e-learning innovation• Categorising integration requirements• Why SOA is premature

Part 2• Examples from LAMS• Future directions

The “All you need is LMS” myth

• A decade on from the rise of the Learning Management System (LMS), there is a widespread myth about its sufficiency– Some vendors encourage the belief that their platform does

everything (or at least everything *important*)

– Some university executives believe that by implementing a LMS, they have *done* e-learning, so no major changes are warranted

– Some university CIOs are reluctant to consider having more than one piece of software for e-learning

• Especially when it doesn’t come from a large vendor

– Some central e-learning support groups have become so aligned with their current LMS, they struggle to imagine other possibilities

The “All you need is LMS” myth

• Two reason for skepticism about the sufficiency of the LMS:– While the LMS has helped with many “e-administration” tasks

(announcements, course notes, assignment dropbox), the amount of online *learning* remains modest in most cases

– Most e-learning innovation now happens outside the LMS (eg, Blogs, Wikis, e-portfolios, advanced quizzing, Learning Design, Learning Object Repositories, Virtual Classrooms, mobile devices, portals, eResearch, Personal Learning Environments, podcasts, desktop applications, etc)

• But does this mean the end of the LMS?– Not for most universities, if only for legacy system reasons

• So the question becomes one of integration, especially integrating new innovations with the existing LMS

Incremental and disruptive e-learning innovation

• Viewed from the perspective of integration, some e-learning innovations are incremental, others are disruptive– Not just a technology issue – also depends on use – but for the

purpose of this presentation, I will focus on technology

• Incremental innovations (in terms of integration)– Advanced quizzing– Virtual classroom– Learning Object Repository– E-Portfolio– Podcasts– Some uses of Blogs and Wikis– “Simple” integration of Learning Design

Incremental and disruptive e-learning innovation

• Disruptive innovations (in terms of integration)– Some uses of Blogs and Wikis

• Available outside the LMS– “Tools” integration of Learning Design

• Requires tools (forum, chat, etc) to be “workflow enabled”– Personal Learning Environments

• Student controlled; may include desktop tools– Portals

• Alternative base platform, different integration “fabric”– eResearch

• Different authentication model (PKI), non-http internet services– Mobile devices

• Alternative screen layouts; online/offline synchronisation– Desktop applications

• Different security model (non-browser)

Categorising integration requirements

Two caveats:– Assumes you want integration (can always run separately!)– Focus on most typical integration (not all possibilities)

• Type 1: No integration or non-person-based authentication– Eg, Learning Object Repository, Podcasts

• Type 2: Single-sign-on (SSO) – person-based authentication– Virtual classroom– Some uses of Blogs and Wikis– “Simple” integration of Learning Design

• Type 3: SSO + assessment reporting– Advanced quizzing– E-Portfolio (NB: depends on purpose of e-portfolio)

• Type 4: Workflow-enabled LMS tools– Tools integration for Learning Design

Categorising integration requirements

• Type 5: Support for alternative presentation– Mobile devices; also relevant for advanced accessibility ideas

• Type 6: Intermittent network (Online/offline synchronisation)– Mobile devices, Personal Learning Environments

• Type 7: Authentication/security models unlike LMS– Some uses of Blogs and Wikis (expose content outside the LMS)

– eResarch that requires PKI

– Desktop applications and non-http internet services

– Personal Learning Environments

• Type X: Conflicting basic platform assumptions– Portals, “full” SOA implementations, eResearch Virtual

Organisations

Categorising integration requirements

Some observations:1. Authentication and security models are the most common

challenge– Type 1: No integration or non-person-based authentication– Type 2: Single-sign-on (person-based authentication) - SSO– Type 3: SSO + assessment reporting– Type 7: Authentication/security models unlike LMS

2. Some other integration types each represent unique challenges with far-reaching consequences– Type 4: Workflow-enabled LMS tools (includes SSO)– Type 5: Support for alternative presentation– Type 6: Intermittent network (Online/offline synchronisation)

3. Some cases are so different as to challenge integration per se– Type X: Conflicting basic platform assumptions

Why SOA is premature

• For some, the concept of Service Oriented Architectures/Approaches represents a new solution to integration problems

• If SOA just means identifying some minimal integration points between two systems, then this is less difficult to implement

• But much of the SOA hype is around rebuilding the whole IT infrastructure around disparate sets of services to create composite applications– Assumes the applications of today will disappear, or at least be

completely rebuilt

Why SOA is premature

• SOA as a solution to the current integration challenge is premature because:– Almost none of our current (innovative) systems are constructed

using a SOA approach (they are still “traditional” applications – the Fedora repository is about the only real exception)

– Even if applications were service oriented, we haven’t even begun to understand the wider SOA authentication and security fabric needed to build composite applications from disparate services

– Even if we understood the security fabric, and all our applications did expose services, we still have the problem that each application could have its own, different assumptions about the security fabric, leading to interoperability failures despite availability of services

• NB: For the same reason, combining two or more SOA frameworks from big competing vendors will often be an interoperability nightmare

Part 2: Examples from LAMS

• LAMS is an integrated Learning Design system– Author (create Learning Designs)

– Monitor (instructor can launch/monitor Learning Designs)

– Learner (student environment for “run-time” activities)

– Admin (usernames & passwords, roles, server admin)

• In addition to the above components, and the core “workflow” engine, LAMS provides a suite of “workflow enabled” activity tools (forum, chat, quiz, content, etc)

• Not a LMS, but can be used integrated or stand-alone• Freely available as open source software

– See www.lamsfoundation.org

Examples from LAMS

• Example A: Single-sign-on (SSO) with LMS– LAMS V1 provides SSO with Blackboard, WebCT, Sakai,

Moodle and .LRN LMS platforms– For instructors, LAMS authoring and monitoring are accessed

just like other LMS tools• No extra login• Sequences can be selected directly from LMS page

– For students, a LAMS sequence is accessed via a URL on the course page

• Eg, “click here for activities for week 3”– Integration involves LAMS receiving basic identity and role

information from the LMS (via integration module)

Examples from LAMS

• Demonstration of LAMS V1 integration with LMS (based on Sakai)

Login Page of LAMS/Sakai test server – includes further information links

Sample course in Sakai that uses LAMS

Adding a LAMS sequence to a Sakai course – Sakai page

Adding a LAMS sequence to a Sakai course – LAMS authoring page (pop-up)

Sample course in Sakai with links to LAMS sequences shown in central area

Student view of LAMS activities as pop-up window from Sakai course page

LAMS monitoring page for live student sequence – popup from teacher area

Examples from LAMS

• Example B: Tools integration for LAMS V2– LAMS V2 (released October 2006) incorporates a new

modular tools architecture - “LAMS Tools Contract”– The tools contract describes the requirements for an activity

tool (forum, chat, quiz, content, etc) to run within the LAMS workflow environment

– The tools contract is not simply a Java API, but rather a set of URL calls and conventions on tool behaviour for

• Authoring• Monitoring• Learner (ie, “run-time”)• Admin

2

Examples from LAMS

• Example B: Tools integration for LAMS V2– The tools contract provides the basis for LMS tools to run

within LAMS workflows (“sequences”/Learning Designs)• Eg, creating a LAMS sequence inside Sakai (SSO

integration) which uses the Sakai forum, rather than the LAMS forum

– This provides a solution to the “tools duplication” problem• That is, you can avoid having a course forum tool in your

LMS, and a separate (workflow enabled) forum tool for Learning Designs run within your LMS

– No LMS have implemented the LAMS tools contract yet, but a number of pilot projects are underway

Examples from LAMS

• Demonstration of LAMS V2 (including tools contract)

• For LAMS V2 demonstration accounts, see http://demo.lamscommunity.org/

• To learn more about LAMS V2 architecture, see the LAMS V2 Development wiki at– http://wiki.lamsfoundation.org/display/lams/Home– Including link to Tools Contract description

Future Directions

• Authentication and security fabric remains a key challenge to various types of integration

• LAMS Tools Contract provides a basis for creating “workflow enabled” LMS tools

• Dealing with LMS as a legacy system environment for practical integration

• Some approaches have fundamentally different assumptions to LMS (eg, using a portal as basis for “Learning Management Operating System” – LMOS)– Do they provide a better platform for integration?