Same area, different goals; Sakai and the JISC Framework Programme
With Managed Learning Environment (MLE) implementation increasingly moving from theory to practice, two major initiatives come along at once. One will deliver a customisable but complete 'community source' MLE, the other a means of stitching together an MLE out of bits you already have or want. We talk to Chuck Severance of Sakai and Tish Roberts and Scott Wilson of the JISC Framework Programme about differences and similarities.
The case for an MLE is clear: few people want to manage the same information in many different systems that are completely unaware of each other. Why have several different discussion tools or calendars of varying usefulness, in different sites with different log-ins if you could have the best one of each, in a consistent and joined-up environment? Even if the user experience is not top priority, at least the elimination of time-consuming and error prone data duplication should be worth it.
Question is, of course, how?
One way is to buy a complete, ready-made system from a commercial vendor. Nice and easy, if you can afford it, have a do-able migration path from the systems you already have and if the vendor really is able to provide the best tools for your needs. Given the investment involved, that would be present and future needs, and, given how central an MLE will be to the core business of the institution, 'best' really means 'fits like a glove'.
Should those conditions not obtain, Sakai and the JISC Technical Framework Programme aim to provide two more alternatives. Sakai by pooling MLE development effort from several major US research universities and a partner programme of quite a few more in a tightly managed programme (hence the 'community source'). Within a few years, Sakai is to turn a number of existing enterprise systems into a coherent whole, with a means of extending and customising it via open source code, and an ecology of re-useable tools and developers around it.
The JISC Technical Framework Programme also aims to create an ecology of tools and developers around open source code, but with a difference: in a rolling series of short, focussed, community-led projects, the means of joining up whatever systems the community has or wants are to be developed. Because the means of joining-up are to be based on specifications, systems can be swapped out, or new, lightweight tools developed to piggy-back on existing ones.
To explore the differences and commonalities a bit further, we invited Chuck Severance, the technical committee chair of Sakai, and Tish Roberts, JISC's programme director for the technical framework programme and Scott Wilson, senior consultant on the JISC project, for an interview.
What would you consider the major difference in the pedagogic goals of Sakai and the JISC Technical Framework Programme?
Sakai does not make pedagogy a priority. Pedagogic approaches are still very much a matter of ongoing debate, and we can't wait for that. Sakai will make a range of pedagogically neutral tools available for pedagogic experts to extend. We can't afford to make presuppositions on that front right now, we're in a hurry.
JISC seems interested in both technical and pedagogic exploration, pushing the envelope of both, piece by piece. They seem to have more time, and willing to take more risk.
The component based approach of the JISC FP is a different means to provide the same flexibility in fine tuning your pedagogic approach. And it is true that we have a greater flexibility to absorb risk: both because we have more time, and because we don't have to deliver a complete turnkey system. We can develop and refine, component by component, over time.
It's worth mentioning that there's a sister strand to the technical framework: the pedagogic strand. Projects in this strand will run at the same time, and evaluate whether the tools developed in the technical strand will meet pedagogic demands. We will therefore have a continuous feedback loop in this area.
There is a great deal of similarity and both initiatives cover similar ground. The divergence lies in that Sakai is very Java (the widely used programming language, WK) oriented. Java is the lingua franca; the JISC Technical Framework Programme uses webservices instead. Again, this is a matter of risk- we will be able to learn from the JISC there. We know how Java works as a means of integration, but webservices is rather newer and a bit riskier.
But there is some movement on the issue within Sakai- we initially thought webservices support was two years out for us, but we will now actually start looking at it in the fall. This is a direct consequence of the Sakai Partnership Programme, as there are a lot of partners who are very interested in making use of webservices technology. So we might learn from JISC FP experience pretty soon.
The two approaches fit very well, as they factor major functionality in a similar way. But Sakai is much more user interface level oriented, we are more about back-end integration, we don't have to worry about user experiences or look and feel, and that is what a lot of Sakai is about. The JISC Technical Framework Programme FP and Sakai are complementary in that sense.
I fully agree
If I had to write the first sentence of the Sakai report in two years time, it'd love to be able to say: "sakai has produced a course management system in two years used by at least 50 institutions, and it is being actively extended by a large community of developers"
The JISC Technical Framework Programme is about supporting the different goals and approaches of diverse institutions united into one technical framework.
We are covering each other's risks. The main point of convergence here is APIs- not necessarily low level ones like 'getX' or 'closeX', but higher level ones that do the persistance and business logic of more complex operations. For example a scheduling service of which a program may want to ask "how many students have registered for this course in the past four weeks". It is at this level that we'll probably see a convergence between the webservices based JISC Technical Framework Programme architecture and ours.
The critical point on convergence is whether there will be agreement on datamodels such as those defined by IMS; they'll have to be researched thoroughly, to make sure they fit everyone's needs. We need to cooperate there to make sure that we can get the interoperability between the two approaches without compromising functionality.
Absolutely, there's lots of standards in this area, but few with a model that is abstract enough to allow us to bind it independently of technology (Java or webservices). We need to keep communicating in the way we already have, exchange people, maybe meet every six months to see how far we've come to ensure that we can interoperate.
We'll be going to attend the first Sakai Partnership Programme meeting in the summer, and we'll be organising a conference on interoperability here in the UK in the autumn to which we have invited Sakai representatives. We're planning a slot for them to present their work and explore the ways in which we can converge the initiatives.
It will be critical that our common work will eventually be handed to a public specification or standards organisation to make sure that it is sustainable, of wider applicability and can be internationalised. There's always a danger in doing this stuff that you create solutions that work for your specific purpose, but that, with a little effort and consultation, could be made to work for everyone. Particularly in the area of datamodels. Organisations like IMS, IEEE LTSC, ISO SC36 for the educational stuff or OASIS, WS-I or even the W3C for the lower level stuff could all be good fora for achieving this. We can look at each service and decide the most appropriate body.
Good question! Those institutions that can afford it have always built their own stuff. We at Michigan did that too, and we once went through an exercise of figuring out why exactly. What we came up with is this: what we do at universities is teaching, learning and research. We can't outsource the software that supports that- you can't outsource your destiny. You shouldn't have to negotiate with an outside commercial provider about things that directly affect your core business.
So building your own MLE software allows an organization to take charge of its own destiny. But building a completely unique package for your own use is really a bit lonely and somewhat expensive. By working together in Sakai, we can control our own destinies and avoid the cost and risk involved in the solo path. Major research institutions can build the large components and the framework, smaller ones can customise the tools they need.
There will always be a place for closed source. I hope that Sakai will, in a few years, be a reference platform that forces the vendors to implement standards developed elsewhere- such as the JISC programme or IMS. The MLE industry has tried standards development before, but that has not always worked because there is not enough incentive for vendors to adopt them. In the future, if Sakai is there with the standards support, they'll have to follow, so that we'll be able to see interoperability and code portability between not just Sakai installations, but WebCT and BB too.
It's similar in vision- we want to take away any excuses for not implementing standards. We'll do it by making it as easy as possible to implement standards by providing IETF style libraries that do the hard work. User experience and features is what vendors focus development on, libraries for back-end standards support provided by someone else can therefore be a major boon for them.
We want a mixed market, cut down on duplication, and encourage specialisation among vendors. They can concentrate on what they do best.
uPortal (open source portal software, to be integrated into Sakai, WK) is an interesting point there: they are ranked number 4 out of all portals by one of the major consultancies, so it has the capability; it is a recognised world class portal. But it has not squeezed out the commercial competition, though it has upped their game. That could prove to be true of Sakai as well.