Ruth Sabean serves as the assistant vice provost for educational technology in UCLA’s College of Letters and Science and director of educational technology in the university’s Office of Information Technology.
Sabean is responsible for developing strategic educational technology plans and initiatives for UCLA that will improve the student educational experience through technology. From 1993–2002, she was the assistant director for educational technology in UCLA’s Office of Instructional Development, following positions directing and managing academic computing services at Cornell University and UCLA, and an early career in software development. She is an active member of EDUCAUSE, Seminars on Academic Computing (SAC), and the New Media Consortium (NMC). She has served on the boards of SAC, the NMC, and the EDUCAUSE Advisory Committee on Teaching & Learning. Sabean holds an M.S. degree in computer science from the University of Pittsburgh. She can be reached at rsabean@ucla.edu.
Interview with Ruth Sabean conducted by Ken Udas. Originally posted on March 12th, 2007 to the OSS and OER in Education Series, Terra Incognita blog (Penn State World Campus), edited by Ken Udas.
This is the first part of two postings that together compose an interview with Ruth Sabean about UCLA’s selection of an open source common collaboration and learning environment. This Interview is the first installation of the Impact of Open Source Software on Education Series. We welcome and encourage commenting on the posts.
Recently UCLA selected Moodle as their common collaboration and learning environment (CCLE) and decided to remain engaged with the higher education community and the Sakai Foundation to pursue interoperability. I talked with Ruth Sabean who serves as the assistant vice provost for educational technology in UCLA’s College of Letters and Science and director of educational technology in the university’s Office of Information Technology, to learn more about their decision to go with Moodle.
Sabean is responsible for developing strategic educational technology plans and initiatives for UCLA that will improve the student educational experience through technology. From 1993–2002, she was the assistant director for educational technology in UCLA’s Office of Instructional Development, following positions directing and managing academic computing services at Cornell University and UCLA, and an early career in software development. She is an active member of EDUCAUSE, Seminars on Academic Computing (SAC), and the New Media Consortium (NMC). She has served on the boards of SAC, the NMC, and the EDUCAUSE Advisory Committee on Teaching & Learning. Sabean holds an M.S. degree in computer science from the University of Pittsburgh.
Ken Udas (KU): Before we start the interview, I would like to get a better handle on how eLearning is positioned within UCLA. How much eLearning does UCLA engage in and is eLearning an important part of UCLA’s strategic planning?
Ruth Sabean (RS): That depends on how you define eLearning. I think of eLearning relatively broadly. For example, UCLA uses electronic tools throughout instruction, in a manner determined by the individual instructor of each course. The extent of eLearning varies from an enrichment strategy through to being a primary part of the course delivery. Two UCLA academic units provide online master’s degrees—an M.S.N. in Nursing Administration and an M.S. in Engineering. University Extension provides an extensive number of online courses in continuing education. But, like many campuses that offer primarily a residential experience, there is a lot of blending of technologies to enhance learning that is primarily classroom-based.
KU: We all know that changing learning-management systems is not a trivial matter. There is risk and cost associated with deployment, but also with course-material migration, faculty development, and training for helpdesk staff, application administrators, and learners. What motivated you to evaluate and change UCLA’s learning-management system?
RS: In 2002, UCLA’s Faculty Committee on Educational Technology (FCET) expressed concern over the proliferation of “course-management system” solutions in departments, divisions, and schools that required separate logins and made sharing of expertise, materials, new tools, and innovation difficult if not impossible across the campus. After several years of cross-campus collaborative efforts to better link the variety of services, UCLA decided to join the Sakai Educational Partners Program in order to support the Sakai vision and to experiment with open-source solutions and the concept of a common solution on which UCLA might converge. The FCET thought it was important for UCLA to join the national community in order to work collaboratively with others to build tools, as well as to support the vision of a higher-education-defined solution that would support both teaching and research collaboration.
KU: What evaluation and selection methods did you use and why did you select those methods?
RS: The FCET recommended that the common solution be open source. This was endorsed by the IT Planning Board and by CCLE Technical and Functional Sponsor Groups. The Assessment Taskforce evaluated solutions that met UCLA’s requirements and selected Moodle and Sakai to be evaluated in greater depth based on the functional and technical requirements.
Our methodology included doing a fair amount of desktop research to determine what options were available. We referred to Web sites, reports, white papers, and other secondary sources to identify potential systems. As there are dozens of open-source learning management environments, we made a quick cut based on factors such as project viability and maturity; activity within the community; the nature of the technology stack (for example, is the stack open source and are the dependencies open source, is the programming language too obscure?). We were also interested in knowing whether other large-scale production deployments were in existence, the strength and maturity of the development and support community, and if there was adequate support and documentation in English.
Based on this type of general analysis we were able to reduce the field to eight potential systems. We then looked at each system in terms of our meta-criteria and selected Sakai and Moodle as the two solutions we needed to assess in detail. As part of the assessment process, we interviewed institutions that had experience with Sakai and Moodle.
KU: What decision was made?
RS: We selected Moodle. You can find more information about the decision at http://www.oit.ucla.edu/ccle. It is important to note that this decision had two parts. The second was 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.
KU: What are the relevant dates (start of the selection process, date of selection, projected deployment)?
RS: This is difficult to pin down because the process has been fairly long, starting with the statement of vision in 2002. The latest round of work (by the functional and technical sponsors) started in February 2006 and produced a report in June 2006 that is available on the Web site. The Assessment Taskforce started in July 2006 and delivered their report to the FCET in October 2006. An alpha service will be available for experimentation and testing by early adopters in April 2007, when our spring quarter begins. The speed of implementation will depend on the flow of funds to support this new common service.
KU: Which parts of UCLA does this decision affect (a department, college, the whole university)?
RS: This service will be offered as an opt-in service to faculty and students. Departments, divisions, and schools will make their own choices based on how well the CCLE meets their requirements. We also anticipate that faculty will make individual choices to use some or most of the service features, such as for collaboration. Because faculty will continue to receive their support locally, we will be encouraging academic units to make collective decisions on whether and how extensively to use the CCLE service to ensure that faculty continue to find the support they need easily and that local IT staff do not end up trying to support multiple systems.
10 Responses to “UCLA Selects Open Source Solution, Part 2, Interview with Ruth Sabean”
March 12th, 2007 at 12:24 pm
Hi, Ruth. It’s great of you to make yourself available for our questions. Thanks!
n your interview you explained that UCLA’s decision to investigate a new learning management system stemmed from the university’s FCET’s “concern over the proliferation of ‘course-management system’ solutions in departments, divisions, and schools that required separate logins and made sharing of expertise, materials, new tools, and innovation difficult if not impossible across the campus.” Then later you said that Moodle “will be offered as an opt-in service to faculty and students. Departments, divisions, and schools will make their own choices based on how well the CCLE meets their requirements.” If Moodle is opt-in and not a common solution across campus, how does that address the original concern about the “proliferation of ‘course-management system’ solutions? Were there a few steps in-between the FCET report in 2002 and the decision that led to Moodle that aren’t apparent in the interview?
Hi Heather, You’ve put you finger on a really important issue. First some background. The “M” word (Mandate) is seldom used at UCLA — the one exception possibly being legal compliance. Decisions about technology and funding to support those decisions are made at the level of academic units. UCLA’s Common Collaboration and Learning Environment will be successful if it has value. Opt-in was a very important aspect of the FCET’s vision. They believed that value should be the driver of choice. The buy-in since the decision has been even greater than anticipated. Given the potential for a distributed implementation (a federated architecture with llots of Moodles running in local units), the challenge ahead will be to indeed implement a common experience for the end user. We will provide a common service and anticipate that many academic units will choose to use it, rather than run their own. Others may make that choice later when they have confidence that the common service provides the customization and autonomy they currently value from a locally provided service. Other units may continue to run their own Moodle service. UCLA, in short, has made two big decisions at the same time — Moodle and the provision of a common service.
Ruth, early in the interview you indicated that your team wants to support the Sakai vision and later you mention that want to work with both Moodle and Sakai. Why is that the case and how do you see that happing? That is, do you see these two communities working together, you contributing to both communities, etc.?
Does any of this have anything to do with the common service model that you mention in your earlier comment?
Let me step back and make several separate points. At the risk of trying to speak for a committee, here’s my view of the intention of this direction. The focus of the FCET was on ‘interoperabilty’ by which they primarily meant something like ‘if I find or already have a tool that works just the way I want it to, I want to have it work with Moodle.’ They were also making a value statement about the big vision of and for Sakai and disliked what seemed to be having to choose between software platforms when what they really wanted to see was a direction that was one notch higher. Third, they wanted to be sure that UCLA was going to stay in synch with what their UC sister campuses and with what other peers (institutions and colleagues) were doing today and would be developing into the future. They rejected the notion that choosing Moodle was walking over a draw-bridge onto a Moodle-only island. The communities to whom we will be able to contribute is a tough question at this point in the process. At the moment, we have a lot to do just to implement our first tier of shared service and getting all the existing functionality working at least as well as it does in our current installations.
Yes, I would hope that we and others can work on practical bridging strategies between Moodle and Sakai and other open-source and proprietary platforms. A lot of good work is being done already to support that vision. We look forward to contributing to that work as we have the expertise and resources to make a contribution.
Ruth, thank you for this. I understand the challenge of not only representing a group decision, but articulating the rationale for one this complex. I am going to take a stab at this also, and if I get it wrong, I welcome input from others who were involved. I made reference, in the second part of this interview, some activities at SUNY that relate to our attempt at selecting a technology platform to support learning. I think that we were trying to address similar issues that the FCET was at UCLA, but we develop a solution that was rejected internally.
If this is a topic of interest it might be worth referencing two sources. The more palatable of the two is an interview with Pat Masson on “JISC eLearning Forum” titled Developing an SOA at SUNY; Lessons learned, which can be found at http://www.elearning.ac.uk/features/masson. The second source is a little more dense and would require teasing out the relevant points. It is the Technology Strategy Report that was released as part of SLN’s Request for Public Comment process. The report can be found at: http://le.suny.edu/sln/rpc/sln2tsr.pdf.
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.
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
Hi Patrick, I think I touched on some of this in my response to your comment in the other section.
Regarding the assessment of Moodle — just a couple of observations.
The FCET did not do an architecture assessment. Although some members might have that skill set, most of the faculty on that committee do not. If you’re interested in seeing the assessment task force report, I’d be happy to share it with you. Part of that assessment involved discussions with institutions with similar scale of operations who also seemed to be effectively working on these issues. We also spent quite a bit of time talking with people who had chosen the Sakai route to understand what we might be missing.
Our sense, and I guess time will prove whether we’re right, is that Moodle seemed to be implementing standards fairly rapidly and more consistent with the definitions than Sakai at the time we compared them. So even though there were no philosophical statements being made about that, in practice there did seem to be attention being paid in terms of the work being produced.
It was also our sense that the Moodle community was interested in the practical aspects of interoperability perhaps because so many campuses run Moodle AND something else, even though there was not a lot of discussion of that as a goal.
We did observe even the 6 months or so that we were working on these choices that Moodle seemed to be learning faster from Sakai than the reserve. Hard to say if that was simply the maturity of the community or the faster pace of development because of various factors, or just that key requirements spread rapidly.
Cheers, Ruth
Hi, I don’t want to spark any grand debate here but I feel it necessary to rebut Patrick’s comments - “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”. That is quite an extraordinary statement on two front 1) given Moodle’s architecture which is fundamentally about application programming interfaces, and 2) the value judgement on what is a huge and diverse community of users. Firstly the architecture. The M in Moodle stands for Modular. It was most certainly built with interoperability in mind and it was this criteria that helped win the day back in 2004 when we selected it. Follow the link if you want to read our architecture assessment at the time (although being May 2004 it needs updating!) https://eduforge.org/docman/view.php/7/18/LMS%20Technical%20Evaluation%20-%20May04.pdf
Since then we’ve done many integrations both at the application level and with dataflows, including many beastly student management systems. We’ve used a variety of web services with Moodle, just recently SRU/SRW creating an interface with the Fedora institutional repository system. Interoperability, open standards and web services is also explict with Moodle’s roadmap.
So I struggle to understand how your evaluation cam to these conclusions? I’m also a little curious how a SOA architecture sits with the selection of proprietary Angel?
regards, Richard Wyles
Not sure how to respond to this. I don’t want to deflect this discussion either (I’m slated to contribute later on, maybe we can pick this up then).
Quickly in context to this discussion,
Our technical goal was to provide teaching and learning components independently of a system. Not really to pick a new LMS. We felt OSS was the best option for doing this. In fact uPortal was to be our “system” with disparate tools presenting depending on the user/course. We felt it would be easier to use Sakai’s tools–not Sakai, not Moodle–as independent components. In fact, we actually began with tools developed outside of “core” Sakai: the grade book and test engine, and even another project, the Bedework Calendar.
And how Angel fits into a SOA model (or at least what we were trying to do)? I don’t think SUNY cares about SOA (see http://www.elearning.ac.uk/features/masson for the gruesome details). I had nothing to do with the selection of Angel. I would love to know how Angel became the “preferred platform” for SUNY. But I do know that this topic is much bigger than what could be explained here!
Pat, Richard, Ruth, this seem to illustrate the importance of dialog. Different institutional needs will drive the selection of applications based on a variety of criteria. The methods of achieving interoperability will impact the usefulness of different applications given different requirements and intended uses. The impact here of OSS is the ability to really understand what is under the hood so we can make truly informed decisions that will influence the teaching, learning, and administrative experience. I know that due diligence, which was facilitated by code transparency, happened at the Open Polytechnic and at SUNY with different conclusions and results.
I think too that Richard struck at something with his final question, “I’m also a little curious how a SOA architecture sits with the selection of proprietary Angel?” The quick answer, as Pat indicates, is that it does not. Angel was not selected based on the requirements that guided our recommendations as outlined in the “SLN’s Request for Public Comment” document referenced above. So, considerations that lead the evalua