Unification vs Fragmentation of the LMS

I loved the discussion I listened to today by Jeff and Brian of the EdTech podcast hosted by ETS.

In it they talk about students building their own LMS.  The discussion is framed mostly around “well, why would they do that” and my thoughts immediately came to reuse, remix and fragmentation culture.  They talk about 3 efforts by students at different universities to replace their LMS with something new.  I highly recommend checking it out as well as previous episodes as they give some thoughts on Structured Anarchy.  The talk got me thinking about the idea of students as part of development (which I’d love to flush out into its own post in the future) but it really got me churning about LMS unification vs fragmentation.

These two two camps seem to be developing in not only the LMS community but in Technology as a whole.  The unification crowd is most prominently represented by companies like Apple.  Buy into the Apple way of thinking and product line and life is good (great actually).  Get irked by the Apple-Standards (connectors, iProducts and iPeripherals) as opposed to universal standards and well, you’re more often than not in the Fragmentation or Google crowd at the moment.

I’m not saying one is better than the other.  I prefer the Android platform for personal reasons much as many prefer iOS in much the same way.  The Fragmentation crowd (which I am typically a member of) believe that the way towards the best end-product for students is to restructure the old ways of systems organization — that is large, singular systems — and instead adopt very (scary) loosely coupled systems.

Decentralization is scary because the thought is that this can cause resource waste.  And not just competing but similar efforts wasting man and woman hours in coding, testing, requirements gathering, etcetera.  And resource waste, especially during budget cuts is never something anyone wants to consider.  We need to be running more efficiently not playing around with new ways of doing the same thing.

So how do we walk (and identify) that fine line between what is better being left unified and what should be left fragmented?  Surely there are times when unification are king.  I mean no one wants a fragmented calendaring system (try scheduling a non-oracle users for a meeting).

Here is my current measuring stick for whether we should or should not unify / standardize / centralize a service:

  • Is the need a simple task or can it mean different things to different people? (i.e. Calendaring system vs Content Management System)
  • Is the system an actor in the interaction? (see Actor Network Theory — http://en.wikipedia.org/wiki/Actor-network_theory)

Let’s apply the rules to Email (protocol not client). What do people want to do? Send text from one person to another (CC/BC is the same process duplicated).  Is Email an Actor? No, in and of itself Email is not an actor in the transaction, it is simply getting a message from one place to another.  Email = Unified.  Calendaring systems line up in much the same way.

The Actor criteria is paramount to simplicity, though actors are rarely simple so they usually are just “no, yes” or “yes, no” assessments.  Is the system imbued with intelligence in some way or is it just a dumb-terminal (by design)?

Let’s look at our decision to build the ELIMedia Asset management system.  Is it a simple, single purpose system?  No, an Asset is like a node, it can be anything to anyone.  Can Asset management systems be an actor in the ANT model? Yes.  Asset management systems need to make decisions about copyright, permission, workflow, and embedding.  They should email or track usage of assets across infrastructures.  There’s a lot involved there!

So by my criteria, asset management systems should not be standardized?  Seems a bit strange yes?  I mean assets are wanted to live in one place all the time and be reused in many places many times.  That’s a 1 to many relationship, why not have a 1 AMS to many locations relationship? I argue that I may think of assets very differently from you from someone else.  Are we talking assets like video, audio and image source files?  Or are we talking tables, chairs, computers and physical assets of a university? Or maybe its documents like syllabi, Powerpoint slides, webpages, and working course documents?

Very different sounding systems based on the context they are used in, right? Hence, we run ELIMedia and while I’d love other people to use that system, my own assessment of needs suggests they should run their own version at the very least.  This is the only way they can truly tailor towards their needs.  Again, turning to concepts of fragmentation and Structured Anarchy: build and reuse part of whats already been built and tailor the last 2-10% to your own needs. (aside: ELIMedia will be released as a Distribution by the end of the year… just saying ;)).

I’d be interested to see my criteria applied to other systems / technologies to see what we come up with.  Grade books, Forums, Course Content, Syllabi, drop boxes?  How granular could we get and still have it make sense? As my take, Grade books and forums should be standardized / centralized, course content / syllabi / drop box environments… I think not.  How bout you?