All models are wrong, but some are useful
In the latest edition of Ariadne the JISC Information Environment (JISC IE), and that diagram in particular, get taken to task by Tony Ross in an article called Lost in the JISC Information Environment.
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.