Enterprise Architecture

Examples of integration

There are several approaches that can be taken to integrate applications. We work with projects and services to choose a design that best fits each situation.

Presenting information to a user

When a student logs on to MyEd, the University portal, they will see the information that is relevant to them at that time. 

To make this work, MyEd contacts several administrative IT systems at the time the user logs on, pulling the data from them so that the student is given up-to-date information. 

Diagram showing the MyEd portal reading information from other systems

MyEd also presents notifications to students, alerting them that a new message has arrived or that there is a new task for them to do.

Notifications contain just enough information for someone to know the type of change that has occurred, together with a link to the actual message or task.

Implementing a task

An increasing number of administrative processes now involve more than one IT system.  When someone updates information in one system, other actions may be needed in other systems.

Diagram showing an update to the Student Record triggering actions in other systems

One example occurs when a new person submits an application to the University to study on a postgraduate course.  This application will be processed by the Student Record system, which will immediately tell the Identity Management system to create a new University login and the MyEd portal to create an account where the new applicant can see information about their application.

Another example occurs when a student changes their personal information in MyEd.  MyEd immediately contacts the Student Record system to update their information.

Larger data transfers

In the previous examples, the systems contact each other immediately, in response to someone logging into the portal or submitting an application.  Sometimes, this immediate response is not needed, or perhaps the IT system is too old to support it.

This approach suits data where changes are made infrequently and are not needed immediately.  Examples include the specifications of degree programmes, or information about buildings, or setting up a new research award.

Another example is when a system needs the end-of-day balance on certain budgets.  These can be transferred overnight, when they become available. 

One caveat to this approach is that if not all systems are updated at the same time, users may be presented with inconsistent information from different systems.  So some care is needed.

 

Ensuring consistent data

All three integration approaches require that we use consistent terminology to describe entities across different business areas and IT systems, or, when local areas have legitimately different meanings for the same term, that we can disambiguate when combining data at a University level. 

We also need to ensure that data is being used correctly and with appropriate authorisation.

To see further discussion of these issues, consult the University data section of this website.

University data