The university, in common with the wider HE sector, is looking at SOA (Service Oriented Architecture) as the way forward.

A major issue is that many of our existing systems exist as discrete silos of data and functionality, yet they are for the most part sufficient for the tasks they were originally acquired for.

A prime example would be our timetabling system. With it, our timetabling team are able to meet the university’s need for an academic timetable, with all that that entails. It is an established part of the university and is supported by process and procedures that have been honed and refined over the years. To replace it would be a major undertaking.

To qualify what I mean by “the university’s need for an academic timetable” is that we are able to generate a timetable that enables the university to allocate its resources in such a way that it is able to deliver its academic program. Any functionality beyond that (for example, publishing the timetable) has had to be provided by other means in common with most of our other systems. This usually entails some form of overnight batch processing.

One consequence of the way our systems currently interact is that when they are all “butted” together as they are, it takes several days of passing from one system to another, processing it and reprocessing it to reflect any changes in any circumstance or environment. Accordingly, we are far from real time and are unable to give a truly accurate view of the “whole picture” at any one time as there will always be some system with data that is lagging behind.

The above encapsulates what constitutes two of the main drivers in our move towards SOA: namely better management information and a near real time experience for our user.