Tony takes a look at the origins of the JISC IE, or more particularly its technical architecture, and asks a series of searching questions about its purpose and effectiveness. I think he does a good job of highlighting some of the difficulties inherent in trying to conceptualise an environment in which the supply of resources is necessarily distributed and the requirements of users are multifarious. He recognises that it was appreciated at an early stage that a ‘homogenous’ JISC IE was an impossibility. Tony also goes on to claim that:

…the IE as an architecture can never be complete, that it is only an abstract conceptual model.

[my emphasis]

I tend to agree that there is a risk that this abstract conceptual model be taken literally, and be used in what Tony terms a ‘prescriptive’ way. The use of the word ‘architecture’ in some JISC IE literature has, perhaps, not helped – Tony also makes the point that ‘architecture’ can be both prescriptive and descriptive. Turning to the diagram, I think that the inclusion of a named service instance (Athens) is interesting in that it highlights the tension between abstract model and architecture: the inclusion of Athens in the diagram in 2005 was entirely sensible – it was pretty much the only example of this type of component in use in the sector at the time (if the diagram were created tomorrow it might have the UK Access Management Federation here no doubt, for the same reasons). However, it does tend to push the impression of the diagram as a whole away from the abstract, towards the concrete.

So, on the face of it, I agree with Tony’s statement. However, I would point out that the conceptual model, symbolised by that now iconic diagram, has been remarkably effective in the way it has become the focal point for a great deal of debate, presentation of ideas, funding of R&D etc. over a number of years. It has proven itself to be remarkably versatile. For all the constraint which it has imposed, or been perceived to impose, it has nonetheless been a useful template allowing people to over-lay ideas, models, information flows and so on. It might be an interesting exercise to collect every available, published use of this diagram where some extra information or annotation has been super-imposed on the original ‘classic’ diagram – I believe I have seen dozens of examples of this usage.

While I think I understand what Tony means when he talks about the difficulties in describing an ‘essentially ephemeral concept’, I would argue that the JISC IE is anything but ephemeral. Firstly, the JISC IE is a long-running programme, comprising many projects. To get a flavour of the breadth and depth of this programme, take a look at the growing collection of outputs from the JISC IE funded projects which are being steadily added to the JISC Information Environment Repository. To an extent, the diagram has also served well as a simple organisational tool for funding. Many JISC IE ‘invitations to tender’ for project funding have carried this diagram, sometimes in annotated form, as a kind of map – giving bidders a top-level view of where their project might fit into the overall picture. In this sense, I think that something more than ‘consolation’ is being offered.

While I would argue that the JISC IE conceptual model has served us well for a number of years, it is true that it is starting to show its age. Events have overtaken it. In 2005, it was not at all clear how user-generated content, RESTful interfaces, the drive for open data would come to be such dominant features of the ways in which people consume, augment and create resources on the Web. The emphasis on portals in the ‘presentation layer’ is limiting, and in an emerging paradigm of the ‘mobile’ networking, more attention will need to be paid to the user and the devices they use to engage with distributed resources. But then again, it does show quite clearly a move towards a contemporary, distributed, service-oriented paradigm.

Turning to the reworked diagram which Tony offers at the end of his piece – I presume this is not offered too seriously as an alternative but is, rather, meant simply to show an ‘non-deterministic’ version. It is interesting that this version seems to miss what is, in my view, the most important issue with the original, in the way it simply copies the same depiction of the client desktop/browser.

As Tony Ross reports, Andy Powell has described his diagram as a ‘myth’, albeit a sometimes ‘helpful’ one. I know from conversations with Andy that he is cognisant of the ‘side-effects’ of the ways in which his diagram has been used. It has, perhaps, ended up occupying an uncomfortable middle ground between model and metaphor. Perhaps so. But, and this is the most important thing, while this model might have been wrong, it has nonetheless been useful.

“All models are wrong, but some are useful”, attributed to George Box.

The opportunistic developer prefers to use someone else’s service/component in the majority of cases. They will create their own software when necessary, and will choose to do so under certain circumstances, but they will accommodate a certain amount of compromise if it means they can get away with using something off-the-shelf. The opportunistic developer is still a developer, as opposed to a power user: they will still write code, just as little as they can get away with.

The proliferation of freely available web-services with simple APIs has created a happy-hunting-ground for the opportunistic developer – a few years ago they were inhibited by a lack of choice of available services to use. In addition to the usual concerns – stability, provenance, price… ease of use is becoming a more important differentiator.

In the JISC Information Environment, the norm has been to develop SOAP interfaces to services, almost by default. There are, no doubt, reasons why this has made sense in the past. However, if there is one thing which became abundantly clear at last week’s IE Demonstrator/CRIG event, it is that institutional repository developers do not want to have to use SOAP interfaces. Aside from the hard-core which is interested in pushing REST as the approach to use in repository-service interactions, the consensus was that the use of SOAP for public service interfaces, rather than being an enabling mechanism, is actually a barrier to adoption.

Whether RESTful or not, services are going to have to start having very good reasons for not offering very simple APIs over HTTP, if they are to attract the opportunistic developer.