Unizin Data Platform - SP

Last updated: November 22, 2023

This document is an amendment to Unizin's general Support Policy.

The information contained in this policy applies to Unizin Data Platform only.

UDP Data stewards

Per its data governance policies, Unizin requires that Universities identify at least one "UDP Data steward." Unizin defines a "UDP Data steward" as an individual who is formally authorized by their Institution to grant, modify, and revoke staff access to the UDP. Institutions may use other terms for this role.

Working with the Unizin Support team, UDP Data stewards will grant, modify, and revoke University staff access to the UDP. At present, that process is full-service and begins with submitting a support request.

The Unizin Services team will only fulfill requests from known UDP Data Stewards and when they have those Stewards’ explicit written consent.

During the UDP implementation process, a University will identify its UDP Data Stewards. Changes to a University's UDP Data Stewards (add, remove) are conducted through the Unizin Support team in conjunction with your University's executive leadership.

SIS data integration and change management

As part of their UDP implementation, Universities are required to implement a data integration between their Student Information System (SIS) and the UDP. During the implementation process, the Unizin Support Team will work with Institutions to implement their SIS data integration. A central aspect of this process is the University's responsibility in producing an SIS dataset that conforms with Unizin's SIS Loading schema. The SIS Loading schema defines a specification (data format, data elements, etc.) for SIS data integrated with the UDP.

Periodically, Unizin will update its SIS Loading schema with the participation of its consortium members. When a new version of the SIS Loading schema is finalized, Unizin will publish the new SIS Loading schema version to its Community Site and share it with UDP Sponsor teams.

Member Universities will be responsible for updating their SIS data integrations within a reasonable amount of time after the new SIS Loading schema version is declared complete. "Reasonable" is meant to be at least one quarter (3 months), but no more than two quarters (6 months) after Unizin supports the use of the new loading schema. By "support" is meant that the UDP can import data conforming to a loading schema.

Unizin SIS data/Google Cloud Storage bucket retention policy

Unizin maintains a 14-day Google Cloud Storage bucket retention policy for all SIS datasets per institution. Unizin will retain inbound SIS data in our infrastructure for 14-days.

LMS data integration and change management

Unizin and Institutions share the responsibility for the Institution's Learning Management System (LMS) data integration with the UDP. At present, we only support the Canvas Learning Management System (by Instructure). Both context data and event data are available from the Canvas LMS.

Context data. Institutions are responsible for providing Unizin with appropriate credentials to access an Instructure-provided service called Canvas Data. Unizin is responsible for configuring an Institution's UDP to import Canvas Data.

Unizin's scope of support for LMS data integrations is defined by its LMS loading schema. Unizin is not required to evolve its LMS loading schema with the evolution of the Canvas Data service. Unizin will do its reasonable best to identify valuable changes in the Canvas Data service and make the appropriate changes to its LMS loading schema. Unizin will do its reasonable best to update its LMS loading schema on a quarterly basis, if appropriate, to integrate new context data from the LMS.

Unizin is not responsible for the frequency by which Instructure provides updates to Canvas Data. It is also not responsible for the latency of the data in Canvas Data. However, Unizin is responsible for integrating new Canvas Data updates within 24 hours of their availability.

Event data. Unizin and Institutions are together responsible for configuring an event integration between the Institution's Canvas LMS instance and their UDP. Generally speaking (since this model may change over time), the Institution will need to configure their Canvas LMS instance to send event data to either their UDP or to a resource managed by Unizin that relays event data to their UDP. Unizin is not responsible for both the quality and standards-conformance of Canvas LMS event data.

Vendor tool integrations

Institutions submit a support request to begin the UDP data integration of a vendor tool.

There are two components to any UDP data integration: a context data integration and an event data integration.

After Unizin Services receives a tool integration request, it will assess whether one or both components of an integration is available. If the vendor tool is not known by Unizin, then a context data integration is likely not immediately possible. By contrast, an event data integration may be immediately possible if the tool supports the IMS Global Caliper event standard.

In the case that a context integration is not immediately available, Unizin will begin discussions with the tool provider to develop a context data integration. Unizin may solicit the participation of its Member Universities in developing data integrations between tools and the UDP – but Member Universities are not required to participate.

All tool data integrations to a Member UDP must be authenticated and authorized. Unizin Services will generate the credentials necessary to authenticate the tool data integration with your Member UDP. Once those credentials are generated as appropriate for either the context data and/or event data integration of a tool, Unizin Services will work with the right parties to configure the vendor tool.

How a tool is configured to integrate data with the UDP will vary. One of two methods will be followed:

• Self-service configuration. The vendor tool includes a customer-facing, administrative tool that enables an institution to configure the UDP integration. In this case, Unizin Services will provide the right credentials to the Institution.

• Full-service configuration. The vendor must configure an Institution’s tool implementation to integrate data with the UDP. In this case, Unizin Services will provide the right credentials to the vendor.

Note: it may be the case that the two components of a vendor data integration are configured differently (self vs. full-service). Unizin Services will coordinate the right integration path in all cases.

* Unizin partners with vendors to develop data integrations between their products and the UDP. At times, Unizin may solicit the participation of its Member Universities in developing data integrations between tools and the UDP. Member Universities are not required to participate in this process.

Vendor data integration service levels

The UDP is capable of ingesting context data from diverse sources at different frequencies. The UDP can also ingest different “versions” of source data. In practice, however, the service level for any data vendor tool integration will vary based on several factors, such as the frequency by which source data is generated and pushed to the UDP.

The UDP is also capable of processing and enriching event streams that flow into the UDP. In practice, however, the ability of the UDP to enrich incoming event streams for any particular vendor tool will depend on the presence of context data. In addition, Unizin will need to work with a vendor to enable enrichment.

Consequently, the service level associated with any particular vendor data integration may vary.

“Most complete” data integration

Unizin will always and only implement the latest and most complete expression of a vendor data integration. Assuming that a vendor data integration supports both a context and event data integration, Unizin will implement both components. Institutions cannot choose one or another component of the tool integration only.

Data integration version and change management

Unizin will always implement the latest version of a vendor tool’s context data integration. Unizin will also automatically upgrade vendor tool integrations, unless they introduce a breaking change in Member data. In the case of a breaking change, Unizin will allow a reasonable period for our Institutions to change their use of that data. Because Unizin defines the specs for context data integrations, change management processes are usually on the order of one or two calendar quarters.

Unizin cannot control changes in vendor tool event streams. So long as events conform with the Caliper event standard and are authorized for a member UDP event store, the UDP will accept it.

Data availability and latency

Context data. The data latency for context data varies by tools. Unizin does not control the latency of the context data provided by vendors. Typically, Unizin will seek a daily context data integration from the tool provider whose data is new "up to the minute" that it was produced. Unizin also does not control the time of day when context data batches are pushed to the UDP. Typically, our guidance is that data integrations should be refreshed overnight, but this is not always possible.

Event data. Unizin does not have control over event data latency. Vendors may choose to send event data as it occurs, or in batches; Unizin does not control this decision. Once received by the UDP, events land in near-real time, although the actual duration of event processing may vary by the kind of processing.

Support of UDP institutional environments (tenants)

Upon implementing the UDP, Unizin provides institutions with a SIT environment and eventually a PROD environment. Unizin will "hibernate" UDP SIT tenants whose use does not fall into the definition of the purpose of the SIT environment. All institutional activity, even if it is development activity, should shift to the PROD environment.

Active vs. Hibernated

When an institution UDP tenant in SIT is active, then its integration, import, and storage functions for all learning data pushed into it are operational. By “all data” we refer to both context and behavior data from the SIS, LMS, and learning tools.

By contrast, when an institutional UDP tenant in SIT is hibernated, the UDP tenant no longer imports data, all data is removed from the tenant’s data stores, and its data stores are no longer available to the institution.

Valid SIT environment activities

The purpose of this service level amendment is to define the valid uses of the SIT environment by an institution and Unizin. When a SIT environment tenant is not used for valid activities, it is hibernated by Unizin.

UDP Implementation

When an institution implements the UDP, a tenant in the SIT environment is used to drive the implementation process. When the UDP implementation process is completed, all data integrations are completed in PROD and the SIT tenant is hibernated.

The activities of a UDP Implementation involve:

• Implementing an SIS data integration.

• Implementing an LMS data integration.

Because vendor tool integrations are fully managed and plug n’ play, there is no need to test them in a pre-production environment for every new institutional UDP implementation.

Extending SIS data integrations is an extension of an implementation.

Learning tool data integration development

Unizin works with learning tool developers to implement standards-based data integrations with the UDP. In this context, it is often necessary to test new data integrations in partnership with an institution and its UDP-based data.

For testing purposes, and only with the participation of the institution, Unizin will use a UDP tenant in SIT to test new learning tool data integrations. Once the testing of a learning tool data integration is complete, Unizin will hibernate the UDP tenant in SIT.

Once a vendor learning tool integration is completed, it becomes available as a fully managed integration for all prod environments. Even if a learning tool integration is new to an institution, it will bypass SIT if the integration is considered production-ready.

Feature testing

As part of Unizin’s normal software development lifecycle, Unizin may involve institutions in testing new features before they are released to production. In cases where an institution participates in testing, the institution’s UDP instance in the SIT environment is used.

How status changes

Institutions may submit a support request to request that their SIT UDP tenant is hibernated or waked from a hibernated state (to support a qualified SIT activity). Alternatively, Unizin reserves the right to wake a UDP tenant from hibernation. It can take up to 7 business days for Unizin to wake a hibernated UDP tenant.

Maintenance windows

Unizin maintains a standing maintenance window for the Unizin Data Platform. Unizin will not always use the maintenance window to run a maintenance action. The maintenance window is set for every night between 4 am and 6 am Central Time.

Google may perform its own automatic updates or maintenance to the Unizin Data Platform infrastructure (in Google Cloud) during the following window:

• Sundays from 1:00 AM - 2:00 AM CST

This will only occur if/when there is an available update from Google.