I was doing a bit of research on the IMS Tool Interoperability effort and I ran across this post by Chuck Severence. He was enthusing about the need for the developing standard--a sentiment which I wholeheartedly support (although I don't know enough about TI yet to know how I feel about the way they propose to meet the need).
At any rate, this bit caught my eye:
This is like a holy grail - like a quest - and some have tried and come up short - SUNY is a good example where they insisted that hte [sic] "future is now" and ultimately ran out of steam and "lived in the present" and went with Angel (a good choice by the way).
Chuck probably has no way of knowing this, but his characterization of how things went at SUNY isn't entirely accurate. While I have generally avoided blogging on this topic to-date, I have decided to break my silence and make just a few comments.
To begin with, most of what I am ready to say publicly has already been covered well in an excellent interview of my former colleague Patrick Masson by JISC's Christina Smart. The gist can be boiled down to two points:
- The intended message of the SLN2 project was not, as Chuck put it, that "the future is now." To the contrary, we were looking toward an incrementalist (and Agile) approach both in our development and in change management for the users. Patrick's question to us, which became a kind of rallying cry, was "What version of Yahoo are you using?" When we were told, to our dismay, that our project must be called "SLN 2" (or, even more pompously, SLN two-point-oh), Patrick's counter-proposal was to call it SLNtoo. Our goal was to use technologies like web services to swap out the legacy system one piece at a time.
- At the time the project was killed, we had not run into any substantial technological barriers to our approach. Nor did our analysis lead us to believe that it would have been a more expensive approach financially than we believed licensing an LMS would ultimately be for the university. (And from what I hear from my former colleagues at SUNY, that analysis has turned out to be correct.)
It's very tempting to spill the gory details (and they are indeed gory), but I'm going to continue to resist that temptation. My main point, which is also one of the main points in Patrick's article, is that the real barriers to an LMOS approach are not technical but political. If we had been able at SUNY to tackle the technical problems one at a time, focusing on the most urgent and practical use cases, I believe to this day that we would have succeeded. We could have swapped out the parts of the system that were in most imminent danger of failing and then gradually evolved other technology pieces, spreading out the change management over time while enabling us to gain rapid improvements.
As proof of that, when the team finally gave up on waiting for permission and actually built something, our developer Bernie Durfee integrated Sakai's test engine and grade book as well as the Bedework open source calendar system with our legacy LMS in just a few weeks. These improvements were all upside and did not take away a single beloved feature of the legacy system from our users. (Note that no holy grail was required to get this done.) The next step would have been to get the content out of the Domino document store--which was killing us in terms of performance and reliability--and into a modern relational database. Again, this would have had nothing but upside for the users. Then, having met the basic needs, we could have focused on the challenge of adding more tools with less effort by working with standards large and small, ranging from RSS to WSRP to JCR. As long as we were able to work on one problem at a time, we could have built an LMOS--cost-effectively, with relatively little pain to the end user.
Instead, we were pushed into a "big bang" approach, with an implementation time line and marketing message that were much more aggressive than were warranted. That generated huge resistance from the hard-core base that had made the SLN community successful, ensuring that an already difficult political situation became outright impossible. It was the politics that killed us.
None of this is a slam on ANGEL, the platform that SLN eventually chose as the successor to its home-grown system. I think very highly of both the system and the company, as regular readers of this blog know. Nor am I saying that we don't need to do the work behind IMS TI v2. It's one thing to be able to wire tools into a system quickly and quite another to be able to plug them in without any custom wiring being required. But I am saying that I disagree with Chuck's characterization of the problem that we face:
So Tool Interoperability is a quest! It is a challenge - it is a mountain to be climbed - it is a standard to be developed. It is the search for the holy grail of LMS technology.
We went on a forced-march quest for the grail at SUNY, and it turned out that none of us was Sir Galahad. We don't need a quest. We need a scavenger hunt.
Now, I know Chuck well enough to know that he is a pragmatist. I don't want to over-interpret his laudable enthusiasm for the standards work as something more than it is. I'm responding to the words themselves more than the intention behind them. And I think it's important to say at every opportunity possible that the technological problems we face on the way toward a flexible and modular virtual learning environment are real but very solvable. To do so, we have to keep our sights firmly fixed on the middle distance, eschewing the pursuit of chimeras on the horizon while also setting our sights higher than adding the next bullet point to a feature list.