NGRE, VRE, VL, SG – What’s in an acronym?

I was interviewed today (5th April 2017) by Max Hammond, a consultant presently working on behalf of Jisc to make sense of the landscape around what Jisc calls “Next Generation Research Environments” (NGRE). Coincidentally, yesterday I had been involved in an exchange of emails in the context of the Horizon 2020 funded ENVRIplus and VRE4EIC projects about a proposed architecture for “Virtual Research Environments” (VRE). There I tried to make clear the distinction between VREs, Virtual Laboratories (VL) and Science Gateways (SG) as I presently understand them.

I always find it helpful to revert to familiar examples in the real world when trying to define and differentiate different terms and concepts in use in the cyber or virtual world. In the real world we have real research environments, real laboratories and physical infrastructure(s). For example, my research environment is the totality of the university department where I work. It’s a broadly organised space for my kind (discipline) of research, including several well-founded laboratories equipped with specific assets to support specific research objectives. (I can go on here in more detail about the different types of physical laboratory that also have their virtual analogues but will save that for another time). These laboratories contain benches, utility supplies, equipment, computers, etc., mostly sufficient for my day-to-day work needs. They may share some assets in common, such as larger, more specific and more expensive instruments. Occasionally, I must collaborate with my colleagues elsewhere in my university, or even externally. This is my larger research infrastructure. Indeed, depending on whether I’m working with colleagues in medicine, or social sciences, or engineering, or environmental sciences I may be operating in and across several of these larger infrastructures, each of which has its own overlying research environment. Sometimes, at either the level of the laboratory or the level of the infrastructure we will outsource our needs to a 3rd party supplier instead of making our own capital / operating investments. Sharing a telescope for seeing the stars or chartering a boat for an occasional marine research campaign instead of buying our own boat comes to mind here.

When we transform this story to the cyberworld of VREs, VLs, RIs (Research infrastructures), e-Is (e-Infrastructure or cyberinfrastructure in the USA), etc. I think it is easy to see the relations between the entities. VREs surround VLs and overlay e-RIs, which may depend on or outsource to e-Is. Only Science Gateways are missing from what I described. In the real world these are the libraries through which access to existing research results can be gained. They are part of the wider university level infrastructure within which I’m situated. As such, they are a part of VREs, alongside VLs but with different purpose.

I explained to Max that I think that VREs are synonymous with NGREs, to which he offered the reply that there is a body of opinion (largely coming from research administrators) that the research environment is not only the immediate environment within which a researcher finds themself but also the wider environment of administrative support for the research process. By that they mean offering support to find sources of funding and applying for them, research information management (RIM) and research data management (RDM) systems, publications archives / repositories, project management, financial management, etc. A broad scope indeed! I have sympathy with the view but suggested that these areas are largely moving forward, developing of their own accord and in a coherent manner; whereas the more immediate virtual equivalent of the physical research environment that I describe above is much more muddled and stagnant. There is a boundary to be drawn but it might be somewhat grey and broad as opposed to narrow and distinct – just as it is in the physical research environment description.

We went on to talk about some of the key characteristics of Virtual Research Environments and Virtual Laboratories. In particular, whatever the purpose of the laboratory there are several categories of assets/resources that must be provided. All physical laboratories contain benches, gas, water, electricity supplies, weighing instruments, lab notebooks, etc. Even as the lab’s purpose becomes more specialised, these basic things are still needed. What are the standard item equivalents in a virtual laboratory we wondered? As the laboratory becomes more specialised it is equipped with items appropriate to that specialisation. It’s easy to identify these more (and probably sub-domain) specific software tools, workflows, data and other resources, modelling environments, etc. but the general supporting infrastructure stuff that would be widely deployed and used? That’s not so easy to see just yet. I’ll come back to that later on in another article. There are new ideas coming from the VRE4EIC project in a paper by my colleague Keith Jeffery et al. on “A Reference Architecture for Virtual Research Environments” (pages 76 – 88 in the conference proceedings) and I have some additional ones – they’re in my head but I need to organise some thoughts and get them out there.

Collaboration is another key characteristic that was mentioned. As we see from the real-world analogue, collaboration and cooperation is essential within a typical research environment. On one, immediately apparent practical level this concerns the idea (and difficulties) of people working together day-to-day using email, Skype, web conferencing systems like Cisco WebEx or AdobeConnect, filing sharing systems like Dropbox or their institutional equivalents, collaborative editing tools like those from Google and Microsoft, etc. On another level, which I characterise as the consortium level it is concerned with approaches that encompass (variously) work on scalable virtual organisations (Foster, Kesselman and Tuecke) and collaborative networked organisations (Camarinha-Matos and Afsarmanesh). More recently it appears also in architectures for data-intensive federations that I’ve been working on with Malcolm Atkinson where mechanisms for enforcing policy controls on access to partners’ data by members of a federation / collaboration (cf. access to physical laboratories), as well as for managing the rules of the federation itself are essential. Had such dynamic, instantaneous data-intensive federations been possible back in 2010, European aviation might not have been grounded for quite so long in the face of the erupting Eyjafjallajökull volcano in Iceland.

Lastly, we talked briefly about top-down versus bottom-up mechanisms for stimulating movement towards more widely available, more generic practical solutions to the NGRE/VRE/VL problem. There’s probably sufficient to say there to justify an entirely separate article but for the moment it’s enough to say that still some really substantial coordinated resource input is needed to allow bottom up engineering to emerge that is coordinated and aligned within and across domains by some top-down strategic directives based in all previous practical experience and learning so far. I will explain this with a phrase that Max used in his introduction to me, which was that we are still “trying to increase the resolution at which the challenge is understood so that we can get a better idea where to focus and where to place effort“. Indeed, further increasing and disseminating true understanding of the problem space is both valuable and essential to progress.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s