SOA at SUNY

A JISC interview with Patrick Masson, (via EdTechPost) formerly of State University of New York, who implemented a service oriented architecture, based around a mixture of LAMS, uPortal, Sakai and their own tools. He is honest about some of the difficulties, but still remains convinced about the need for a SOA solution for VLEs.

A few things from my perspective - firstly SUNY is a case study I use in my book, but this section would now obviously benefit from this kind of material. So once again one is faced with the time lag between writing something and it being published - the book is out in March and there are already bits of it that feel dated (ahem, it's still worth buying though!).

Secondly, he reflects my own feeling on Sakai, saying "I wonder why Sakai isn’t devoting its time and energy to producing a framework which at the end of the day many people could use, what do we gain from getting another Moodle?". I always felt that this was what Sakai really offered, a method of integrating different services, but they seem to have been distracted by the need to deliver a product. In doing so I think they have lost some of the clarity of their approach.

Lastly, it reinforces for me that the OU was right to adopt Moodle as a kind of middle ground between the full SOA and a monolithic system. As project director I had recommended the SOA, but Moodle provided a firm enough technological base to work from, while still allowing us freedom to develop. Whether Moodle remains the right choice in the face of web 2.0 technologies will be the next question.

Comments

[Patrick Masson]

I would be interested to learn more about your SUNY case study. Which book?

Thanks,
Patrick

[Patrick Masson]

I would be interested to learn more about your SUNY case study. Which book?

Thanks,
Patrick

[Martin]

Hi Patrick
it's the Virtual Learning Environments book, published by Routledge. See the link in the left hand column.
Best,
Martin

[Patrick Masson]

Martin,

Just finished "Virtual Learning Environments" and think you've nailed it. Much of what you include in the book were the same principles behind our design and drivers for the future vision of SLN2.0 (or what I wanted to call SLNtoo). These included:

- Perpetual beta, or what we called "versionless development." As you described, new tools discovered by (or even developed by) users could be first integrated within their own course and then move out to the larger community. If the tool was of interest, it would live on. The portal environment allows users to select from a palate of tools (the components based framework) depending on their own course objectives. This would be a tremendous asset for the SUNY System with many specialty campuses and programs including a School of Ceramics and Fashion. To make the point regarding versionless development, I often asked, "What version of Yahoo are you using?" (Perhaps dating myself, Google might be a more contemporary example, and technically more appropriate as well). Consider Google's development from a single text buffer for searching the internet to gmail, iGoogle, GoogleApps, Google Earth etc. All of these services appeared on day as a simple link to live on our die out based on use. What happened to "Froogle?" This approach not only extends functionality but reduces training needs as new functionality and features (iterations) are introduced as small increments. These slight changes never require a training session as they are relatively small in scope and tu easily found and understood. Again using Google as the example, have you ever heard of "Google training?"

- The long tail, as mentioned above; we always believed that there would be a need for specialty and niche tools and that the system should be designed to incorporate those.

- The wisdom of the crowd. When I got to SLN we had four locations online for making suggestions for development in addition to two annual conferences that included, "Grill the Developer Sessions" where end-users could nominate projects. While all of this seemed like "co-development" it really was not as, other than a title for the new functionality/feature, e.g. "grade book weightings," the community provided little else. We deployed a wiki that allowed end-users to directly describe their projects (define needs) tell stories how they were currently using services and how they would like to in future releases (use cases), etc. This not only provided better requirements gathering and development, but even QA and documentation (for training and future development) as project goals could be cleanly derived from the collaboration output of real users' project descriptions.

-Integration vs. Interoperability. We viewed integration as the exposure of different tools based on groups and permissions. Logging in might provide a user with a set of tools different that what another user might see (pretty basic). Interoperability, however is more complex, allowing data created in, or activities within one tool, to affect another. An example is a date. A date defined in any tool should propagate through the system to any other integrated tool. For example, defining a due date in the grade book would create a date in not only the course calendar, but the campus calendar and even personal calendar. (This also leads to a discussion about unified tools, i.e. why have four calendars?)

- SOA/Web Services: With 64 campuses why not capitalize on the diversity of the development pool and distribution of technology (data centers, skill sets, resources)? We hoped that tools development across the system could be aggregated through the VLE (portal). This would not only provide for a more diverse tool set (SUNY Suffolk campus had a web service for controlling a telescope-it would be great to share that with all o the campuses), but system stability and reduced costs compared to a centralized system.

There are many many others and as a technologists my interest revolve around the architecture. My colleagues Micheal Feldstien and Ken Udas, both on the teaching and learning side could provide much more regarding the impact of LD and pedagogical issues. Ken in fact was not only in the SUNY project, but also the New Zealand case study you include as well.

As a follow-up, the SLN2.0 concept was thoroughly rejected by SUNY System Administration, the Policy Advisory Committee (made up of campus presidents) the SUNY Council of CIO's and many of the instructional and technical staff on the campuses. The result was a move to Angel.

I left SUNY System Administration and now am working on one of the campuses, SUNY Delhi. Ken Udas has moved on to Penn State World Campus as its Executive Director, and Micheal Feldstien is now with Oracle working on the Academic Enterprise Initiative, with a similar goal of what both we defined for SLN2.0 and what I hear in your book.

Again, I really enjoyed reading Virtual Learning Environments, it was great to find a kindred spirit and served to validate the vision we had at SUNY (I guess we weren't crazy). I will be sending Micheal and Ken copies for Christmas.

Thanks and I would be interested to see if you discover any developments inline with what you outline for the VLE2.0.

Patrick

[Martin]

Hi Patrick
thanks for your kind words on the book. I had heard that the SLN2.0 had been rejected. One of the dangers of being brave is that senior management get cold feet about these things. It looks like you were ahead of your time. Like many others I am coming round to the idea of not having a centralised VLE at all and more loosely coupled systems (http://nogoodreason.typepad.co.uk/no_good_reason/2007/11/the-vlelms-is-d.html)- which I don't quite articulate in the book, but which follows the principles you outline above. Part of the struggle you encountered seems to me to be about the process we have for making these decisions - senior management want to have a simple decision to make 'product X' or 'Product Y' and if you present them with a more complex (but ultimately flexible, pedagogically sound) solution, it doesn't fit well with the agreed structures.
When they come to do a review in 5 year's time they'll no doubt be saying 'what we need is a much more flexible framework'...
I hadn't realised Ken worked with you, and I'm a fan of Michael's blog.
Thanks again for your thoughtful comments.