At the beginning of this year, I started working for Jisc. My first months have been nice and busy, and full of mainly one challenge. SHERPA Ref.

Context

For those of you not in scholarly communications (Hi Mum), here’s a bit of background.

The Research Excellence Framework (REF) is a big deal in UK academia. It’s a sector-wide exercise to rank all Universities by the quality of their research outputs. How well an institution does in the REF will have a direct impact on the research funding it will receive through the next cycle. HEFCE (the UK government’s Higher Education quango) administer it and set the rules.

A word on Research Outputs: Without getting into a debate about the scope and nature of a Research Output, for the purposes of this post, we’ll be focusing on Journal Articles.

As far as I can tell, the product that a journal is selling is reputation. An academic that can get a Journal Article published in one of the top journals is respected by his peers, and more importantly, by research funders.

Journals make their money by selling subscriptions to university libraries, and the traditional model of scholarly communications is funded in this way. When a researcher gives a journal her article, the journal handles dissemination of the research. The business I have been in for the last ten years is about shaking this up by enabling academics to publish their work via the web so that it’s available for everyone, for free. It’s called Open Access. Publishers have a variety of views on this, and make those views formally known through Publisher Policies, which are legal wording defining what authors can and can’t do if they publish in their journal.

However, we can now add the British government to the growing list of entities that support Open Access to research. HEFCE has decreed that for a research output to be considered in the REF, it must be Open Access.

Understanding whether a particular Publisher’s Policy allows an author to make his article Open Access is actually quite difficult. The author would have to read through potentially pages of policy document to understand this. To assist, the SHERPA Ref service provides a simple answer as to whether a Publish Policy allows an author to make his article open access and how he can do that. We’ve had our crack admin team read the policies, we’ve stored them in a database, and we’re providing and interface that allows anyone to query by journal.

In at The Deep End

Just as you don’t want to know about the processes that go into making laws or sausages, you probably don’t want to know what’s going on behind the web services you use every day. A lot of what is shipped is not beautiful to behold. This is normal, and right up to the wire, managing a project can be duck-work — calm on the surface but paddling furiously below.

I inherited technical responsibility for SHERPA Ref quite late in its project lifecycle and it was my responsibility to work through the last remaining technical hurdles and get it release-ready.

The Challenge

The first piece of critical analysis was to identify which parts of the system were ready for launch and which weren’t. On the whole, the system was robust. There was a sophisticated administration and data entry infrastructure that was functional and appropriate, a database structure that was a little was inelegant but functional (as a developer, I’d love to live in a world where elegance was one of the bars all software had to clear) but there were still some issues with the front-end.

Results from our closed beta testing were generally positive, but there were criticisms that came back to the issues we identified with the front-end.

Problem Solving in Broad Strokes

Of course, some of these issues were bugs that beta-testing had shaken out, but some of the issues were structural. An early misunderstanding of the requirements by the development side of the project team had led to some subtle issues in the way decisions and recommendations were being made by the system. This was a critical issue that affected a low number of journals, so had not been caught earlier in the process.

So, there was a decision to make. Repair the existing front-end or build a new one. The front-end of the system was a fairly small (in terms of lines of code) component of the system and is essentially a view on the data that is curated by the larger components of the system, which made either option a viable one. In the end it was decided to rebuild due to the lack of current staff that had a detailed knowledge of the framework that was used to build the system.

Building a REST interface to access data stored in a database is the bread-and-butter of a Web Systems Developer, which is one of the hats I wear. The most complex part build was reading from the database and normalising to a more elegant structure. Once that was done, it didn’t take long to produce an equivalent system, and it was a simple matter to also push JSON data out over predictable URLs to create an API.

The Benefit of Automated Tests

As part of the new development, a comprehensive set of Unit and Integration tests were written. By far the most important of these were created in association with Jane Anders, the SHERPA Services Development Officer, and by far the most expert person I’ve ever met on the subject of publisher policies. Her job is to ensure that the data that powers SHERPA Services accurately reflects reality. Together we chose a set of representative publications and wrote down what the system should say about each of them. We ended up with 28 journals. We used these to test against the system, and quickly isolated the conditions under which the system did not perform as expected.

The biggest benefit of tests when dealing with software projects that they give provable confidence. There is now a process for determining that the software is correct at this point, and furthermore, we can recheck it at any point in the future.

The End of the Process

Sherpa Ref was launched yesterday in a small blitz of Jisc publicity. I ran the tests once more before launch time and kept my fingers crossed; I’m never fully convinced that my software works, and I think that’s a healthy attitude.

I learn best by doing, and while there was no Rocket Science in this project, it was an opportunity to stretch my legs with the technical management of a project while gaining understanding of the organisational context of my job. Throughout this process, I had the support of colleagues in other offices in Jisc. We were provided with infrastructure to run our test and live services on, development support from Rachel Witwicki in the Open Access Scholarly Comms Development Team.

All in all, this has been a good quarter, and I’m happily ensconced in my role, and I’m now looking at the next challenge: version 2 of SHERPA’s other Open Access Services…