Your Insitution’s Data Mobility

In our work on the SLE we have met range of challenges, some expected and some unexpected but none as surprising to me as the problem of data mobility. Coming from a world of open repositories data mobility was the goal, the aim is to give away the content, give away the metadata about the content and, more recently, give away the paradata around the content. To me data mobility was so seemless I couldn’t foresee a situation where access to data would be a problem.

The world of corporate IT is in stark contrast to this. Data is stored in “off the shelf” proprietary systems designed for an environment where data may be sensitive or of great financial value. These systems are often not bought with data sharing considerations in mind or worse, built to make sharing data deliberately difficult to lock you into their other products which work together.

At the University administration level where the idea of data mobility seems to be a subject of great confusion. It seems the university has no formal policies about the use of data even between it’s own systems. The system which collects the data becomes a master source for that data. The administrator of that system decides if and how that data can be used. There is some sense that at some point all data finds a home in banner campus manager (which I recommend no one ever buy, build your own system it’ll be cheaper, faster and more flexible) but to then get access to this data the banner administration team need to decide if you are worthy of the data and build you a database view to access it. The combination of these problems result in glacially slow resolution to requests for data.

It is not all gloom and doom. Recent initiatives such as Chris Gutteridge’s http://data.southampton.ac.uk, the SLE and Student Dashboard have all been run in an agile way expecting far quicker service to data. This highlights some of the problems of the current system. The next stage is for the university to draw up some data policies. These policies should outline what data we are allowed to store, who can be given access to it and under what circumstances. Once the policies are set we can start looking at technical solutions which give role-based APIs to our data. This would mean a member of the public could make request to the API and be shown public data, student can make a request to the API and be shown data accessible to students and a SLE system administrator can make request  and be given data which the SLE is allowed to access.

If you are wondering how good your institution’s data mobility is ask yourself, “How would I go about getting a list of every student and which modules they taking?” The answer may be that you can not, you should probably only be able to get a subset of information about a student and perhaps not even their name will be in that subset but I would hope to at least get a list of computer usernames and module codes. Would you receive this list in a time scale which allowed you to complete a project on time? The real question is does your institution have framework for answering this question which can at least produce consistent and repeatable results with respect to what data you can access, how you get access to it and how quickly you can be given access? At the University of Southampton we can not answer this question consistently. The answers will depend on who you ask and what you ask for and the access method may be different too but at least we are aspiring to change. We know we need better data policy to facilitate better data mobility. Like so many great empires the institution dreams of benevolence.