Overview

Background

Objective 1

Due to its sensitive nature, there is a need to move the following defined list of “reportable characteristics,” data items to a new, more secured place (MCI) on the SITS database as the golden copy, so that EUCLID remains supported.

STU Field

Item

MCI Field

STU_UDF7

Care Leaver

MCI_CLVC

STU_UDFG

Carer

MCI_CARC

STU_COBC

Country of Birth

MCI_COBC

STU_DEPS

Dependent

MCI_DEPC

STU_UDF9

Estranged Student

MCI_ETRC

STU_ETHC

Ethnicity

MCI_ETHC

STU_GNID

Gender Identity

MCI_GNID

STU_NID1

National Identity 1

MCI_NID1

STU_NID2

National Identity 2

MCI_NID2

STU_NATC

Nationality 1

MCI_NATC

STU_NAT1

Nationality 2 (Dual Nationality)

MCI_NAT2

STU_NDEP

No. Dependents

MCI_NDEP

STU_RELB

Religious Belief

MCI_RLGC

STU_SXOR

Sexual Orientation

MCI_SXOC

STU_OCBC

Standard Occupational Background

MCI_SOBC

STU_SECL

Socioeconomic Class

MCI_SECC

SCJ_PARE

Parental Education

MCI_PEDC

 

MCI is also used as a data source for HESA Statutory Returns.

Some processes such as online registration have already been updated to store this data on MCI, but other processes (like admissions, reporting etc.) that are still reading data from the STU table need to be reviewed. Historic student data also needs to be migrated, including the GDPR review of data “not needed.”

Current students will have data written to MCI as they complete online registration, but if all of the “reads” are moved to look at MCI rather than STU it will mean that any student data not on MCI will drop from reports and retrieval screens etc. There is therefore need to agree whether this migration should be performed for all historic students or if there's a cut-off period and, if the latter, how historic data is reported on/retrieved. This is not likely to be required for historic data but a discussion with GaSP/Planning will follow.

A benefit of moving to MCI is that there will be no need to manage dual maintenance of storing/updating data on both Student and MCI tables. This will also allow the use of Tribal recommended processes. At an as-yet unconfirmed date, Tribal will stop supporting the use of STU (student) tables for the storage of reportable characteristic data. Not doing so will leave us open to potential reporting errors. This will also impact the current Admissions process and BI reporting. 

Objective 2

We also need to address the SITS database performance issues that occur on large tables so that EUCLID downtime is prevented as the increased number of users, processes and therefore data being stored on the SITS database is causing performance issues and impacting users (staff and students). This will involve identifying data for deletion. Previous analysis work done on the Assessment APT tool showed that low level components assessments could be deleted and the performance would be boosted by 30%.

This occurred recently with the Engagement tables growing at a rate of 2 million a year. New processes were also added during the Covid period to record students' LEARN logins as required for Immigration Tier 4 students and is still being used by CAHSS. This was implemented without a data retention policy and therefore, the creation of a new data retention policy is required.

Scope

  1. Move a defined list of data items from STU to more secured place (MCI) on the SITS database, categorised as ‘reportable characteristics,’ so that EUCLID remains supported.
  2. Address SITS database issues that occur on large tables so that EUCLID downtime is prevented.

Out of scope

  1. Migration of Online Registration data to MCI as this has already been completed (see below).
  2. Migration of data outside the agreed upon population.

Objectives and Deliverables

ID Description

Priority (MoSCoW)

Benefit(s) Success Criteria
O1 Move the student characteristics from STU table to MCI table Must Sensitive data will be more securely stored. We will also be aligned with Tribal support agreement/future version upgrades. Sensitive data stored in MCI tables
O1D1

Analyse the processes/integrations (WS02, EUGEX, EUGEX file generator) storing student details on STU tables

Must Will allow the update of the processes to move to MCI tables All processes/integrations identified and documented
O1D2

Analyse the BI reports using STU tables

Must Will allow for the update of the BI universes and reports All BI reports using STU tables identified and documented
O1D3 Opportunity for GDPR review of data not needed Should Opportunity to check whether we are adhering to GDPR GDPR review complete
O1D4 Analyse the staff access to MCI Should Will allow for the implementation of the improved access control to the sensitive data.  All staff access to MCI identified and documented
O1D5 Update the processes to move to MCI tables Must Will allow for the migration of the student characteristics from STU table to MCI table All processes to move to MCI tables documented
O1D6 Migrate data from STU to MCI Must Avoid for Data Futures Reporting errors Data migrated from STU to MCI. Any and all errors resolved
O1D7 Update the BI universes and reports, EUGEX and WS02 Must BI universes and reports will continue to function by referencing the MCI tables All BI universes and reports updated
O1D8 Implement the improved access control to the sensitive data.  Should Ensures sensitive data is securely accessed by the appropriate people Improved access control implemented and documented
O2 Address SITS database issues that occur on large tables Must

Prevent or mitigate downtime, improve performance and contribute towards being GDPR compliant

SITS database no longer suffers from performance issues caused by large data tables
O2D1

Review the SITS database to identify the large tables, review processes creating large data volume.  Analyse the access/permissions.

 

The following have already been identified as causing issues:

 

Engagement/Learn logins added during Covid (not used by Immigration any longer, but by CAHSS) ,

Men_doc (5 TB size of db) has  compliance data (see dependency from SAC097)

Work done last year: low level assessments components: not compliance but would improve performance by 30% during peak period

 

All this work can be completed iteratively
Must Will allow the build, test and implementation of the deletion process Large tables and processes creating large data volume identified and documented
O2D2 Prioritise actions: how we address the size of the tables/data retention policy required Should Will allow the build, test and implementation of the deletion process Actions identified, documented and prioritised
O2D3 Engage with stakeholders to agree data retention policy/process. Establish whether a DPIA is required Must Will allow the build, test and implementation of the deletion process Data retention policy agreed and signed off. DPIA complete if required
O2D4 Measure performance expected: take baselines, then review Should Will allow successful tracking/review of the build, test and implementation of the deletion process Baselines established and documented
O2D5 Build, test and implement the deletion process as per agreed retention policy, ensuring batches feasible to run in live Must Will remove large amounts of data and therefore reduce the risk of system downtime Deletion process implemented in LIVE environment
O2D6

Delete Course Block Occurrences for previous years.

Should Will remove large amounts of data and therefore reduce the risk of system downtime Course Block Occurrences for previous years deleted
O2D8 Handover the deletion process to student systems so that they are run as BAU Must Will allow for the resolution of SITS database performance issues that occur on large tables Deletion process formally handed over to student systems. No errors identified
O3 Additional Technical Legacy Work Should Enhanced data security of key student systems applications is completed Remaining Vue Upgrade / Update of Components under Continuous Service Improvement (CSI) are complete

Project Milestones

The following milestones take into account the increased budget and duration of the project.

There are four strands of work in Objective 1:

  • Student characteristic data migration. There is a hard deadline of 28 June 2024 for this work as it must be completed prior to the HESA Returns in July.

The following three strands need to be tested, trained and deployed to LIVE concurrently:

  • EUCLID Reads moving from STU to MCI tables
  • EUGEX Reads moving from STU to MCI tables
  • BI Universes moving from STU to MCI tables

The work required for Objective 2; the agreement of the data deletion policy as well as the deletions themselves, has resulted in the longer duration of the project.

The scope of this project has been increased to include:

3. Remaining Vue Upgrade / Update of Components under Continuous Service Improvement (CSI).

 

Stage Milestone Due Date Previous Date
Initiate Project Start Date (MAJOR MILESTONE) 01-Apr-2024 No date available
Analyse O1 Data population to be migrated to MCI tables identified and analysed 10-May-2024 No date available
Build O1 Migrated data in MCI tables secured in development environment 24-May-2024 No date available
Plan Project Brief Completion (MAJOR MILESTONE) 31-May-2024 01-May-2024
Build O1 Migrated data in MCI tables secured in testing environment 14-Jun-2024 No date available
Build O1 Migrated data in MCI tables secured in training environment 21-Jun-2024 No date available
Deliver O1 Data migrated from STU to MCI tables in LIVE environment 28-Jun-2024 No date available
Deliver O1 Data migration Deployment Sign-off Review 28-Jun-2024 No date available
Build O1 EUGEX Reads integration moving from STU to MCI tables secured in development environment 28-Jun-2024 No date available
Build O1 EUCLID Reads moving from STU to MCI tables secured in development environment 28-Jun-2024 No date available
Build O1 BI universes and reports secured in development environment 12-Jul-2024 28-Jun-2024
Build O1 EUCLID Reads moving from STU to MCI tables secured in test environment 12-Jul-2024 No date available
Build O1 BI universes and reports secured in testing environment 16-Aug-2024 19-Jul-2024
Build O1 EUGEX Reads integration moving from STU to MCI tables secured in test environment 16-Aug-2024 02-Aug-2024
Build O1 EUGEX Reads integration moving from STU to MCI tables secured in TRN environment 16-Aug-2024 09-Aug-2024
Build O1 EUCLID Reads moving from STU to MCI tables secured in TRN environment 16-Aug-2024 19-Jul-2024
Deliver O1 EUCLID Reads moving from STU to MCI tables LIVE 20-Sep-2024 30-Aug-2024
Deliver O1 BI universes and reports updated 20-Sep-2024 30-Aug-2024
Deliver O1 EUGEX Reads integration moving from STU to MCI tables LIVE 20-Sep-2024 30-Aug-2024
Deliver O2 Large data tables that don’t require the Data Retention Policy deleted 27-Sep-2024 30-Aug-2024
Analyse O2 Data retention policy agreed with users 31-Oct-2024 04-Oct-2024
Build O2 Data retention policy built 31-Oct-2024 27-Sep-2024
Build O2 Data retention policy tested 29-Nov-2024 15-Nov-2024
Build O2 Data retention policy UAT signed off in TRN environment 14-Feb-2025 24-Jan-2025
Deliver O2 Large table data deletion processes deployed to LIVE environment (MAJOR MILESTONE) 28-Feb-2025 31-Jan-2025
Build O1 STU updates switched off 28-Feb-2025 31-Jan-2025
Deliver Delivery sign-off review 14-Mar-2025 No date available
Deliver O3 - Additional Technical Legacy work complete 21-Mar-2025 No date available
Close Project Closure (MAJOR MILESTONE) 28-Mar-2025 25-Apr-2025

 

Project Info

Project
Euclid Technical Legacy - Other
Code
SAC102
Programme
Student Systems Partnership SSP
Management Office
ISG PMO
Project Manager
Jack Ross
Project Sponsor
Lizzie Beattie
Current Stage
Close
Status
Closed
Project Classification
Run
Start Date
01-Apr-2024
Planning Date
31-May-2024
Delivery Date
28-Feb-2025
Close Date
31-Jul-2025
Overall Priority
Normal
Category
Compliance