The Revelation Student Records Enterprise Reference Model

This article presents an updated version of our Student Records Enterprise Reference Model, building on our earlier blog, A Higher Education Enterprise Reference Model for Student Records.

The updated model is intended as a working reference for architects and analysts operating around the Student Information System (SIS). It extends the original scope beyond core SIS integrations to provide a fuller UK higher education view spanning operational systems, statutory bodies, student support processes, examination operations, and academic governance.

You can explore the interactive model here: View the model in the Revelation EA tool.

What’s Changed in This Version

The original accelerator described 24 systems and 26 core SIS flows. The current reference model expands that scope to 33 systems and actors and 69 flows, turning the original integration-focused view into a broader enterprise reference for UK higher education architecture.

• Broader scope: the model now extends beyond core SIS integrations into analytics, research, digital services, statutory reporting, student support, examinations, and academic governance.
• New systems and actors: additions include Student Wellbeing & Disability, Exam Scheduling, Academic Integrity, Exam Board, External Examiner, and UK sector bodies such as UCAS, HESA, the Student Loans Company, and UK Visas & Immigration.
• Expanded flow coverage: the original model ended at F026. The updated model adds flows for analytics and warehousing, student evaluation, HR and payroll, research administration, content and service management, statutory returns, wellbeing and adjustments, examinations, board ratification, external examining, and academic misconduct.
• Clearer system-of-record boundaries: Student Records is now described explicitly as the authoritative student record and outcome system, while source systems such as Finance, Wellbeing, Research Proposals, and Academic Integrity retain ownership of their own business processes.
• UK-specific architecture: statutory and regulatory obligations are now modelled directly, rather than assumed, including HESA returns, SLC confirmations, UKVI sponsor-compliance data, and UCAS admissions exchange.
• Academic governance made explicit: the model now distinguishes between systems that process and present data and actors that make formal academic decisions, supported by Exam Board and External Examiner flows.

Model Overview

Student Records sits at the centre of the model as the institutional system of record for the student academic lifecycle. Around it are domain systems that originate or consume data: teaching and learning platforms, operational services, analytics tooling, research systems, digital workplace services, and external statutory bodies.

The updated model distinguishes three architectural roles:

• Source and operational systems, such as the VLE, Timetabling, Finance, Attendance Monitoring, Wellbeing, and Exam Scheduling.
• Core record systems, with Student Records consolidating the student’s authoritative institutional record and ratified academic outcomes.
• Governance actors, such as the Exam Board and External Examiner, who review and ratify outcomes rather than own operational processing.

For architects, the main value of the model is not simply the application inventory. It is the assignment of responsibility: which system originates data, which system owns the lasting institutional record, and which actors apply judgement or assurance before outcomes are confirmed.

Model Principles

This model has been developed around a set of governing principles that reflect common practice in UK higher education. Understanding these principles helps architects apply the model appropriately and identify where local deviation may be justified.

Student Records as system of record

The SIS is the institutional system of record for the student academic lifecycle. It holds the authoritative data about who is enrolled, what they are studying, how they are progressing, and what outcomes have been confirmed. All other systems that generate or affect student data are expected to pass the relevant outcome to Student Records.

Process ownership versus outcome ownership

Other systems manage their domain processes and pass the confirmed outcome to Student Records. Finance manages billing; the fee liability and hold status sit in the SIS. Wellbeing manages adjustment cases; the approved outcome sits in the SIS. The Exam Board ratifies results; the ratified decision is written to and locked in the SIS. This principle prevents data fragmentation and ensures a single, auditable record for each student.

SIS as distribution hub

Because the SIS holds the authoritative record, it is also responsible for distributing confirmed outcomes to downstream operational systems. Attendance Monitoring receives approved adjustment thresholds from SIS rather than directly from Wellbeing. The VLE receives adjustment delivery requirements from SIS. This pattern reduces integration complexity and prevents divergent states across systems.

Governance actors are not systems of record

The Exam Board and External Examiner are modelled as actors rather than systems. They receive data, apply judgement, and return decisions — but they do not own records. This distinction preserves the integrity of the student record and reflects the governance reality that formal academic decisions are made by people, not systems.

UK regulatory compliance as a first-class concern

Statutory and regulatory obligations are treated as core integration requirements. HESA data returns, Student Loans Company confirmations, UKVI sponsor compliance data, and UCAS admissions exchange are first-class flows in this model because in a UK HE context they carry legal and financial consequences and must be planned for from the outset of any SIS programme.

Local variation

This model represents a generalised UK higher education architecture. Individual institutions will vary from this pattern. Some operate more lateral data flows between systems, with less centralisation through the SIS. Some have fewer or more systems, or use product suites that consolidate multiple capabilities. Some have integration middleware that alters the physical routing of data. The model is a reference for mapping, gap analysis, and programme planning — not a normative prescription. Institutions should adapt it to reflect their specific systems, history, and governance practice.

Nature of information flows

Flows in this model are logical rather than technical. The physical implementation of any flow may be a real-time API integration, a scheduled batch extract, a portal-based self-service action, a manual process carried out by registry or administrative staff, or an electronic file transfer. The model does not prescribe integration technology; it establishes what data should flow between which systems and who owns each element of the student record.

Applying the Model Locally

The reference model is a starting point, not a deliverable. Its value is realised when institutions use it as a lens against their own landscape — comparing what is modelled here against what they actually have, identifying gaps, and scoping the work needed to close them.

A typical application follows a progression from orientation to execution:

Domain and system identification

Begin by mapping the reference model against your institution's actual application inventory. Identify which systems in the reference model you operate, which capabilities are served by different products, and where there are genuine gaps — domains present in the reference model but not yet covered locally. This gives you a scoped, institution-specific version of the model as a baseline.

Business analysis and requirements

For each domain or integration gap identified, use the flow descriptions in this reference as a starting point for business analysis. The flow type classifications — SOR intake, SIS distribution, outcome confirmation, statutory — help orient conversations about data ownership and process boundaries. Work with domain leads to confirm what data is exchanged, who owns it, and what business rules govern it in your local context.

Functional flows

Translate the logical flows in the reference model into institution-specific functional flows. These describe what happens in your processes, using your system names, your data structures, and your business rules. Functional flows are the bridge between the reference model and your detailed design — they confirm the scope of each integration and surface dependencies before implementation begins.

Detailed as-is and to-be modelling

Where significant change is planned — a SIS replacement, an integration remediation, or a new domain capability — develop detailed as-is and to-be models for the affected scope. This may include process models, data flow diagrams, and sequence diagrams that describe the precise message exchange, trigger conditions, error handling, and data transformation for each integration. Revelation supports this progression from logical reference model through to detailed design artefacts.

Transition roadmap and work packages

Use the scoped system inventory and detailed models to build a transition roadmap. Group related integrations and domain changes into work packages that can be sequenced, resourced, and governed independently. Statutory flows such as HESA, SLC, and UKVI typically carry fixed delivery deadlines and should be identified early. Core SIS integrations — VLE, Finance, IAM — are usually foundational and will unblock other work packages downstream. The reference model's flow groupings provide a natural starting point for work package boundaries.

The Enterprise Reference Model

Detailed Flow Reference

Each section below is intended as a practical architecture reference. The “Typical data exchanged” list is illustrative rather than exhaustive, but reflects the principal data classes implied by the model and its underlying process boundaries.