This great question was posed by Patrick Masson, SUNY Learning Environments’ Director of Technology Projects, to make a point about the next generation of course management systems. The design of the current generation of systems is that of old-fashioned monolitic systems. Blackboard, WebCT, Angel–even Moodle (albeit to a somewhat lesser degree)–they are all built on this model. To improve the system, you have to upgrade to the next version.
But web services such as Yahoo, Jotspot, and Salesforce.com are versionless. We don’t know what version of the product is running and we don’t care. New features are added from time to time, but that all happens seamlessly for the user. There’s no migration…no “flipping of the switch.”
So what does a course management platform need to have in order to support this kind of versionlessness? In a word, “services.”Basically, every tool needs to function as its own, independent piece with well-defined (and standard) integration interfaces. As a system administrator, I need to be able to pull out one discussion board and plug in another, for example. But discussion boards don’t function entirely independently of other CMS components; they need to be able to both give and receive data from other pieces. For example, they may need to get the following information from other system components:
- Who the person is
- What class the person is in
- Whether the person is a student or a professor
And it may need to pass other information out:
- Who has participated in discussion
- Which discussion boards have new information in them
On top of these data-passing requirements, the component (in this case, the discussion board) needs to live in the same visual environment as other components. In the world of the web, that means compatibility with a portal. And if you want to get really innovative, then you want to think about interchangeable (and sharable) pieces that are smaller than a discussion board. For example, you may want an RSS service that can be used by any other component (including the discussion board) to notify users of new contributions. Or you may want to create a service whereby a professor can attach a grade any student contribution, whether it’s a post to a discussion board or an assignment uploaded to a file storage area. In order for to build these nifty services that could be shared by various system components–especially where those components are themselves swappable–you need a comprehensive set of well-defined programming interfaces or “APIs”.
The vision of the next-generation system that I have just described is essentially the goal set for Sakai. Whatever complaints you may have about the project–and I have voiced some here on this blog–it’s a pretty inspiring vision.
