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.
I was struck by your comments, “After several years of cross-campus collaborative efforts to better link the variety of services, UCLA decided to join the Sakai Educational Partners Program,” and that UCLA wanted to, “remain engaged with the higher education community and the Sakai Foundation in order to work on interoperability of Moodle, Sakai, and other CMS/CLE solutions.” To be honest, at SUNY we found that Moodle was not designed with service integration and interoperability in mind, and the Moodle community was not interested in undertaking the development to make SOA possible (although we did feel Moodle was a better designed and developed application with a stronger community).
I am curious if the above considerations were part of the decision making process, how Moodle's technology and architecture was assessed, and how the FCET felt Moodle's architecture provided (or could provide) for the integration of services and interoperability?
Thanks Ruth, and best of luck, Patrick
- 911 reads
