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
- 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.
- Address SITS database issues that occur on large tables so that EUCLID downtime is prevented.
Out of scope
- Migration of Online Registration data to MCI as this has already been completed (see below).
- 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).
