Speaking of both standards compliance and Blackboard, IMS CEO Rob Abel has posted an interesting comment on the Wired Campus’ blurb regarding a Blackboard/SAP integration deal:
It is important for the readers to understand that there are currently administrative system providers such as Oracle working within the nonprofit IMS Global Learning Consortium to create open standards for the type of integration mentioned between administrative (SAP) and course management (Blackboard) systems. SAP is not currently a member or participant in IMS and, as such, is not involved in this work. Buyers need to understand that proprietary integration schemes limit their choice and involve greater total cost of ownership. There has been quite a bit of “lip service” to standards and we are doing our best to change that. As such, IMS will be developing a certification and compliance program for the next generation of enterprise data exchange and I suggest that buyers look to the IMS web site (www.imsglobal.org) to see which vendors are participating members and which products are compliant.
This is all of a piece with the Common Cartridge issue. If customers don’t demand standards compliance, then they will remain at the mercy of vendor lock-in. The last thing you want to hear is that you can’t change to a better LMS because the non-standard integration with your Student Information System (SIS) will break.
Are these standards perfect solutions? Of course not. Standards specifications are rarely perfect and even more rarely perfect on the first try. For example, one LMS developer told me he had concerns that that the current Common Cartridge specification doesn’t give him very good tools for ensuring that his platform fully complies with it. So glitches will happen and the spec will need to be refined. But that won’t happen unless customers demand standards compliance first and then demand improvements to the standards as the needs are identified.
Despite what some bloggers may tell you, there is plenty of evidence in this industry as well as others that customer demand can drive standards adoption. (SCORM is one good example off the top of my head.) So go ahead and be demanding. Tell the vendors that that you simply will not adopt a platform that locks you in by neglecting standards compliance.
Jesse Ezell says
While the common cartridge spec is an intersting idea, it is far more important that we get better specs than SCORM, QTI, etc. Even if your tags are imported just fine, the content communication specs are still so horrible and complex that you’re still going to have to cross your fingers and pray that the content will work on your LMS after it is imported.
Michael Feldstein says
I don’t see this as an either/or issue. Both are important. And both can be helped along by active lobbying from teachers.
Jesse Ezell says
Michael, I think you are right to some degree… . I agree that the goals of CC project are right on target. However, building a standard that standardizes on top of poor specs is hardly the way to get off on the right foot. SCORM is plain bad any way you cut it. QTI is technically better, but is needlessly complex. Building your own LMS even with the CC spec will be horrendously difficult. There is no good reason that creating a simple LMS that supports everyone’s content and gives you 5 or 6 basic reports should be much harder than creating an RSS aggregator. So yes, CC does solve some problems, but it solves them in the wrong way, by creating specifications that say how to use a bunch needlessly complex specifications together, rather than starting clean and solving the root issues.
Michael Feldstein says
You certainly won’t get any argument from me about the complexity of SCORM. (I can’t speak to QTI, since I haven’t been involved in any QTI implementation projects.) I guess the question is what teachers should do about the situation, since that’s the audience I am addressing in this post. Most teachers don’t know and shouldn’t have to care about how easy or hard the standards are to implement. They *should* care, however, about how seamless and ubiquitous those implementations are. If we create market demand for this, then there will be more motivation to fight the inertia inherent in having an established specification and fix remaining problems.