Building Service Usage Models

Over the course of the project, the use case documents have been analysed from a services perspective. This work follows on from the earlier e-framework initiative, and seeks to provide an initial bridge between user workflows, and something that might ultimately be implementable by software developers. For those familiar with the e-framework initiative, these documents are a variant on the service usage model (sum), with more emphasis placed on the “above the line” parts (that is, context information – introducing problem statements).

These documents will be useful to technical architects, business analysts and software engineers. Each document contains similar contents; being initially a description of the problem, business analysis of current practice which addresses the problem, and then finally sections on the sorts of behaviour that software would need to exhibit in order to help solve the problem. Where possible, useful technical standards from the domain have been included.

The documents are not hard and fast rules on how an implementation should be built, but rather a starting point that would explain context to technical staff; likewise the early sections of the documents should be readable to domain experts also.

In preparing these documents, which were based on the original use cases, several observations have been made. At this stage it should be noted that these observations are made by an impartial observer – the author is a software engineer by training, and not a librarian.

First, the problems from the use cases seemed very similar in nature – information on <something> was difficult to find, not considered reliable, and/or might exist in many different places. Collation of this information was difficult and occupied a large amount of staff time. Secondly, these information issues were spread across many institutions, which contribute to a potential sector wide duplication of effort. Finally, even in a perfect world, the processes required to do what would be considered by laymen to be simple, e.g. “change my current paper journal subscription to be an electronic journal subscription” are (necessarily) much more complex that one would imagine.

The proposed solution to this, the “knowledge base plus” (KBP) appears essential given this context. Allowing staff to save time across many institutions will lead to massive savings, and one suspects, allow the staff to concentrate on helping students and academics.

From a services perspective, KBP is relatively straightforward to describe, although the difficult part – and the sum documents hint at this – still needs to be addressed; and that is the data models for the information that KBP will manage.

In conclusion, working with the use cases to create service usage models has been an interesting exercise, particularly where it has revealed real practice, and shone a light on the scale of the issues faced.

The Service Usage Model documents are now available.