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