IMS Learning Information Services: The Motivating Pain

Today Oracle announced the release of the Student Administration Integration Pack, or SAIP. It’s the first product that I have worked on as an Oracle employee, and I’m proud of it for a number of reasons. It’s not a particularly glamorous piece of software, but I think it’s going to be important. This is my first post in a planned series about it.

I’m going to start the series with a few posts about the IMS Learning Information Services (LIS) specification that the SAIP implements. Because, really, the specification is at the heart of the product. Now, let me get one thing out of the way, because some of you are going to complain ask. A draft of the LIS specification has just left the working group and is currently available to IMS members only. It will be made available to non-IMS members by December, after which there will be a better part of a year when it will be open to public comment and further revision from the working group before it is finalized. I know that this schedule makes some of you unhappy. I have complained about it myself. I’m going to tell you as much as I can now and let you know the moment that more information becomes available to the general public.

Anyway….

Today’s post will focus on describing the main pains schools have been experiencing that motivated the creation of the specification in the first place. In later posts, I’ll talk about how the LIS attempts to relieve those pains (again, not glamorous but still important), and then I’ll write a little bit about some of the moderately sexier possibilities that LIS will also enable.
To begin with, LIS is really an updated and renamed version of the IMS Enterprise Services (ES) specification (which is why LIS will start on Version 2.0). ES was originally designed to enable students and courses to be populated into an LMS from a Student Information System (SIS), and to have basic grade information pushed back from the LMS to the SIS. This may seem really boring and unimportant until you try to set up your first class in some Web 2.0 tool where you need to manually invite each student into the group and set the appropriate privileges. Even under the best of circumstances, it is a large and annoying time sink–enough of a time sink, in fact, that most professors simply would not do it. So, back in the days when the campus LMS was (for the most part) the sole online environment where you would want to provision students and classes, the ES specification was created as a standard way for any SIS to automagically provision students and courses to any LMS.

Or so the theory went.

Like version 1.0 software, version 1.0 standards (or even version 1.1 standards) tend to be buggy. This is particularly the case when the standards are created early on and the full scope of the problem being solved, along with all the various sensible implementations of the solution, are not yet fully understood.  In the case of ES, the initial design didn’t fully account for the fact that registrars think differently about courses than teachers and students do. For a registrar, the lecture, lab, and discussion sections for, say, Biology 101 are all distinct entities and not particularly distinguished from all the other Biology 101 sections for a given semester–of which there may be many. But the teachers and students often view one particular trio of lecture, lab, and discussion sections as a distinct “class” because all the same students, TAs, and teacher participate in those sections and do not participate together in any other Biology 101 sections. For the students and teachers, it makes sense to group those sections together as one “class” in the online learning environment, possibly in one unified course site. But because ES didn’t have a standard mechanism for describing these relationships between sections, the LMS would generally receive one record for each section and create one completely separate course site for each section, just as any registrar but no student would find sensible. And chaos ensued.

Different schools dealt with this differently. In some cases they dealt with it on the LMS side by, for example, turning off the course sites for the lab and discussion sections and just using the course site for the lecture section. But this doesn’t always do the job. Suppose you have lecture/lab pairs where the students are always the same, but the discussion sections are all mixes of students from across all the lecture/lab pairs. And suppose further that you want all of the discussion sections to share one course site. You can’t do that by just turning off extra sections. Because this is academia, and because registrars are evil geniuses, there are a million billion quirky exceptions and odd combinations like this one at colleges all around the world.

So many schools decided that the best way to deal with the problem was to merge the section records after they came out of the SIS but before they went into the LMS. The LMS would still create one course site per record, but because the section records are merged, the sites would come out the right way. Schools either wrote custom middleware on their own or paid vendors copious amounts of money to write it for them. This solved the separate-sections-in-the-LMS problem for them, but it also created new problems. To begin with, this middleware is almost never built to operate in real time. The student registers for a class in the SIS, the data goes into a database table somewhere, it gets munged up with other sections (either in an automated fashion by a pre-set rule or manually by some action on the part of the administrator) at some point during the day, a batch process runs overnight, and the student will have access to the course the next day. Or two days later, if the school’s process is particularly inefficient. You can get approved for a credit card or order an intercontinental airline ticket pretty much instantly online these days, but to get access to an online course usually takes overnight in most colleges.

Another problem is that the record munging destroys any possibility of grade integration using ES. In most places, after a teacher spends an entire semester working in their LMS grade book–the online, electronic gradebook with grades that are stored in a modern, electronic database–the teacher has to print out a copy of the students’ final grades, log onto the SIS, go to the grade roster page for the class, and manually re-enter all the grades that already exist in the electronic, online LMS grade book that is storing the grades in a modern, electronic database into the electronic, online SIS grade roster that stores grades in a modern, electronic database. In theory, ES was going to end this madness. It allowed the LMS to say to the SIS, “student X in course section Y got final grade Z”. Very hip. Very now. Very digital. Except that, when you munge up all of those sections in your middleware in order to get them to appear properly in the LMS, you lose the ability to link a student grade back to a section ID that the SIS recognizes. So we’re back to printing out the grades.

But by far the worst problem the custom middleware approach creates is cost in time and money. First, you have to build the darned thing. For a large university paying an external vendor to do it, this can run half a million dollars. Then you have to maintain it. Again, in some large universities, you have 2 or 3 full-time employees dedicated to keeping the software running and up-to-date, managing the merging rules, handling exceptions, etc. Often these are skilled programmers. And if you ever update either system or–heaven forbid–actually replace your SIS or LMS with another system, everything is likely to break. Which means your IT director is going to be very reluctant to change anything, even when your LMS or SIS is hopelessly out of date. (And you thought it was just because he’s mean….)

And while all of this mess has stayed exactly as it has been for nearly a decade, the world has moved on. Colleges now often have 2 or 3 LMSs that they have to integrate the SIS with on campus, plus adjunct applications like course evaluation systems and stand-alone wikis, not to mention many possible Web 2.0 tools in the cloud. ES does nothing for any of these needs. Very few schools support these needs today because they’d have to build this integration from scratch.
So, to recap:

• Students can’t get into their online classes for 24 hours after registration.
• Faculty can’t electronically submit grades from their electronic LMS grade book to their electronic SIS grade roster.
• IT directors can’t update or change their systems without incurring close to job- (and sanity-) threatening amounts of risk, expense, and work.
• Nobody can provision courses and students into the many other systems that could be used for teaching and learning.
• And yet, universities are devoting huge amounts of money and personnel to maintaining the current state of affairs–resources that could be spent instead on, say, making the campus webmail solution less heinous, getting reasonable bandwidth on campus, or (*gasp*!) possibly even installing a wiki or a weblog system.

And all for the want of a horseshoe nail.
It’s not such a great situation for the vendors, either. (Yes, weep tears of pity for the poor, downtrodden vendors, Dear Reader!) Naturally, customers complain about this sorry state of affairs (as they should). So the vendors rush off and try to create better integration. But the standard is broken, so they have to devote development resources–resources that could be spent instead on, oh, say, making their user interface slightly less unusable, for example–building point-to-point integrations with every platform out there. Integrations that break if the customer upgrades or swaps out a system. For example, Banner has very good integration with older versions of WebCT CE, which is one reason why many campuses are still running an ancient, weak, hopelessly outdated LMS. It’s hard to tell faculty that they’re getting shiny new tools in their shiny new LMS but now they have to enter their final grades into Banner manually.

So, to recap:

• Vendors spend a lot of money and resources trying to build point-to-point integrations.
• These integrations often break with new point releases, so the vendors have to constantly spend more trying to re-fix them.
• And yet, customers are still pissed off because they’re getting a sub-standard solution.

And thus it was that the IMS LIS working group was born. An intrepid band of vendors, colleges, and government agencies, gathered together in a fellowship to travel to Mount Doom, deep in the heart of Mordor….

THE BEGINNING.