Over the last year or so as the vision of the international eFramework as started to take shape I’ve been hearing more and more about SUMs (service usage models). I went along to the SUMs workshop to see if I could find out exactly what a SUM is.

The event was run by the international eFramework so we had the benefit of having Dan Rehak (consultant to the eFramework), Phil Nichols (one of the eFramework editors) and Lyle Winton (of DEST who has been involved in creating SUMs) facilitating the workshop. This was particularly useful (for me anyway) as it helped to distinguish the aims of the international eFramework from those of the partners involved. The partners in the international eFramework have common goals of interoperability and the use of service orientated approaches, but each country has their own priorities and interpretations of the framework. The eFramework does not mandate any one approach, it should be seen as a reference point for developers where proven technical interoperable scenarios are documented using a set of standard (hotly debated – for example ‘reference model’ has been blacklisted) terms. (Copies of Dan and Lyle’s presentations are available from the e-Framework website)

Although the aim of the day was to actually create some SUMs, we started with an overview from Dan Rehak on the eFramework and SUMs. Services provide the technical infrastructure to make things work – they describe interfaces between applications. A SUM is the description of the combination of services, which meet a specific requirement (or business need). So in some respects a SUM is analogous to a blueprint as it (should) describe the overall ‘business story’ (i.e. what it is supposed to do), with a technical description of the process(es) involved e.g. the services used, the bindings for service expressions and then examples of service implementations. Ideally a SUM should be developed by a community (e.g. JISC or a subset of JISC funded projects working in a specific domain area). That way it is hoped the best of top down (in terms of describing high level business need) and bottom up (in terms of having real instances of deployment) can be combined. I can see a role for JISC CETIS SIGs in helping to coordinate our communities in the development of SUMs.

At this point no official modelling language has been adopted for the description of SUMs. To an extent this will probably evolve naturally as communities begin to develop SUMs and submit them to the framework. Once a SUM has been developed it can be proposed to the eFramework SUM registry and hopefully it will be picked up, reused and/or extended by the wider eFramework community.

Some key points came out of a general discussion after Dan’s presentation:
*SUMs can be general or specific – but have to be one or the other.
*SUMs can be described in terms of other SUMs (particularly in the cases of established services such as open id and shibboleth).
*SUMs can be made up of overlapping or existing SUMs
*Hopefully some core SUMS will emerge which will describe widespread common reusable behaviours.

So what are the considerations for creating a SUM? Well there are three key areas – the description, the functionality and the structure. The description should provide a non-technical, narrative or executive summary of what the SUM does, what problem it solves and its intended function. The functionality should outline the individual functions provided within the SUM – but with no implementation details. The structure should give the technical view of the SUM as a whole, illustrate how the functions are integrated e.g. services, data sources, coordination of services. It can also have a diagrammatic illustration of any coordination. There are a number of SUMs available from the eFramework website as well as more detailed information on actually developing SUMs.

The main part of the workshop was devoted to group working where we actually tried to develop a SUM from a provided scenario. Unsurprisingly each group came up with very different pseudo SUMs. As we worked through the process the need for really clear and concise descriptions and clear boundaries on the number of services you really need became glaringly obvious. Also, although this type of business process may be of use for certain parts of our community, I’m not sure if it would be of use for all. It was agreed that there is a need for best practice guides to help contextualise the development and use of SUMs for different domains/communities. However that is a bit of a chicken and egg situation at the moment.

One very salient point was made by Howard Noble (University of Oxford) when he pointed out that maybe what we should be documenting are ‘anti-sums’ i.e. the things that we do now and the reasons why we take non soa approaches in certain circumstances. Hopefully as each community within the eFramework starts to build SUMs the potential benefits of collecting, documenting and sharing ways for people, systems and services to interoperate will outweigh other approaches. But what is needed most of all (imho) are more real SUMs so that that developers can really start to see the usefulness of the eFramework SUMs approach.