Two servers, one for live use and one for testing, have been installed in our data centre and are being remotely configured by Worktribe. Worktribe provide the virtual server to us as an OVA file that is then installed and hosted in our existing virtual server environment. Almost all of the support and maintenance will be done by Worktribe remotely, which is a different approach to most of our systems though should be straightforward. Active Directory integration, which will allow users to log on to APMS using their standard University username and password, is also being configured.
We are starting to see parts of the system coming together now, and have been able to do some end-to-end testing of selected processes.
The vast majority of fields and workflows for creating short courses, standalone credit and ‘normal’ programmes have been created. This is where testing has been focussed. Worktribe still have a little more to do with preventing changes to programmes once they have been validated, but it is encouraging to see some significant progress and to be able to run through from proposing a programme to getting it validated.
Here’s a sneak preview of what you currently see when first proposing a new programme. (There may, of course, be some change by the time the system goes live.)
The project team are all very pleased that another instance of the system has been set up to be used specifically for populating our existing programme and module data. The population exercise has begun, which in itself is a major undertaking, and towards the end of the project the data will be moved across to what will be the live system. Starting population with real information at this point brings an added benefit that bugs are identified early, along with any suggestions for tweaks.
In addition to the programme proposal and validation work mentioned earlier, Worktribe have also put in place the mechanism to ‘roll over’ programmes from one academic year to the next. This is needed so that Agresso Students can be populated with instances of programmes for each academic year, and will also form the basis of how modifications are made to programmes.
After a few discussions between ICT’s server specialists and Worktribe, an appropriate way of backing up the system has been agreed. Although we hope that the worst will never happen, it’s essential we have backups in case of a major failure that means we lose the server or its data. The APMS server will be backed up to another server via a share, and from there backed up to an off-site facility. The backup routines will run every day, with Monday to Thursday backups kept for a week and Friday backups kept for a month.
ICT’s Application Support Team attended a training course about DTC (Data Translation Centre) – a tool in Agresso Students used to import information to the system in a support manner. This will be the way that programme and module information is imported from APMS to Agresso Students, and our Application Support Team are now able to configure and support the technical implementation.
The main areas Worktribe is now tackling are
- how the marketing information about programmes is stored in the system and made available to be published on the Univerity’s website
- how the system will handle programme modifications
- how deletions/suspensions of programmes will be managed and the information archived
- how records will be ‘locked down’ once validated but certain fields are still made available for editing.
I have started thinking about how to get information about the system out to a wider audience when we get nearer its launch. A lot of people, especially academics, will need to know about and use it so it is important to strart thinking about how to get the message out. To that end I have started talking to the Internal Comms team, and we have started work on a simple communication strategy.
In order to allow Worktribe more time to concentrate on core functionality at the moment, access to the API will come later but will still definitely be made available as part of the project. We’ve seen the first XCRI-CAP outputs from the system which Jamie has had a look and provided feedback to Worktribe. At this stage the XML is produced by manually selecting a programme and choosing an option to export the XML file, but later will be available via a URL. Worktribe is making some refinements, with the aid of the XCRI-CAP validator, and we should see the next iteration soon.
“how the marketing information about programmes is stored in the system and made available to be published on the Univerity’s website”
XCRI is the answer. Don’t waste time creating a custom export or additional data spaghetti for a specific purpose, just have a comprehensive XCRI feed and tell Maketing to use that.
XCRI-CAP isn’t the full answer though – our marketing information contains more than XCRI-CAP encapsulates. There will be an XCRI-CAP feed, but we also need the additional information too.
Isn’t XCRI-CAP extensible though?
You’re right, it is (or at least should be). There was some talk about a year ago on how modules could be incorporated. It would make sense for there to be a standard, but apparently there isn’t. There seems to be a variety of ideas but I think that’s as far as it got.