ELMS Learning Network: Design Philosophy / Theory

Far more important then the technology you select for anything is the design.  Quality, well thought out and executed design is difficult to accomplish and requires many iterations over ideas.  You need to allow certain concepts to fail and others to flourish and be willing to switch to better ways of thinking mid development at times (and refactor and refactor again..).  This is true of any technology you select and as such, philosophy of design and theory are paramount in the development of the ELMS learning network.

Design Philosophy

In a world of constant chaos of technological design where any 12 year old prodigy can disrupt your entire business model, it’s critical to stick to a method of tool development that can stand the constant winds of disruption.  I won’t go into great detail as to why I chose Drupal over an actual educational platform but the primary reason is flexibility.

A community so vast will breed superior solutions to those found purely within edtech. Have you used or seen any of the popular MOOC authoring experiences? Drupal from 4 years ago slaughters it let alone today or tomorrow’s Drupal!  It is for this reason that the solutions to save edtech don’t lie in the vendors traditionally pushing you edtech.

It is with this philosophy that we’ve won multiple awards for “Innovation” and plan to do so with a development team of 1.  This is possible because the reuse of the work of others leads to a development team of thousands.  While the implementation is only one; the available code-base is produced and refined by thousands upon thousands of developers’ eyes daily.

In the Learning Network though there is one primary implementation philosophy that powers everything: RESTful APIs which in the current Drupal 7 portion of the CIS is powered by the RESTful Web Services Module (restws).

Network Topology

Stepping back from Drupal to network implementations in general, we need to find a structure that best mirrors a need for structured yet loosely connected environments.  For this reason, I’ve decided to base the ELMS LN on a combination of Star and Fully Connected Topology.  The deployment methodology of the Course Information System being the center of the ELMS universe, drives the creation of course networks.

Star Topology

CIS Star Topology

This topology enables the CIS to have a say in coordinating the connections between all other systems in the network.  While all of these services pictured could live on their own, it’s obviously more helpful that they have a consistent connection back to the CIS when needed.

This is just for the initial setup of the network.  Data systems can then be wired into the CIS so that information is populated automatically and propagated back down to the rest of the services that it is aware of.  This is critical towards making the learning network effectively self aware; this base architectural decision.  Without understanding that this is the base layer, the rest will appear as chaos (and very quickly).

Fully Connected (through the sub-net)

Fully Connected, distributed systems to power the course

 

This is what the CIS starts to allow to be generated: chaos downstream.  The instances are formulated based on data thats shipped to the CIS / Middleware (other LMS APIs and what not). These instances could connect to all other instances but the only way this would make sense is when the instances are related.

For this, we use a consistent pattern match against the services used in a course network loop.  This can be engineered in a consistent manner as follows: {service}.{college}/{course}.  

Example course sub-net for Math 100:

• online.college.com/math100 — markets the course and helps organize internal logic for staff roles and web service agent accounts
• courses.college.com/math100 — the primary outline of the course that helps form a logical instructional flow for students
• studio.college.com/math100 — the place assignments are submitted
• analytics.college.com/math100 — an invisible RESTful engine that aggregates data silently for instructors and staff to gain insight into the analytics of the course

This allows all services in the network to easily sniff out other services in the network and broadcast RESTful API communications back and forth.  The CIS can be utilized to understand the topology of a CIS Sub-net as some sub-nets may be made up of a different set of course tools then another.  Maybe the only thing required for a course is the outline tool, why clog up the feature set with tools that are unneeded?

Time frame

ELMS LN is being designed and implemented with a goal of powering the next 10 years of innovative, free, open systems I seek to develop.  To do this, I’ve created several tools over the years to help bring me to this point.  The most important currently is known as Ulmus.  It is a distribution that was specifically created to allow for the rapid creation of new tools to plug into ELMS learning network.  Think of it as the framework of a tool with all the modules, connections and features required at a base-layer to enable a smooth transition into a course sub-net as a new tool.

Web Services also help open the door for bringing non-drupal tools into scope of a traditionally all drupal network.  RESTful APIs can be implemented by any system in any language, as well as the use of LTI to help bridge communications.

At the time of this writing, I am running the CIS (online) and MOOC (courses) distributions in production with several courses.  If I had to rate them in terms of completion, I’d say both are at about 95% stabilization and well on their way to being finalized systems with only minor UI, UX, and bug fixes to go.  CIS’s theme is still in active development as well as a professionally produced ELMS Learning Network Design Guide with detailed visual descriptions of the ELMS “brand”.  Documentation needs a lot of love, but that’s what things like this blog hope to help bridge!

The ELMS: CLE (studio) distribution is available as a proof of concept and will receive full development focus over the next 4 months. Some additional distributions being developed in tandem with hopes of being released over the course of the next year include a centralized helpdesk, a centralized accessibility and copyright auditing system, a semi-centralized error reporting system, a learning analytics repository (lar) and an interactive course object repository (icor).