Child pages
  • Response to Request For LMS Software and-or Services
Skip to end of metadata
Go to start of metadata

Friday 10-1-2010

TO: Mark Berman, MCLA
Information Technology Services
375 Church Street
North Adams, MA 01247


Thank you for sharing your RFR with UMassOnline, as I mentioned previously when the RFR was first released, UMassOnline was very interested in joining MCLA in an assessment of the both the current market of LMS technologies and the various teaching and learning environments they support.

From both the notes sent out through the CIO listserv as well as the distributed RFR, it appears MCLA and the affiliated institutions are interested in demonstrating a community of interest, and thus potential adopters, in order to leverage the collective user-base through negotiations and during procurement with LMS vendors (e.g. Blackboard, Desire2Learn, eCollege, etc.) and LMS service providers (e.g Embanet, Lamda, Longsight, Moodlerooms, Remote Learner, rSmart, Unicon, etc.). This is UMassOnline's goal as well.

Traditionally, as has been provided within the RFR, in order to provide potential respondents with the type of information needed to formulate an accurate proposal, the RFR would contain not only the details and descriptions of LMS functionality and basic campus demographics (such as FTE, online enrollments, data storage, etc.), but also specific technical requirements (integration with SIS, Library, IdM, and 3rd party applications such as e-portfolios, plagiarism detection, desktop sharing, media streaming, etc.) as well as any institution specific business requirements associated with online learning (enrollment processes, blended/hybrid/asynchronous courses, training, end-user and technical support, etc.).

Obviously, while many campuses provide access to courses online, the teaching and learning methods supporting specific academic programs and business practices employed by campuses enabling access, vary considerably. With most organizations undertaking a technology assessment and implementation, considerations are limited to local needs. That is, as there is a single campus, and that campus will host a single instance of, in this case, an LMS, functional and technical requirements gathering is rather straight forward, reflecting that single campus' current needs and future direction. However, UMassOnline, as a community-managed centralized service provider for fifteen campuses located within the University of Massachusetts, offers a different suite of services and support, as well as a different business model and thus value proposition, than those of commercial or open source LMS developers and the Application Service Providers that host them.

A few examples we have encountered include:

  • Hosting: Will all campuses want to host the LMS locally or engage with an ASP model? How might the diverse hosting interests of campuses affect pricing and service models? For example, local hosting with contracted support like Remote Learner offers, versus remote hosting through Moodlerooms - indeed, it is possible that some hosting providers will offer other options such as a virtually managed appliance or co-location models. The costs associated with a single campus implementing one of these options will vary considerably from a consortium of campuses, each selecting different hosting models. Any hosting model offered by UMassOnline, and thus costs, cannot be determined until each of our current campuses have provided their expectations and capacity around hosting.
  • Integration: Will all of the campuses currently supported by UMassOnline expect the same level of integration (do they all share the same SIS for example)? Moodlerooms offers real-time (but one-way) integration with Banner, but two way integration with PeopleSoft (meaning grades, for example, are pushed back from the LMS to the SIS). However this requires campuses to implement Oracle's SAIP IMS LIS integration tool set. In addition, are there custom connectors or integrations that have been installed and deployed at individual institutions (Safe Assign, Turn-It-In, Chalk & Wire, OWL, etc.)? Also, are there any considerations in place for multi-campus integration (either technical or programmatic)? In order to identify the scope of services, and thus costs associated with the delivery of those services, UMassOnline must first undertake and audit of our campuses' current integration points and business workflows.
  • Support: Many campuses have different levels of end-user and technical support available on their campuses. Defining support levels, accommodating campuses with various help desk functions and availability, must be done before any pricing schedules can be defined.
  • Reporting: Many campuses have developed custom reports for Institutional Research, marketing, early warning (student jeopardy), retention, etc. UMassOnline would need to understand these practices in order to not only ensure continuity but assess costs.
  • Relationship management: How will the diverse needs (like those mentioned above), as well as evolving needs of the participating campuses, be managed within the consortium (between campuses) and with the service provider(s)? Will each campus work with the service provider(s) individually and independently per issue/request, or does the RFR define a specific relationship management process for initiating requests and resolving issues centrally? Defining the various roles and responsibilities of each campus (based on their capacity) and UMassOnline will dictate costs.

When the MCLA RFR was delivered, I expressed some hesitation about UMassOnline's ability to respond with any realistic figures or service proposals, as UMassOnline would first need to understand the issues like those mentioned above for each campus, not only participating in the RFR, but those currently served by UMassOnline. UMassOnline has reached out to all of the campuses we currently support to begin defining these very functional and technical requirements toward the eventual release of an RFI. To be honest, I had hoped MCLA would join us in this effort.

Perhaps I either mis-understand UMassOnline's current model with our hosted campuses, or perhaps I see UMassOnline's role differently than what has traditionally been provided. My expectation for UMassOnline is, 1) we should provide services and support for systems centrally that would otherwise be redundant (duplicated) if undertaken by all of the campuses across the System and/or State working with UMassOnline, and 2) provide a platform for the development of new services or systems that do not reach the tipping point on a single campus for investment (resourcing), however does spark sufficient interest across the System or State to warrant development. For example, imagine a set of technologies hosted at UMassOnline that enables multiple campuses to share tutoring services across the participating institutions. Considering this model, I guess I do not see UMassOnline as a respondent to an RFR, but a resource that would work with campuses to develop an RFR to take to market, so that each would not need to duplicate efforts (example one as noted above).

UMassOnline has been tasked recently to develop a better understanding of our business practices and service models. Some of the topics have included UMassOnline’s current suite of services. For example, I have been exploring the nature of our Service Level Agreements, pricing models, and our current product development lifecycle. As a matter of improvement I am asking, for example, if the service level agreements are appropriately developed, do the pricing models best support growth and interest in a variety of services, and is the product development lifecycle agile enough to best service a multi-campus consortium? These questions point to some of the interesting opportunities and options that ought to enhance the value that a multi-campus consortium can provide. As a consortium, it may be that UMassOnline best functions as an organization with less of a traditional contractual/commercial orientation, to one that reflects the organizational and operational principles of a cooperative, taking advantage of the interests of a group of individuals working together for their mutual benefit.

To this end I would like to offer MCLA, and the partner campuses included on this RFR, the opportunity to join UMassOnline's Learning Platform Review (LPR). Below you will find an outline of the LPR process for your consideration. It is my hope you will find some value in, not only the process for identifying both the next generation LMS, but also a platform that enables and advances online education across the Commonwealth of Massachusetts.

In addition, you will find below a direct response to the questions included within the RFR. While many of the responses might or might not satisfy specific fundamental requirements included within this RFR, I would like to honor the spirit in which each was created in order to help MCLA and the partner campuses understand both UMassOnline's current services and vision for the future.

If you have any questions please feel free to contact me directly, and thank you for your consideration.

Patrick Masson
Chief Technology Officer,

Table of Contents

Learning Platform Review Process

Please follow this link to learn more about UMassOnline's Learning Platform Review Process.

UMassOnline Qualifications

  • At least three years of experience in the provision, maintenance and support of software designed for the enhancement of online teaching and learning.
    • Since 2002, UMassOnline has provided systems administration, software maintenance as well as end-user and technical support for various software applications in the delivery of online education. During the 2009/2010 academic year UMassOnline supported more 150,000 enrollments across 15 campuses.
  • Ability to provide both online and on-site training in the management and use of the software package proposed.
    • UMassOnline provides a variety of scheduled and ah hoc training for each of the academic technologies delivered.
  • If a hosted service is proposed, the hosting provider must have at least three years experience in the provision and support of Software as a Service (SAAS).
    • Currently UMassOnline partners with University Information Technology Services (UITS) within the  University of Massachusetts' Central Offices for hosting services of Blackboard Vista. This relationship began with the launch of UMassOnline in 2002 and has included not only LMS support for various platforms, but several teaching and learning technologies. While UMassOnline does not directly operate or administer the resources provisioned for delivery of the learning management system, our staff does represent campuses' interests to ensure quality and continuity of service.
    • UMassOnline is currently undertaking a Learning Platform Review (LPR), which includes an assessment of hosting options, including not only the service provider but service models as well. Under consideration is: continued remote hosting through UITS or other third-party providers providing managed hosting, dedicated servers, co-location and cloud computing (e.g. AT&T, Rackspace,, Amazon EC2 ) and vendor supported LMS-specific application service providers (e.g. Blackboard Learn Managed Hosting, Hosting Services by Desire2Learn, Instructure Enterprise Hosting, Lambda, Longsight, Moodlerooms, RemoteLearner,  rSmart,  Unicon, etc.) and third-party software as a service providers (e.g. Embanet, ).
  • The hosted service must also support single sign-on, and integrate with administrative systems as well as third party tools
    • UMassOnline, as a Managed Service Provider working with a variety of colleges and universities throughout the Commonwealth of Massachusetts, works with campuses and technologies to deliver integrated services including identity management. While there are currently no campuses exploiting single-sign-on (SSO) with their LMS implementation, UMassOnline, despite the hosting service provider or model, will provide support for SSO. Currently UMassOnline is developing, independently of the LPR, federated identity management which would enable SSO using Internet2's Shibboleth System. This approach would enable campus-specific identity management for accessing local resources through SSO, while extending the shared services available to all campuses across the state who choose to participate.
  • A hosted service must Provide 24/7 technical support
    • UMassOnline currently provides 24/7 user (issues related to application access and use) and technical (issues related to availability and performance) support.

Basic Requirements

  • The application must include tools that support the learner, the teacher, and course designers to enable the delivery of online learning.
    • UMassOnline, through the LPR, will consider all Learning Management Systems and combinations of technologies to support learners, instructors, instructional designers and institutions, enabling the delivery and advancing of online teaching and learning.
  • The solution must address the need to migrate existing online course content from a variety of LMS platforms and content publishers.
    • UMassOnline, through the LPR, will include in our assessment migration of both courses (i.e. the various pedagogical approaches employed by faculty to delivery content and enable learning) and content (i.e. the various educational objects and artifacts used within a course).
  • The solution must accommodate a full range of content including, text, multimedia, and laboratory simulations.
    • All technologies considered by UMassOnline will support currently recognized content formats. In addition, UMassOnline recognizing the continual evolution and emergence of new technological formats appropriate for academic use, will also include in it's assessment system architectures that allow extending services via integration and interoperability.
  • The solution must provide the ability to link out to various external applications used for the delivery of course content, including Digication E-Portfolio, public Blog and Wiki sites, and MCLA local web servers.
    • UMassOnline, as part of the LPR, will include not only  MCLA's unique technical and educational requirements, but each of our currently supported institutions. This comprehensive approach will allow UMassOnline to offer access to and integration with a variety of services and systems to participating campuses as a consortium, expanding online educational opportunities making them greater than what would be possible by any single institution.
  • The successful solution must support a wide variety of pedagogical approaches and designs, accommodate diverse learning styles, and provide mechanisms that promote community among the learners.
    • Recognizing that the variety of campuses working with UMassOnline to deliver online courses through is diverse in not only a variety of pedagogical approaches and designs and teaching and learning styles while promoting community (again, recognizing this ideal is expressed differently among our users) but unique business processes that enable access (admissions, advising, enrollment, etc.), the UMassOnline LPR will endeavor to identify and understand both the similarities and differences in order to establish an appropriate suite of technologies.

Standards Compliance

MCLA seeks a comprehensive Learning Management System. The proposed system should comply with all relevant standards for courseware and interface with external systems. Please address your proposed system’s support for data interchange and other standards including, but not limited to, the following:

  • SCORM (Shareable Content Object Reference Model) — Also known as “Shareable Courseware Object Reference Model Initiative” SCORM is a commonly used standard for delivery of course content by textbook publishers
  • IMS GLC — A set of standards defined and maintained by IMS Global Learning Consortium
  • IEEE 1484 LOM (learning Object Metadata) — A standard defining the attributes required to fully/adequately describe a Learning Object. Learning Objects are defined here as any entity, digital or non-digital, which can be used, re-used or referenced during technology supported learning
  • _LDAP (Lightweight Directory Access Protocol) — Access to a database of information of various types. RFC 2251­6, 2829, 2830, and 3377 and related RFCs .__
  • _IMAP (Internet Message Access Protocol ­ Version 4rev1 and better) — allows a client to access and manipulate electronic mail messages in multiple folders on a server. RFCs 2060, 1731, 2087 (quotas), 2086 (ACLs ), and related RFCs ._
  • SMTP (Simple Mail Transfer Protocol) — the basic protocol for transport of electronic mail across the internet, defined in RFC 2821, 2554 (SMTP Authentication) and related RFCs.
  • SSL (Secure Socket Layer) — a protocol that provides for encryption of sessions.

While a response referencing standards compliance within UMassOnline's current LMS implementation, Blackboard Vista, might satisfy the fundamental requirements of this RFR, it would not satisfy the spirit in which this requirement is included in the Response. Like MCLA, UMassOnline shares an interest in identifying a standards-based and compliant platform for the delivery of online education (courses, content and community). Each of the above will be included within the UMassOnline LPR as well as others, for example:

  • Application Programming Interfaces (API) — An interface implemented by a software program that enables it to interact with other software. It facilitates interaction between different software programs similar to the way the user interface facilitates interaction between humans and computers. An API is implemented by applications, libraries, and operating systems to determine their vocabularies and calling conventions, and is used to access their services. It may include specifications for routines, data structures, object classes, and protocols used to communicate between the consumer and the implementer of the API.
  • Internationalization/localization — Process of planning and implementing products and services so that they can easily be adapted to for international/cultural users, including: languages, character sets, graphic/icons, data space, etc.
  • IMS LIS (IMS Learning Information Services) — Specification for how systems manage the exchange of information that describes people, groups, memberships, courses and outcomes within the context of learning. The LIS specification is the means by which learning management systems exchange relevant information with other enterprise systems of record, i.e. it defines system interoperability through a set of identified services.
  • IMS LTI (IMS Learning Tool Interoperability) — Provides a single framework or standard way of integrating rich learning applications — in LTI called Tools — with platforms like learning management systems, portals, or other systems from which applications can be launched — called Tool Consumers.
  • OASIS Open Document Format — An open XML-based document file format for office applications to be used for documents containing text, spreadsheets, charts, and graphical elements.
  • Open Database Connectivity (ODBC) — provides a standard software interface for accessing database management systems (DBMS). ODBC is independent of programming languages, database systems, and operating systems. Thus, any application can use ODBC to query data from a database, regardless of the platform it is on or DBMS it uses.

Usage Requirements

The proposed LMS system must be capable of supporting at least 20,000 active student user accounts, 500 faculty accounts, and 25 administrator and/or instructional designer accounts. Full featured Web access must be available for all user types.

  • UMassOnline — with over 150,000 enrollments annually, provides access to 1000+ faculty, and administrative access to 15 campuses via the web — regularly sees peak concurrent sessions at 10,000+ unique users.
  • UMassOnline's usage requirements and the architecture that supports them, as a Managed Service Provider for multiple institutions, will differ significantly from campuses implementing a single instance of an LMS for their campus. However, while UMassOnline's scale and scope of services described within the LPR will be broader than any single institution, they will provide for the individual needs of each campus.

Security Requirements

Security and privacy are important to MCLA. The proposed solution must support encryption for access and authentication/authorization. Adequate protection of the data store from hackers and other unauthorized users must be demonstrated. At minimum the SSL protocol should be supported.

In the course of providing services to the college, the vendor may be given access to personal information about members of the MCLA College community. The vendor will maintain the confidentiality of all such personal information, and except as provided by law shall limit access to personal information to employees and subcontractors who perform services under the Contract, and shall promptly destroy any copies of personal information maintained by the Vendor upon completion of the tasks that required use of the personal information. Upon request the vendor will supply a list of all employees and subcontractors who were provided this access. The vendor must also be fully in compliance with Massachusetts data protection regulation 201 CMR 17.00.

Like MCLA, as a State Agency within the Commonwealth of Massachusetts, the University of Massachusetts, The Office of the President and UMassOnline must comply with state and federal law, as well as University policy, regarding Information Security, Data Security and Personally Identifiable Information.

Currently, UMassOnline provides access control to online resources through secure login to the LMS as well as site-wide encryption via Secure Socket Layer (SSL). Access to, and validation for, Vista accounts are determined by participating campuses. Like MCLA, UMassOnline will include within the LPR, specific requirements for data security, access control, protections for Personally Identifiable Information, as well as compliance with Federal, State and UMass law and policy, e.g. FERPA.

Records Retention

All communications records sent and received during the conduct of college business may, depending on their content, be Public Records as defined by M.G.L. c. 4, §7, cl. 26th, and should not be deleted except in accordance with policy. Public Records must be saved by the custodian or keeper of that Public Record to a permanent electronic record system (i.e., saved in a digital archive) and preserved in accordance with the current Statewide Records Retention Schedule.

The successful response will propose a data archival solution to aid in compliance with these requirements.

Again, as part of a government agency within the Commonwealth, UMassOnline, like MCLA, must comply with all state and federal policy regarding records retention. In addition, as a matter of business practice, UMassOnline strongly believes in data and document retention to not only ensure compliance with Freedom of Information Requests, legal requests and student challenges, but also as a means to insure business continuity and planning. Business and operational records are developed and stored in UMassOnline's enterprise wiki with controlled access to ensure confidentiality and security. This provides a digital repository for document retrieval and referral as well as a knowledge base for reference and organizational cohesion.

Specific to academic materials (courses and content), currently UMassOnline retains course backups for one semester after course completion and provides course archives to participating campuses via DVD each academic session (four times per year). For example, a course delivered in Spring of 2010 will be archived by UMOL to DVD and sent to the campus. In addition a local archive of the Spring session courses will remain archived by UMassOnline over the Summer of 2010. UMassOnline will then remove this course content from local resources in Fall of 2010.

Desired Features

The response must address the following desired features.

It is understandable that a list of desired features and functionality specific to teaching and learning and system's administration would be included within this RFR, however as UMassOnline is currently undertaking it's own Learning Platform Review due to the upcoming retirement of Vista by Blackboard, providing a specific feature set for UMassOnline's LMS will not be possible at this time.

Detailed Issues and Questions

Please answer the following specific questions regarding your proposed solution:

  • What technology is used for the storage of data? Database? Which database?
    • Future database architecture and administration will be subject to the findings of the LPR.
  • What special features are provided to support handheld and mobile devices such as a PDA, iPhone, or Cell Phone?
    • Mobile access and capabilities for future implementation will be subject to the findings of the LPR.
  • To what extent and using what methods is the proposed solution customizable to meet the needs of MCLA for such things as
    • Look and feel: branding
    • Interface with local applications such as e-mail and blogging packages
      • Customization options for branding, integration and interoperability will be determined by the LPR.
  • Describe the ability to interface with Banner: feed specifications and API.
    • Systems integration will be determined by the results of the LPR.
  • What provisions are there in the proposed solution for redundancy, failover, or other methods of providing highly available service?
    • Availability and continuity through disaster recovery, redundancy and fail-over will be determined by the results of the LPR.
  • Are there any Single Points of Failure in the proposed solution?
    • Vulnerability will be measured through the LPR
  • It is preferred (but not required) that the successful bidder will provide migration and conversion of existing course and account data to the new system. Please describe the tools that could be used to accomplish this.
    • A specific migration plan for course and content migration will be determined as part of the LPR.
  • What tools and features are available to the Systems Administrator to manipulate, rename, move, edit, and otherwise work with user accounts and course data?
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • Describe the training and documentation that will be provided.
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • What on-going costs are associated with the proposed solution? Do maintenance fees, if any, include software updates and/or bug-fixes?
    • Currently all associated costs with LMS delivery and support are included in UMassOnline pricing. UMassOnline's current business model is under review, and while not specifically part of the LPR, the results of the review will have significant impact on the delivery and pricing model.
  • Describe any technical support that will be provided on an on-going basis? How is support obtained? Describe escalation procedures in the case of a severe or extended problem. What initial period of technical support is provided with the initial purchase and what are the costs of technical support beyond the initial period?
    • UMassOnline provides 8x5 live support and 24x7 oncall technical and user support to participating campuses. This is complemented with after hours, third-party support for users through Perceptis and technical support through UITS.
  • What alternate hardware and/or operating system platforms are available for the proposed solution? (If not a hosted solution).
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • Is a service level agreement or guarantee provided? If so please describe its parameters.
    • An SLA will be offered to participating campuses, however specific details will be determined by the LPR process.
  • Does the proposed solution support automatic processing for data beyond a certain age such as archiving, deletion, relocation, compression, etc.?
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • Can the proposed solution be upgraded or patched without interrupting services?
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • Does the proposed solution support hacker avoidance techniques such as locking a user account after a defined number of login failures? What other hacker avoidance techniques are available?
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • Please describe the capacity limits of the proposed solution using the following parameters:
    • Number of Accounts (student, faculty, administrator)
    • Storage Capacity
    • Transactions Per Second
    • Maximum concurrent users
    • Chat room maximum concurrent usage (if applicable)
    • Maximum concurrent data streams (video or otherwise)
      • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • Fully describe how the proposed solution can interact with LDAP services for user provisioning. Describe any required schema elements. Can the solution use LDAP as the source for authorization to access individual data elements? Are user accounts provisioned automatically on a successful LDAP authentication if they do not already exist?
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • Describe any routine tasks required to maintain operation of the proposed solution at optimum efficiency.
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • Does the proposed solution support SNMP for Monitoring and/or Management? If so, what is the highest version of SNMP supported? Describe SNMP Manageable elements.
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • Describe methods and tools supported to provide hooks for extensibility into the system. These could include: API, XML, Scripting Languages…
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • What provisions are built into the proposed solution for Disaster Recovery?
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • Are there any restrictions on the naming of accounts such as reserved characters or words?
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • What reporting tools are provided for statistical analysis? What Log and/or Audit analysis tools are provided?
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • Are any special considerations required to perform routine data backup of the proposed solution? (for example: database shutdown).
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • Please provide a roadmap of future development of the proposed solution including functionality, standards support, and/or integration with other systems or products.
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • If the proposed solution is a hosted one, please provide the physical location(s) of the server(s). If servers are spread across multiple locations, will MCLA et al. have any say in which locations are used? Are any server locations outside the USA?
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.
  • If the proposed solution is a hosted one, where are data backups stored? Are the backups accessible by college staff.
    • This will be determined by the final product selected, the defined hosting model and support levels identified through the LPR process.Interestingly, I was going to send you a message letting you know UMassOnline would be interested in joining your RFR.