Jim Farmer has posted a slide stack (in PDF format) on the economics of interoperability. There’s a lot of good general stuff here about service-oriented architecture (SOA) and interoperability issues from a business perspective, but 90%+ can also be read to apply directly to the LMOS concept.
Here are some highlights:
To begin with, it’s important to understand how small the resource pool is to solve instructional technology problems. Colleges and universities, on average, spend well over 60% of their IT budgets on administration and only 20% on instructional technology. And we know that, on average, $6 out of every $10 (or 60%) of any IT budget goes to maintenance. That means the total average IT budget for instructional technology devoted to something other than just keeping the lights on is 40% of 20%, or 8% of the total IT budget.
One reason that maintenance eats up so much is the cost of integration. Campuses increasingly want thier Course Management System (CMS) to integrate with their SIS system (to auto-populate class rosters and auto-report grades to the registrar), library systems (to integrate courses with e-reserves and other resources), a portal, an eportfolio, a learning object repository, and so on. (Note that these integrations are more than just single sign-on; there are other types of data being passed.) Traditionally, these integrations are wired up one at a time. Want to integrate your CMS with your eportfolio and your SIS? You need to write one connector for each of those two integration points. But if you want to integrate your eportfolio directly with your SIS directly, you have to write a third connector. The number of integration jobs increases almost exponentially with the number of application-to-application connections you need.
(By the way, an added consequence that Jim doesn’t mention in his stack is that vendors also are forced to spend increasingly large percentages of their revenues on writing connectors. That’s money that could have gone into improving the product as a learning and teaching tool.)
Now, consider that the average age of CMS’s at institutions is under four years, and that the migration rate to new CMS’s is about 12% annually (which, if that rate remains constant, means a migration roughly every six years). Migrations are expensive, and they take time. A heavily-utilized system may take as long as three years to go from initial migration planning to putting the last courses up in the new system. That means many institutions are undergoing some phase of CMS migration maybe 50% of the time. It’s more or less a permanent drain out of that 8% of the budget available for non-maintenance investment in instructional technology. With all of that, there’s little or no budget left to invest in fostering innovation.
What would the solution to these problems look like? Well, one possible solution looks a lot like an LMOS–lots of tools plugged into a central service hub (…broker…bus…whatever) via standard interfaces, with communication between tools choreographed via the hub. To begin with, it should lower maintenance costs by dramatically simplifying the integration code. Furthermore, being able to swap out functionality of the learning environment on a tool-by-tool basis should help break that 4-year migration cycle. As Jim says, “better service, lower costs–now.”
