EDGC Decision: Data Approval Process for Enterprise APIs

Posted on

Data Approval Process for Enterprise APIs

EDGC Decision Date: July 31, 2023

Decision: Data Approval Process for Enterprise APIs

Decision

UW System is building out data integration and analytics capabilities in support of administrative transformation, most notably in the form of institutional APIs and data assets which are themselves supported by an enterprise data lake. To effectively manage access to these data assets, UW System needs to develop an approval process that maintains campus control over data but can also be responsive to needs for cross-institutional data access.

Background

Requests for data that span institutions, or that represent a System-wide dataset, should be routed to UW System Administration (UWSA) for review. UWSA will work with the EDGC to establish a register of pre-approved use cases for systemwide datasets, and UWSA will review requests against that register. If a request cannot be satisfied by a pre-approved use case, the EDGC will determine if it represents a new use case, should be amended, or should be approved as an isolated case.

In support of this process, the Enterprise Data Governance Council (EDGC) will document existing institutional data governance processes and develop supporting documents to support those decision-making processes.

A more detailed procedure is defined in Appendix 1.

Who Developed the Recommendation?

This recommendation was developed jointly by:

  • Tom Jordan, UW-Madison’s Ancillary Systems Program
  • Stacy Scholtka, UW System’s Enterprise Analytics Program

Who Was Consulted in the Development of the Recommendation?

The following stakeholders were consulted about the proposed POC:

  • Members of UW-Madison’s API development teams and UW System’s Enterprise Analytics program reviewed and contributed to the principles identified in Appendix 1
  • Additionally, ATP functional and integration teams consulted on issues related to data access and approval for integrations.

Appendix 1: Recommended Procedure for Data Approval for APIs and Data Lake Assets

Principles

  • Campuses retain the ability to make decisions about their own data, through their data stewards, even when that data resides in enterprise-wide information systems.
  • Access to data assets should be based on a legitimate university interest, and should involve consideration of risk, impact, and business need.
  • The EDGC will determine appropriate uses of enterprise-wide data sets or integration services, including institutional APIs that provide access to data for all campuses.
  • UWSA will manage the request and approval process, including evaluating requests against a set of pre-approved use cases. UWSA will not judge the merit of a request beyond its technical feasibility.
  • EDGC will consider new use cases for system-wide datasets and services as the need arises.

EDGC Decision: ATP Conversion POC – Data ingestion from Oracle HRS/SFS to AWS S3

Posted on

ATP Conversion POC – Data ingestion from Oracle HRS/SFS to AWS S3

EDGC Decision Date: July 16, 2023

Decision: ATP Conversion POC – Data ingestion from Oracle HRS/SFS to AWS S3

Decision

This ATP conversion request is for actual data from our current HRS and SFS system (including PII data like full SSN, bank accounts, etc.) to be moved from the source system to Amazon S3, then to Workday for the conversion. The data will be converted into Workday and will follow the security policies of the ATP Workday team. Once the data is in Workday, the data will be secured using role-based security that is being designed by the ATP Functional teams. The data loaded to stage tables in AWS S3 is not going to persist past the go-live, all security is then passed to the Workday teams.

Background

The success of ATP Conversion depends, in part, on quickly and safely ingesting data from Oracle Exadata sources (including HRS and SFS), transforming that data to meet business requirements for Workday and ultimately loading the data to Workday via excel files.

The ATP Conversion Team has identified roughly 220 source tables needed to create the Workday files and present to our implementation partner to load to Workday. Some of these data sources contain highly restricted data such as social security numbers and bank accounts. This data will ultimately reside in the Workday cloud environment.

The team has been using a combination of Exadata, SQL, IICS and Python to build out the tenants for the project to date. The team requested permission to use AWS and AWS tools to ingest the data from SFS and HRS to an S3 raw layer.

The Conversion Team will utilize the following serverless services within AWS – S3, Glue, Athena, KMS (for encryption), IAM (for permissions) and Cloudwatch Logs (for logging). For ingestion, the team will use on-prem servers running hadoop/spark which won’t need any firewalls to be opened.

The goal for this POC is to evaluate the efficiency of using AWS. As we approach the go-live date, it is critical to continue to shrink the timelines for pulling and transforming the data to limit disruption to daily operations.

The team has anticipated this transition for 6 months and have been developing current code in a manner that will require little rework to test the POC. The team has been working with the DoIT Cloud Team to stand up the environment for ingestion. The team has met with Cyber Security, completed the assessment, and taking all necessary mitigation measures as it relates to this data.

This POC request is extremely limited to a small team of ATP Conversion developers and a key subset of HRS & SFS data. The team has tested the process of pulling public data to an S3 bucket in the AWS environment and the final step is to connect to Exadata to pull true data. The team has an expert AWS Engineer on the team who has been working to set up the environment and will manage the ingestion POC.

Who Developed the Recommendation?

  • Michelle Weber, ATP Conversion Strategy Lead
  • Brian Zehren, Associate Director, ERP App Support
  • Shiva Prakash, Conversion Cloud Engineer
  • Mike Vavrus, DoIT Cloud Engineer

Who Was Consulted in the Development of the Recommendation?

The following stakeholders were consulted about the proposed POC:

  • Pam Snyder, Cloud Security Risk Analyst
  • Steve Tanner, Cloud & Security Eng Associate Director
  • Steffanie Johnson, Info Security Analyst IV
  • Kristy Rogers, ATP IT Security Lead and HRS Security Lead
  • Al Kantor, Cloud Data Architect

 

EDGC Decision: Data classification of enterprise data according to risk. April 23, 2023

Posted on

Data classification of enterprise data according to risk

EDGC Decision Date: April 24, 2023

Decision: Data classification of enterprise data according to risk pdf

Background

The success of ATP/EAP/ASP projects depends, in part, on classifying enterprise data elements across enterprise systems in a standard way.

UW System Administrative Policy 1031 calls for data to be categorized as high, moderate, or low risk. It provides standards for classification and minimum protections for each level of risk. Data classification “determines the extent to which technical, administrative, and physical controls should be applied to protect the data from theft, alteration, loss of integrity, and/or misuse.” SYS 1031 is currently under revision.

UW-Madison employs a classification system with four categories: public, internal, sensitive, and restricted (per UW Madison IT policy UW-504) spanning the spectrum of low to high risk. Many developers working with enterprise data across the ATP/EAP/ASP portfolio are from UW-Madison and are accustomed to UW-Madison’s classification system. Data in UW-Madison’s ancillary systems use UW-Madison’s classification system.

Lack of agreement on a single risk classification may result in developers applying different classifications in Workday vs. the data lake vs. ancillary systems. This reduces the opportunity to apply a common set of security roles across enterprise systems, and where possible, ancillary systems. And it could lead to inconsistent access and security of enterprise data.

Decision

APT/EAP/ASP apply the draft data classification schema (below) that brings together existing Madison and UW System policy in anticipation of the pending revision, noting that this MAY change by the time the policy revision is fully vetted.

Draft Data Classification Schema

Public (Low Risk) Sensitive (Moderate Risk) Restricted (High Risk)
Data is classified as Public when the unauthorized disclosure, alteration or destruction of that data would result in little or no risk to the University and its affiliates. Public data requires no confidentiality, integrity, or security protections.

Examples: Data approved for display on websites and/or made available to the public.

 

 Data is classified as Sensitive when the unauthorized disclosure, alteration or destruction of that data could result in a moderate level of risk to the university or its affiliates. A reasonable level of security safeguards must be applied to sensitive data.

Examples: By default, all institutional data that is not explicitly classified as Public or Restricted must be treated as Sensitive data.

 

 Data is classified as Restricted when the unauthorized disclosure, alteration or destruction of that data could cause a high level of risk to the university or its affiliates. Strong security controls must be applied to restricted data and access will frequently be limited to a small number of individuals.

 Examples: Information protected by state or federal privacy regulations (e.g., FERPA, HIPAA), or by standard confidentiality agreements.
Sub-category: Highly Restricted
Examples include data that may pose a threat to health and safety (e.g., biotoxins), Controlled Unclassified Information (CUI), export-controlled research information (e.g., ITAR and EAR), or research data associated with some Department of Defense contracts.

Who Developed the Recommendation?

  • Joe Johnson, UWSA Director of Governance, Risk, and Compliance
  • Lisa Johnston, UW-Madison Director of Data Governance

Who Was Consulted in the Development of the Recommendation?

The following stakeholders were consulted about the proposed data classifications, in the context of the forthcoming revision of SYS 1031. These stakeholders have supported the general direction being proposed and have not raised any initial concerns. However, the proposed data classification may change during the SYS 1031 revision over the coming months.

  • Ed Murphy (UW System, AVP Information Security)
  • Jim Treu (UW System, Director of Security Awareness and Outreach)
  • Mike Bubolz (UW Breen Bay, Interim CIO)
  • Patti Havlicek (UW-Madison, RMC Asst. Director)
  • Other various Technology and Information Security Council (TISC) representatives
  • UW Madison Data Stewards
  • UW Madison IT Policy Advisory Team (subcommittee of Information Technology Council)

Request for Proposals: Instructure Canvas Pilot II

Posted on

In 2013, the University of Wisconsin System conducted an Instructure Canvas pilot project, as recommended by the 2011 Learning Management System (LMS) Task Force, sponsored by the Learn@UW Executive Committee. The pilot was intended to enhance our understanding of the changing LMS landscape. The 2011 pilot provided us with an opportunity to experiment with and explore the features and functionalities of an alternative learning management system. The pilot also focused on ways to use the LMS to improve student engagement, as well as gauge the adoption effort of instructors and students when using a new LMS. The pilot was not intended to seek an LMS to replace Desire2Learn (D2L).

By initiating this RFP for “Instructure Canvas Pilot II,” UWS intends to further explore the Canvas platform and leverage the Canvas Pilot being carried out as part of the Unizin project by UW-Madison. While the objectives of the UW-Madison Canvas pilot are integral to vetting use as part of the Unizin initiative, the objective of the UWS Canvas II pilot is to provide all UW System campuses with the opportunity to further explore the Canvas product. Carrying out Canvas Pilot II also falls squarely in line with other initiatives, as it was one of the recommendations of the LMS Task Force 2011, and will also provide information (along with the LEARN@UW Roadmap) to support the LMS RFP which will be also initiated in the near future.

Canvas Pilot II is not being conducted to seek an LMS to replace Desire2Learn (D2L). The objective of Canvas Pilot II is to explore and learn more about the technical “back end” of the product with particular focus on the integration, interoperability, and ease of content export/import with UWS supported third-party systems (e.g., ePortfolio, Kaltura, Turnitin, Respondus Suite, and others), as well as Canvas’s ability to meet discipline/course specific needs for teaching and learning.

We invite interested campuses to select faculty and teaching staff to participate in the Canvas Pilot II project. Each instructor will design a course using Canvas to be delivered during one of the following semesters: Spring, Summer, or Fall 2015 (deadlines are shown in the “Application section below). For those interested in delivering Spring 2015 courses, please note that the timeline is quite aggressive.

Deadlines:

  • Spring 2015 Semester – October 31, 2014  (closed)
  • Summer 2015 and Fall 2015 Semesters – December 1, 2014 Date extended to January 16, 2015

For more information, please refer to the Instructure Canvas Pilot II RFP:
InstructureCanvasPilotII-RFP2 docx November 25, 2014 47.5 KiB

Status Update – April 27, 2014

Posted on

Progress continues with the implementation of the Kaltura Media Management System and we’re sharing the following highlights of recent developments:

  • Some campuses have provided access to select D2L users/groups. Please contact your campus Kaltura Administrator about availability or information concerning deployment plans.
  • Kaltura Administrators received training from the vendor concerning the MediaSpace™ component. MediaSpace™ provides a customized video portal that may offer both public and private access to media content. The project team received approval to proceed with testing the integration with the UW enterprise authentication service, Wisconsin Federation, and work with the vendor continues. This will enable UW users to supply their campus credentials (e.g., NetID) to access MediaSpace™.
  • The exploration and pursuit of integrating Kaltura with other systems is underway. Specific areas of interest involve other LMS (e.g., Moodle), hosting content capture in the classroom (Camtasia), and transcription and captioning services (e.g., 3PlayMedia and Automated Sync Technologies).
  • A knowledgebase was created to provide service specific documentation and other support resources to the user community. This site is available at https://kb.wisc.edu/kaltura. Additional resources will be added in the coming weeks.

We look forward to presenting an update at the UW System Spring ’14 Information Technology Management Council (ITMC) Joint Meeting on Monday, April 28, 2014. There is significant “buzz” across the UW institutions and we’re excited to share news about the progress. We hope to see you there.

Peter and Lorna

Status Update – January 21, 2014

Posted on

We are on track with implementing the Kaltura Media Management System and provide the following information about recent developments.

  • The campus D2L Site Administrators and Kaltura Administrators are actively engaged with integration their D2L site with Kaltura. The deployment of the service may vary, so please contact your designated Kaltura Administrator for additional information.
  • Nearly 21K media entries have been migrated from the shared Kaltura instance (used during the pilot phase) to the appropriate campus instance. An additional process will ensue later this week to migrate any content that was uploaded during the Winter interim session. Please note that the ability to upload content into the shared instance was disabled at ~5:30 p.m. on Friday, January 17. Previous pilot participants are strongly encouraged to start using the new Kaltura instance set up for your campus as soon as feasible.

We’re excited about the start of the spring ’14 term and the opportunity to provide the Kaltura service through deep integration with D2L. We will begin to turn attention to the 2nd phase of the implementation, which involves the deployment of campus MediaSpace sites and other integrations.

Stay tuned as additional updates will follow in the next two weeks.

Peter and Lorna

Status update – January 1, 2014

Posted on

We continue to make good progress on a number of fronts regarding the Kaltura implementation project. The following provides an overview of recent developments.

  • The vendor (Kaltura) created the necessary environments that are used for integrating the media management platform with Learn@UW/D2L in late December.
  • Documentation providing the instructions for integrating the aforementioned systems was developed and shared with the campus Kaltura Administrators (KAs) on 12/30/13. The designated contacts are strongly encouraged to work with their local D2L Site Administrator to configure their campus Learn@UW/D2L test instance to become familiar with the deployment process.
  • The vendor is actively developing the scripts needed to perform the initial batch migration of the content hosted in the UWS pilot instance. Quality assurance testing is scheduled to occur later this week and the batch migration process is expected to begin shortly thereafter. The final phase of the migration plan will involve migrating the content that will be uploaded during the Winter interim session.

The following dates pertain to the continuity of service during the Winter interim session. The goal is to limit the impact of the transition on the existing user community.

Monday, December 30, 2013 – Friday, January 17, 2014
Existing users of the UWS pilot Kaltura instance will continue to have access to their content and the ability to upload new assets.

Friday, January 17, 2014 (end of work day)
Access for adding new content to the UWS pilot instance will be suspended at the end of the day on Friday, January 17, 2014. Those needing this function may have the ability to access the campus Kaltura instance, which is dependent upon the local deployment plan.

Friday, May 30, 2014 (end of work day)
The ability to view content hosted on the UWS pilot instance will conclude and users will have been fully transitioned to the specific campus production Kaltura instance. References to media content hosted on the former will need to be modified due to the transition and users will be able to take full advantage of the new features with the integration.

We will continue to provide updates as important developments occur. It is our intent to begin conversations about deploying other aspects of the Kaltura system, specifically the campus MediaSpace™ video portal (see vendor product description) and integrations with other LMSes, in early spring.

The New Year will bring exciting new opportunities with respect to the use of a common media management platform throughout the UW teaching and learning community. We always welcome feedback and suggestions.

Kind regards,
Peter Mann

Status update – December 13, 2013

Posted on

Good progress is being made and this update offers additional details concerning the implementation project.

  • Training on the Kaltura Management Console (KMC) and integration with Learn@UW/D2L will be provided on Monday, December 16 (2 – 4 p.m.). The campus Kaltura Administrators (KA) will receive additional information, including the details for connecting to the web conference. The campus D2L Site Administrators are invited to attend as the Kaltura experts will provide a walkthrough of the actions needed to configure the integration.
  • A test Learn@UW/D2L instance is integrated with Kaltura and quality assurance testing is taking place. We will provide the campus KAs with access to the example course.
  • The existing pilot Kaltura instance will be available to instructors who plan to conduct courses during the upcoming Winter interim session. The service will be available to existing users, who will have the ability to upload and view content, through mid-January. Content hosted on the pilot instance will continue to be available through May 2014.

We’ll continue to post updates as the developments occur.

Peter Mann

Kick-off meeting generated much excitement

Posted on

A kick-off meeting for the Kaltura implementation project was held during the late afternoon on Tuesday, December 3rd. In attendance were the designated campus Kaltura Administrators, some of which served in the role during the pilot program.

The gathering was an opportunity to share information about the endeavor — goals and key milestones, transition of content contributed during the pilot, ideas regarding service guidelines (usage, policies, etc.), and established communication channels. The conversation was punctuated by thoughtful questions and input from the participants.

We are excited to embark on this journey and appreciate the involvement of the campus designees. They play a vital role with ensuring a successful roll-out and communicating updates regarding the progress to their campus stakeholders.

Stay tuned as more developments will continue to occur.

Sincerely,
Peter Mann

Kaltura Implementation Planning

Posted on

This website is intended to provide updates and highlights regarding the progress of the Kaltura Media Management System implementation at UWS for all interested parties. This site may change in format as more information and resources become available during the course of the implementation.  Please contact: Peter Mann (DoIT) or Lorna Wong (UWSA) if you have specific questions not addressed in this site.

Background:

The UW System has a three-year contract with Kaltura for a media management system, effective as of November 2014. This outcome was a result of an RFP process, initiated by the Learn@UW Executive Committee, to select a viable solution to meet the needs of the UW teaching and learning community. Prior to the RFP, UWS has engaged in a limited Kaltura pilot for the past two years, expertise in the system has developed on various participating campuses, we are expecting a successful launch of the system.

An implementation plan is being developed. DoIT’s Networked Media Services will provide the service management and serve as the central contact with the vendor and the designated campus contacts. Peter Mann(DoIT) will assume the role of implementation manager.  The initial target is to provide access to the system via a deep integration with the LMS (Learn@UW/D2L) by the spring ’14 semester. Additional phases of the deployment will follow soon to fully utilize the functionality and versatility of the system. Input from the designated campus Kaltura administrators will help define the deployment to best suit the various instructional needs of the campuses.

High Level Implementation Timeline:

 Phase 1: Provide access to faculty and students in D2L for Spring 2014 semester

November 2013 – January 2014

  • Identify campus Kaltura administrators – input from campus CIOs is being sought.
  • Coordinate with the vendor on system configurations and set up
  • Coordinate with the vendor on migration of existing pilot content
  • Coordinate testing integration with D2L V10.1 LE platform
  • Provide training and consultation on rollout plan for campus Kaltura admins
  • Provide test environment for campuses
  • Provide training and documentation resources to campus users
  • Develop usage and retention policy to guide the initial rollout

Phase 2: Provide non-D2L access to faculty and students

February 2014 – May 2014

  • Investigate and implement Kaltura access to Moodle users as requested
  • Implement access to Kaltura Media Space via Federated authentication
  • Coordinate training on Kaltura platform in D2L as needed
  • Coordinate training on Kaltura Media Space

Phase 3: Assess the other specific instructional needs to use the platform

Spring 2014 semester and beyond

  • Consultation with stakeholders with specific needs and campus Kaltura admins to address the viability and support of using the platform
  • Explore other extensibility to the platform to meet the needs of users
  • Review and adjust usage and retention policy to meet the needs of users

The campus kaltura-pilot-coordinators during the pilot project will serve as valuable resources as we transition from the pilot to production phase. We expect many will continue to be actively engaged in supporting the system.

Lorna Wong