3.1 Ruth sabean interview - part 1 - ucla selects open source  (Page 5/6)

One other resource that puts a lot of context around why we were so focused on a SOA can be found in a posting titled The Long Tail of Learning Applications on e-Literate by Michael Feldstein. As usual, Michael was spot-on.

The following evaluation criteria for our technology selection process were teased out of the work from our task force:

• Strong support for integration of new teaching and learning tools via open standards.
• Student-centric rather than course-centric application design.
• Support for the IMS Learning Design Specification.
• Native interoperability with SUNY’s portal environment.
• Strong integration capabilities with campus IT systems.

which were based on the task force’s recommendations to:

• Prioritize and emphasize teaching and learning
• Harness the strength and diversity of the SUNY federation
• Plan for tomorrow’s campuses

Obviously there is a lot packed into these recommendations and each are explained a bit in the Technology Strategy report. Internally, we debated the relative advantages of Moodle, Sakai, and after a lot of spirited discussion, developed a recommendation based on an SOA using some major components including a portal framework, an authoring and packaging tool, and a suite of teaching, learning, and administration tools, most of which were open source. In the end, this solution was not accepted, nor was Moodle or Sakai.

6. pmasson - march 16th, 2007 at 6:54 pm

Ruth, Great information!

I suppose I should confess that my interest in this topic extends beyond professional curiosity…

• I spent over ten years at UCLA developing software for medical/dental education, research and patient care,
• While at UCLA, I was involved in numerous evaluations and implementations including, Angle, Moodle, Sakai, WebCT, and even a home grown tool,
• I was involved in a similar process at the SUNY Learning Network (SLN), to identify “the next generation” of teaching and learning for “all of SUNY,” where we too narrowed our selection down to Moodle and Sakai.

While at SLN our technical evaluations focused on Service Oriented Architecture for really two reason 1) As a centrally managed service to 40 campuses, we needed to provide for a variety of online teaching styles and institutional objectives, and 2) We wanted to provide a components-based framework that allowed the teaching and learning folks to deploy new tools independently of the “system” based on pedagogical needs. I wonder if these are similar to any of UCLA’s requirements?

Considering the above, we felt Sakai offered a better architecture. To be accurate, we felt Sakai could provide a better architecture: we had serious concerns about the actual state of development (In fact, while at UCLA, many of the discussions I was in with Sakai focused on the use of uPortal. Unfortunately, in my opinion, SOA and uPortal were abandoned by the time I was working for SUNY).

Of particular interest for us assessing the technology, was not only integration, where tools would present together (an identity management issue), but also interoperability, where information could be exchanged at run time between tools. That is, not only does the Sakai grade book tool and RPI’s Bedework calendar (two independently developed tools) present together in the presentation layer (the portal), but when I post a new assignment to the grade book, with a due date, it appears in the calendar. This would allow the teaching and learning professionals to provide “best-in-class” tools without significant development or even re-deployment of another LMS.