Posts Tagged ‘SOA’

Moving Forward

Posted on October 26th, 2010 by Alex Bilbie

Over the past week we’ve worked tirelessly to perfect our timetable import code and we’ve now got a system that is working with real data. A select few students have now been given access to iCal feeds for both their timetables and their Blackboard assignments and the Library is hoping to have their Talis Keystone system in place very soon meaning we can start producing feeds of people’s book return dates.

Our next big job is to move away from bulk imports of data and instead start developing code that will go through and validate and verify events. So this could be looking for changes in the time of events or verifying that the right students are seeing the right events (in the event of a student changing course for example). With these changes logged we can then tackle one of the top requests that students have of the University and that is to be better informed of changes to their timetables.

The main timetables are produced by the Registry department however they aren’t informed if a lecturer is ill on a particular day, and in any case timetables aren’t updated currently until the following morning, so we’re planning on developing a tool for faculty offices to use so that they can make individual amendments to timetables when rooms need changing or lectures have been cancelled so that students can be informed sooner.

The logging of these changes will be important for Blackboard too. Certain schools and faculties like the idea of personalised assignment calendars however their own internal policies don’t allow staff to set deadlines inside Blackboard because deadlines may be changed by lecturers and senior staff aren’t informed. This is why the Computing School for example release a huge Excel spreadsheet of deadlines because it means only two people have access to change deadlines. We don’t want to be in a situation where we have to create individual departments their own tools to manage assignment deadlines, we’d prefer everyone used Blackboard and so with the ability to log changes to events what we could do is delay the update of the deadline in the student calendars for 24 or 48 hours giving senior staff a period in which to change it back to the original date or leave it (i.e. approve the change).

Our plan over the next few weeks is to perfect our API for querying events, give more students access to the their iCal feeds and also start developing the front end calendar application.

Integrated Service Development

Posted on August 5th, 2010 by Tim Simmonds

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.