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.
So I appreciate your unwillingness to go into the "gory" details in public, but I do hope some day our paths will cross f2f as I would love to hear more of these. Not out of any sordid interest, but because I agree, many of the barriers are political, and it is one arena that I know I have personally much to learn, so hearing how this project, full of vision and promise, got derailed would be instructive.While I am encouraged by your description of the small pragmatic steps you had planned to make the LMOS a reality at SUNY, another part of me (probably the same part without the political acumen) worries that until something like TI becomes a reality in a specific, implementable platform, there will be many more tales of aborted efforts like the one at SUNY, and actually far more tales of quests (*and* scavenger hunts) never even begun, the knights errant (god how this metaphor is stretching!) preferring the warmth of their familiar (if dysfunctional) LMS to the perils of the hunt. You’re right that the metaphor needs to change from quest to scanvenger hunt, but my experience is that big IT departments are still mostly provisioned for quests. Maybe this is another place the discussion needs to be focusing, what changes could be made to help IT departments ween themselves off monolithic systems and quests and become more nimble and support smaller, more losely joined systems.
A couple of rays of hope:
I think that 2007 could very well be the ramp up to 2008 as the Year of the LMOS.
I wonder if the “pragmatist” label may actually get at the heart of your story. Here are two ways to “pragmatically” decide something:
Confusing those two approaches may sometimes be politically astute, but only one of them is what I would recognize as good engineering.
It sounds as if your pursuit of Pragmatism B got pushed into a spot where it was vulnerable to Pragmatism A. Thinking monolithically is a great way to make Pragmatism B in itself sound dangerous: “We don’t have time in the schedule to test everything!”
Spot-on, Ray.
You might call these pre-Copernican and post-Copernican pragmatism, respectively.
Scott,My political reality is decision makers enjoy the benefit of ignorance regarding integration and interoperability issues, "that’s the ERP vendor’s responsibility" and the luxury of consumerism, "Sorry, company X does not support that." SLN2 (and the LMOS) brought these issues to light within the LMS (e.g. integration between the Discussion Forum and the Gradebook), issues usually only (if ever) discussed at the systems level (e.g. integration between an SIS and LMS). Where does TI and SOA merge/separate? Why is it ok to endeavorer to create custom scripts to connect Banner to XEI but not SAMigo and Bedework? Why is it ok to spend hundreds of thousands of dollars and employ a significant number of developers to "customize" an SIS because of the diverse needs of campuses but expect an LMS (and thus using the LMS: faculty) to function as needed, "out of the box," despite those same diverse campus needs?"What changes could be made to help IT departments ween themselves off monolithic systems." I have many ideas, none of them complimentary to the current lot of IT leadership. Perhaps
Walter Mossberg, personal-technology columnist for The Wall Street Journal, has it right. He described the information-technology departments of large organizations, including colleges, "the most regressive and poisonous force in technology today. They make decisions based on keeping technology centralized,” he said. “Although lesser-known software may be better,” he said, “technology departments are likely to use big-name products for their own convenience. That may keep costs down for an organization,” he said. “but it puts consistency above customization, preventing individuals from exploring what technology products are best suited to their own needs."Ray, At SUNY, "Pragmatism A" was considered "esoteric" and "Pragmatism B" was the "Request for Public Comment."
Patrick, I really appreciate your willingness to expand on this some more, thanks! I would be surprised if your comments and experiences didn’t resonate with many. If you read my blog you can see I’ve been suffering through a similar, if lesser scaled, experiences with IT staff. I also wish I could have attended the recent ed media session around this topic hosted by a bunch of edubloggers (http://weblogs.elearning.ubc.ca/brian/archives/039877.php).
Risk management trumps. That’s my takeaway, Michael.It’s the devil you know vs. the devil you don’t know,I can see where it’s hard to sell the incremental approachwithout broader support.It may be that SUNY was too large to try this out.Risk aversion is like inverserly proportional to size.I’m not a big fan of very large deployments, I’d liketo see us spread out our risk. There is a thought outthere that bigger is better, heck I heard someonefrom Educause tell us that you needed to figure outhow to work in some consortium or what not. Thisis like old school to me, in the day of timesharing computers when CPUs were expensive and you hadto be careful how much you used. The economicsof scarcity. Thing is, we are in a huge boom of computing capability. Everywhere you look, somedevice is what 10-15 years ago would have beena heck of a computer.So, I dunno how this is going to play out over time,but I’m pretty confident that it’s not going tobe a big-box central computer style.How does this fit with TI (glad you brought me back :-)?As someone who worked on TI v1, I think we need toget-along faster. I was somewhat mobbed after a sillylittle presentation in Austin about TI (2005) and it’s stillnot much further. We whipped that one out in a fewmonths, most of the work happened in a couple of weeks.Google has some cool APIs, maybe weshould look there 🙂 And what is that deployment modelthat Google uses? (that’s a rhetorical question 🙂
Nice article and fun to get a little detail on the inner workings that I was watching from the outside as if I were viewing a black box.Probably the biggest thing that I missed was the plan to "evolve the existing system". As best I was told was that SUNY effort was about starting over with uPortal LAMS and turning off the Domino stuff ASAP. This is where my reaction was "yikes – these folks want to insist on Nirvana right away by fiat – ignoring all common sense". But frankly I was also excited about the possibility of a talented group of folks going "after" the hard problem – which I am sure would yield in time.I generally love the evolve in place approach and have recommended it many places (BTW – This is a good use case for IMS TI – sorry I *am* obsessed with TI) – but I never had a clue from SUNY communication that this was under consideration.I think that evolution is a good way to go but there are zero standards that help with that – but as you say – with a little talent, agility, and time – they can be solved one at a time in priority order. I have told lots of potential Sakai deployers that they need to look at an evolution rather than replacement approach. Sometimes you bring new features into an existing system and other times you put in a new system and then pull in some features of the old system in to help with user comfort. We have a number of examples of this second approach with Sakai sites that really are best described as hybrids.Again a well-designed and well supported standard would like TI be so sweet to enable this in a less painful manner. (again the plug for TI).