“Monoliths,” APIs and Extensability – A presentation on the past and future directions of CMS


I was very fortunate recently to deliver the above talk to a CMS task Force at UBC on the overall lay of the CMS land. It seems relevant to share it here, especially in light of a recent post by James Farmer on integrating open source pieces with WebCT, and the great follow up by Michael Feldstein.

I think Michael’s read is mostly accurate. As I try to lay out in the presentation, CMS have evolved as a series of “wrappers” around a set of applications, and there were good reasons for this innovation (it was an innovation when it began 10 years ago) in terms of handling scale and providing some stable service across all or many departments in a post-secondary institution within a limited budget.

But this model, which does tend towards monolithism, is now 10 years old; in part because of rapidly maturing alternative models (service oriented architectures and distributed applications development environments in general), in part because of pressure from customers to allow more pedagogically-driven choices in their tools, and in part because of challenges from Open Source and elsewhere, all of the CMS, be they commercial or open source, are moving, some slowly, some more quickly, towards increased extensability and interoperation with other tools. This is in my mind an undeniable trend, and the issue for organizations is not if this will happen, but instead a question of how best to obtain the core services and acceptable level or “service” while increasing the amount of flexbility and choice for instructors and students, and at the same time not increasing the cost (and hopefully decreasing it if you’re really adept).

I don’t think the commercial CMS companies are going away, at least not anytime soon. There are still many organizations (often small ones, but not always) for whom more sophisticated ‘elearning architecture’ approaches, “best-of-breed,” or the choices (and demands) facilitated by open source are not (yet, maybe ever?) realistic choices. There is value in providing a set of tools (however limited you might feel these tools to be) in an integrated environment that can with relative ease tie into other parts of your infrastructure and for which you need to hire application administrators, not developers, to run. But even those customers want more freedom to make choices, and the CMS companies know this and are trying to mediate it without cutting off their own nose. But it’s also clear that they are under fire, and that many institutions will have the wherewithal to adopt or create what Michael terms a “Learning Management Operating System” into which they can insert, or on which they can build, different application choices and approaches. As I read it, the impetus behind OKI, and to the extent to which it embodies openly agreed upon APIs, Sakai, is a step in that direction. Michael’s predicition of a timeline (about 5 years) also seems about right; it will take a while for the implications of this approach to flow through and for the various systems needed to implement it to mature to the point where each implementation is not a large software development initiative of its own. But it is coming, and it will change the landscape of these systems considerably. – SWL