Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 46 Next »

The draft Reference Architecture for Teaching and Learning (RATL) is a product of the ITANA Learning Working Group in 2012-2013.

This site is under development as we continue to incorporate and expand on the working group's findings from 2013. Thank you to all the working group contributors!

Introduction

The Reference Architecture for Teaching and Learning (RATL) is a resource for architecture in teaching and learning enterprises, primarily institutions of higher education. Using the RATL, architects and other leaders can map their enterprise, assess its maturity, model the effect of new goals, and plan for proposed changes.

The RATL was developed by the ITANA Learning Working Group in 2012-2014 in response to ongoing disruptive changes in the practice of teaching and learning, and the perceived need for a reference architecture that bridges existing standards efforts and discussions in the higher education community.

For a summary view of the topics covered in the RATL, see the Teaching and Learning Capability Map.

Using the RATL

Modeling Changes

Scenarios

Each scenario in the RATL describes a common set of circumstances in a teaching and learning enterprise, a typical goal for change, and considerations for responding to the change. Scenarios are linked to interrelated assets that may be affected or needed, and may include real-life case studies from other enterprises.

  1. The provost tells us we must allow current students to receive credit for enrollment in, and successful completion of, a MOOC offering.  The ability to do this might require the following:
    1. Establishing criteria for successful completion
    2. Recording a current student's enrollment in a MOOC offering.
    3. Capturing usage and assessment (if any of that) data from the MOOC
    4. Evaluating success according to the established criteria
  2. The Learning Management System currently in use no longer supports all of our learning goals.  We must systematically lay out the capabilities needed at our institution and use these requirements to do a fit-gap.  The outcome might be to replace it, to supplement it, or ...   (needs to be taken down one level)
  3.  Our learning analytics capability is extremely limited.  We need a reliable student early warning system to promote higher retention.  We need better to assess changes in curriculum to guage the impact.  The usage data we have captures only a fraction of the student's learning.  There are lot's of tools in use from which we have no data at all.  (implies infrastructure to ingest data from multiple tools and system including those that cloud-based)
  4. Increasingly, students' work is presented in the form of rich media (e.g., movies and photo sets)
    1. our facilities for helping students prepare the work are limited and inefficient (implies improved access to rich media equipment, better training, better support for collaboration)
    2. our facilities for handling their submissions are ill suited to the purpose.(might imply a different architecture and greater capacity for submissions.  The architecture needs to account for access scoped by class and collaboration group.  It may also imply the need for different presentation support)
  5. Our provost wants the student record to include both the timetable classes and the "non-credit" classes.  That way we can track ALL of a student's engagement at our institution and better support the life-long learner. Timetable classes usually require students to be enrolled in a degree program.  "Non-credit" classes, on the other hand, do not usually require that.  A "non-credit" class can have many purposes and take many forms: it can be for professional (re)-certification or personal enrichment; it can be part of a larger series or a single, one-off class; it can lead to a certificate or not.   This might include milestones such as the following:
    1. Requires re-defining the meaning of student and the policies regarding assignment of resources to students
    2. Adjust the identity, authentication, and authorization capabilities to handle all these students
    3. Streamline the delivery of roster information to the non-credit instructor and, when needed, to the non-credit LMS
    4. Streamline payment processing
    5. Might imply more unified or standards-consistent use of CRM and local record keeping among the providers
    6. Adjust the SIS to support a single student record
  6. There is a proliferation of tools.  Some are publisher supplied, some come from the institution's LMS, some come from other cloud or on-campus services.  How can we provide a more coherent interface to our students
  7. The institution is tracking the viability of eTexts.  What would be required to provide eTexts to students as an option?  Should we promote a single reader or should we allow many?  Should we capture analytics from the reader, and if so how?  What information is needed to assess the merit and viability of such a capability?
  8. Related to the above, the university wants to explore setting up a repository and catalog for instructor-developed eTexts.  This would possibly be in collaboration with other institutions
  9. Key decision-makers want to promote the move towards outcomes-based learning.  This recognizes new ways to demonstrate mastery and implies a shift from the course- and term-centric structure of degree programs

The RATL Library

The RATL includes a reference model for understanding a teaching and learning enterprise. The reference model consists of interrelated assets that enable a typical enterprise to carry out its mission, including business capabilities, roles, processes, data, and tools.

The Teaching and Learning Capability Map introduces the capabilities and related assets found in the following library sections:

Capability Library

Capabilities summarize what a teaching and learning enterprise needs to be able to do to succeed.

Roles Library

An enterprise's capabilities are supported by people acting in roles.

Process Library

To carry out its capabilities, an enterprise creates business processes.

Data Library

In carrying out its capabilities, an enterprise consumes and produces data.

Tools Library

To carry out its capabilities, an enterprise implements tools.

Related Standards

Standards help to define how assets should be selected and designed to support capabilities. The working group captured information about standards on this page:

  • No labels