New entry on the SAGrid official blog | Framework for collaboration(s) How can we work together ? A frequent question we have to respond to is How can I x SAGrid where x falls in the set of (use/join/collaborate with). We pride ourselves on SAGrid being a platform for research and collaboration, however the details of just how we expect people, communities, infrastructures and institutes to collaborate with us gets very fuzzy very quickly. The only agreement which was in place until recently was the document binding the resource providers on the production infrastructure, which was the basis for the entire collaboration. This document created the so-called SAGrid Joint Research Unit in 2008 and has been the bedrock on which our activities have been based. However, the JRU agreement itself has no legal basis, and does not adequately provide a framework for the multitude of ways that the grid can benefit various stakeholders, users and peers. While we are working on an updated version of the JRU that will take into account specific activities that the core collaboration will conduct, as well as explicit levels of operation and service for our various resources and services, we also need to provide a frictionless way for players to collaborate with us. Some initial thinking around this is outlined below - as usual, a work in progress and your comments are most welcome. A more granular framework During the last few years, specifically working through the CHAIN project (and subsequent CHAIN-REDS project) we were exposed to activities similar to our own, in great detail, in other parts of the world. One of the great successes weve had recently was the integration of SAGrid with EGI. The framework for collaboration that is adopted by EGI.eu foresees two kinds of interoperability - integration of resource infrastructure providers into via an MoU EGI.eu or peering with EGI.eu Diagram describing the model for interoperation between EGI.eu and external resource infrastructure providers CSIR Meraka, on behalf of the SAGrid JRU, has signed such an MoU with EGI.eu in order to interoperate. This model, proposed and supported by CHAIN as well, allows interoperability with EGI.eu, but doesnt speak directly to the internal needs of South Africa or African collaboration. Trying to convince new institutes to join the grid, it became clear that there was a need for a more granular framework for collaboration. Instead of a single over-arching, monolithic Memorandum of Understanding, there should be place for different kinds of interaction. Of courses these interactions - between sites providing resources, users, user communities, developers, etc - have been going on since we started activities in 2008, but each interaction needed to be developed and curated by hand. This experience has informed the thinking of what follows. Whats in it for me ? The core of any collaboration is th value proposition to the parties involved. Why should we work together instead of continuing our separate paths independently ? What will I get out of working with you; what will you get out of working with me ? A point that is often lost on many formal collaborations is that the benefit of working together is not bound to just an exchange of goods or services (you do this for me, Ill do that for you). Its important to remember that some collaborations are necessary for issues of scale. Ie we cant do any of this unless we work on it together. The institutional priority in South Africa is still an impediment to developing this kind of collaboration efficiently (but thats a story for a different blog), however in SAGrid weve certainly made a case for overcoming them. Next, well talk a bit about why it would be a good idea for various players to collaborate around specific activities. As an added bonus, well try to make the discussion object-oriented. To save on time for you, dear reader, well delve into each of these in depth in further editions of this blog. Here, for now, is a short summary of our thinking ->Join(infrastructure) In this case, an institute decides to formally participate to the resource infrastructure, and sign the JRU document as a partner to the collaboration. This is the only way right now whereby partners can be formally added to the infrastructure. Such agreements would be allowed by signature of the JRU document. ->Peer(infrastructure) We are are aware of several peer infrastructures or sets of resources which ware being developed around South Africa and Africa. This kind of agreement would allow such activities to peer with SAGrid and share common tools, such as we do with EGI.eu, e.g. the accounting system, without actually becoming a member of the core SAGrid Joint Research Unit. Such agreements would be negotiated by the coordinators of the respective projects and the SAGrid JRU, around specific activities and specific timelines. ->Support(activity) The SAGrid collaboration undertakes several activities, but they are necessarily focussed on maintaining a healthy operational infrastructure. There are however several other activities which are fundamental to achieving to these goals, such as training, development, dissemination, etc. We would like to have a way to enable experts in these fields to support us formally, by conducting specific activities for us; and vice-versa. ->Collaborate() Collaboration is difficult beast to tame. The best collaborations are formed over long periods of time, during which initially its not clear what the aim of working together is, beyond a stimulating exchange of ideas. This usually crystallises around specific tasks or deliverables, perhaps in the context of a particular project. The possibility to collaborate with the SAGrid JRU currently exists, as the CSIR is the flagbearing institute, however there is only one possibility : full participation. Baby steps To close off the initial thoughts in this post, we would like to provide the possibility to build trust and collaborations iteratively: first express the fact that there is common ground. This could be done through a letter of support for SAGrid or a particular activity. This should of course be a mutual exchange. Once it is clearer that there is common ground, no conflicts of interest, clear benefit, etc, a Letter of Intent could be signed to designate a timeline and milestones towards formal collaboration More granular templates for Memoranda of Understanding should be drawn up by the collaboration to speed up Join(), Peer(), Support() and Collaborate() methods of collaboration. This will give potential collaborators a clearer understanding of the pros, cons, rights and responsibilities related to each of these kinds of collaboration. Note that this thinking is only somewhat informed by the NICI process so far, and I do expect major details to change in the near future. Comments and feedback are of course requested !
Posted on: Thu, 17 Oct 2013 09:40:10 +0000
Trending Topics
Recently Viewed Topics
© 2015