Position Statement Michael Daw – University of Manchester January 2007 Realising Coordinating e-Research Endeavours Workshop Position Statement Michael Daw University of Manchester January 2007 How do you encourage and manage research collaboration in eResearch? e-Research collaboration can (and is) encouraged by allocating research funding to such effort. Without the push from funders, the effort from collaborators would very likely be much smaller. For these projects to be successful there needs to be perceived and clear benefit for collaborators. e-Research tends by its very nature to involve distributed collaborations, with partners spread across the UK, Europe, or even the world. This means that there is an immediate and persistent barrier to collaboration because of the increased time and effort involved in these kinds of collaborations. A glib solution may be to "use more collaborative technologies"; in some instances (Access Grid/videoconferencing) these can indeed be very helpful or even required for such collaborations to happen at all, but most of these technologies are not sufficiently mature to solve all the problems involved with distributed collaborations. Whilst there is work going on to meet some of these challenges (e.g. the VRE programme, etc.), it has not so far been prioritised enough, which means there is a gap in requirements and technology. How do you manage e-Research projects and the relationship between the various stakeholders involved? It is the nature of the funding process that expectations are high because of the need for proposals to sell ideas. What emerges may fall short of these expectations because resource does not match the work required. Stakeholders need to be prioritised so that it is clear who are to be the main beneficiaries. Again, a steer from funders is very useful – a good example is the recent JISC VRE 2 programme call, which built on lessons learnt from the first phase and mandated a highly user-focussed approach in proposals. How can the relationship between emerging requirements and ongoing technological development be managed? Users need to be at the heart of the development process to facilitate maximum collaboration and communication between users and developers. Projects work best when developers understand what users need and why and users understand the constraints on 1 Position Statement Michael Daw – University of Manchester January 2007 development. This gives the greatest chance of avoiding a situation where users ask for far more than is possible to be developed with the resources available, and where they understand the inevitable lag between requirements specification and the resulting functionality. It also allows greater confidence in follow-on projects that can begin to meet emerging requirements. How do we match the facilities of e-Research with particular scientific cultures? We need to engage users first – show them how things work with demonstrators and then roll these out so that they become required tools in researchers' work. Through this process, we will be in a better position to understand different research cultures, and accommodate these in e-Research technologies. It is difficult to see how this can be done without a high level of user engagement over the long term. How do we promote and support sustainable use of eInfrastructures for research? Because e-Infrastructure technology can be specialised, its promotion requires that we know the researchers' culture. To promote it properly, we cannot expect potential users to come to us; we must go to them. The next stage in recruiting users is by demonstrations at conferences native to target disciplines, although care must be taken to avoid unwarranted hype. Support for sustainable use of e-Infrastructures requires investment and expertise from fields that already support conventional infrastructures. A lot can be learnt from organisations such as UKERNA, who specialise in this kind of support; however, there is a danger of moving too quickly to a service mode whilst the amount of innovation is so high. Perhaps we need a 'conveyor belt' of services that have different levels of robustness so that exciting new functionality can still be supported, even though it will not meet stringent service levels. 2