JRA1 Deliverable Review Form

Identification of the deliverable or milestone
Project: EMI	Deliverable or milestone identifier: D1.4
Title: DNA1.4 - EMI Roadmap and DCI Collaborations	Doc. identifier: EMI-DNA1.4-1277542-EMI_Roadmap_DCI_Collaborations-v0.3.doc
Author(s): Alberto Di Meeglio	Due date:14/12/10

Identification of the reviewer
Name: O. Smirnova	Affiliation: LU	EMI Activity/External project or Institute: JRA1

Review date	12/12/10
Author(s) revision date	27/02/2011
Reviewer acceptance date	mm/dd/yyyy

Attach the reviewed document to the deliverable page, put here a link

General comments

The document broadly addresses its description in DoW and thus is a quite good first draft. However, at 55 pages, it is rather excessive, being in places merely an extended high-level overview of other deliverables, such as the release plan, collaborations plan etc.. I did not review the Appendix A, since I understood it is not subject to EMI QA; nevertheless, it is curious to observe that the two documents are not exactly in sync, and I am not sure which has to be adjusted (see detailed comments below).

While presenting the EMI Roadmap and mentioning technical objectives, the document never refers to the actual high level Technical Development Plan (DNA1.3.1), while referring to lower-level plans like the Standardisation one (DJRA1.5.1). Instead of the Roadmap (ordered collection of goals and milestones), the reader is presented with references to other roadmaps and the generic software development plan, which is not actually placed in the context of the European infrastructure vision, as the DoW requires. Specifically, as stems from Appendix A, the European DCI vision is that of a grid of virtualised resources, federated across European research areas, while the presented Roadmap has no explicit indication how it will support the stated vision (the word "virtual" appears only once in the Roadmap section, and in a different context).

The narrative style of the document makes it difficult to pinpoint the specific common collaboration objectives and specific collaboration mechanisms, as requested in the DoW: the objectives and mechanisms are actually described, but are well hidden in the plain text, and are not summarised in either the Executive Summary, or in the Conclusions. Being an EMI deliverable, the document must explicitly describe how collaboration with other projects benefits EMI.

While reviewing the document, I was able to filter out the following specific collaboration objectives:

• Projects will make use of each other products, such as:
  • Software
  • Technologies
  • Know-how
• Projects will work together in developing common standards and approaches
• Projects will share user support
• Project will collectively seek and share user requirements

Also, the following specific collaboration mechanisms were scattered in the text:

• Joint participation in boards and commities
• Usage of common software repositories
• Usage of common user support tools (GGUS)
• Establishment of common SLAs, MoUs and such

I would strongly recommend to include such itemized lists in either the executive summary or conclusions; I surely missed some objectives and mechanisms, so the lists perhaps need to be extended.

The document therefore needs a revision, in order to address the general comments above, taking into account the recommendations and detailed comments below.

Minor notes to the author:

• the draft has no page numbers, therefore page numbering as deduced by MS Office was used below.
• comment numbering below does not coinside with that in the document, as some comments there are about simple editorial corrections.

-- OxanaSmirnova - 12-Dec-2010

The document has been revised to present a clearer structure and a better relationship between Part 1 (The EMI Development and Collaboration Roadmap) and Part 2 (The DCI Collaboration Roadmap), which are now explicitly defined as Part 1 and Part2 to highlight their equal status within the document. A table of milestones and additional information about a number of points have been added or expanded. A number of items mentioned by the reviewers however have probably not been addressed to the level of details requested. The reason for this is that this document is not a replacement for the Collaboration Programs deliverable, the Sustainability deliverable or the Technical Plans deliverables. Detailed descriptions of the collaboration mechanisms, of the common user support tools and workflows, of the technical objectives just to mention a few are left to the respective deliverables. The goal of this document is to present an overall high-level view of the main EMI strategy and milestones, so that the individual deliverables can be better read within a coherent context.

More detailed explanation is given in the replies to individual comments

-- AlbertoDiMeglio - 27-Feb-2011

the new version is a clear improvement; and although I still have some pedantic comments, they are of minor nature and do not prevent publication of this deliverable. I therefore approve the deliverable.

Comments that may be useful for eventual revisions are:

1. There is no dissemination level on the deliverable title page. I understand that this is the format approved by PEB, but just in case this particular detail avoided PEB's attention, I'd strongly suggest to have dissemination level clearly indicated on the front page of all reports.

2. In case this report is public, I'd kindly ask to correct link to ARC middleware as: http://www.nordgrid.org/arc and replace ARC logo with this:

http://www.nordugrid.org/images/ARClogoColourTrans.png 

. This is true for all other public EMI documents. For internal as well, but they are of lesser impact. (A note: KnowARC project has finished in 2009, and its Web site has not been updated since, linking to very old middleware. The Web site is online simply because this was the EC requirement).

3. Executive summary of Part 1 mentions also Part 2, and I believe this was not the intention.

4. Extensive description of release cycle seems to be inconsistent with the otherwise high level nature of the document, especially if it is described elsewhere.

5. A small note on my previous comment on GEANT: I actually meant the GEANT software for simulation of particle interactions with matter, versions 3 and 4. I'm not aware of direct EU funding of neither ROOT nor GEANT4, and this is why I used them as fine examples of softwares that are sustainable without a solid business model.

-- OxanaSmirnova - 28-Feb-2011

Apparently, dissemination level is indicated in the footer. I think the problem is that this footer has tendency to disappear in some word processors - and this is also the reason for disappearing page numbers.

-- OxanaSmirnova - 01-Mar-2011

Additional recommendations (not affecting the document content, e.g. recommendation for future work)

As the document will have no future releases, no additional recommendations are applicable.

Detailed comments on the content

Note 1: The reviewers must list here any observation they want to track explicitly and that require interaction with the authors
Alternatively all changes must be listed in the document itself using Word change tracking features (if you use Word)
Note 2: These comments have to be explicitly addressed by the authors and the action taken must be clearly described

N°	Page	Section	Observations and Replies	Is Addressed?
1	5	1.1	Define term “collaboration” in introduction or elsewhere. Specifically, explain that it refers to a common work of several projects on same product, or to re-use of products of one project by the other in order to optimize effort. It is important to demonstrate that EMI will benefit from such collaborations. -- OxanaSmirnova - 12-Dec-2010 The following paragraph has been added to the Exec Summary of Part 1: "The goal of these collaborations is to define common objectives, perform joint activities, and reuse knowledge and technology produced by either party to optimize effort and speed up the implementation of the objectives. " -- AlbertoDiMeglio - 27-Feb-2011	OK
2	5	1.3	Please add corresponding deliverable number codes, to simplify reading (as deliverables are often referenced by the codes in the text) -- OxanaSmirnova - 12-Dec-2010 Added -- AlbertoDiMeglio - 27-Feb-2011	OK
3	9	2	The summary is somewhat excessive; instead of generic text and many references to other documents, it should clearly identify specific collaboration objectives (e.g., as an itemized list), and specific collaboration mechanisms. From the current version it is not easy to extract this information. -- OxanaSmirnova - 12-Dec-2010 The Exec Summary has been agreed to be a summary of the document keeping the same outline of the document itself introducing the reader to what they will find in each section of the document. An itemized list of the collaboration objectives and specific collboration mechanisms are in my opinion a bit out of scope within this document, since they are indeed the main focus of deliverable DNA2.1.1 - EMI Collaboration Programs -- AlbertoDiMeglio - 27-Feb-2011	OK
4	10	3	Para 1: EMI is not only focused on users; it also aims at reducing costs of infrastructure (DCI) operations, as seen from the text below. -- OxanaSmirnova - 12-Dec-2010 Added a sentence on infrastructure TCO -- AlbertoDiMeglio - 27-Feb-2011	OK
5	10	3	Para 2: Reference to the Technical Development plan which defines these objectives is needed here -- OxanaSmirnova - 12-Dec-2010 Added -- AlbertoDiMeglio - 27-Feb-2011	OK
6	10	3	4th bullet: Unlike the previous 3 areas, this view is narrowed to the collaborations aspect of sustainability, and that is narrowed to commercial companies. Our products must be sustainable even without commercial companies; e.g. GEANT or ROOT are sustainable because user communities support them. -- OxanaSmirnova - 12-Dec-2010 Expanded the paragraph to include the open source communities; However sustainabilty without subsidies means commercial activities; GEANT and ROOT are not really sustainable, they keep getting money from the EC. Of course here my concept of sustainabilty is that the EC contributions can be reduced or even removed. Another definitions for sustainability can of course be that the middleware is so used and necessary that even if nobody is willing to pay for it, the EC has to keep funding it (this is closer to the GEANT modem). This would mean sustainability for the middleware, but I'm not sure this is what the EC is thinking about -- AlbertoDiMeglio - 27-Feb-2011	OK
7	10	3.1	Section title: Can vision have a roadmap? Semantically, roadmap relates to a process, and vision in this section is not described as a process. Eurospeak overload -- OxanaSmirnova - 12-Dec-2010 Well, the vision is usually defined as a description of a final status of things that your project aims at establishing. The mission is what you intend to do to get there. Therefore I do not see any contradiction in having a roadmap to a vision ,on the contrary. However, it's really a matter of definitions. Not that Google should be taken as ultimate reference, but just try to search for "vision and roadmap" and you get documents from almost every big software player out there, from IBM to Microsoft and the like -- AlbertoDiMeglio - 27-Feb-2011	OK
8	10	3.1	Point out that this document (DCI Roadmap) itself is a nice example of beneficial collaboration between the projects: instead of creating 6 roadmaps, they jointly created one. -- OxanaSmirnova - 12-Dec-2010 Added "This document represents an important example of collaboration, where the six projects together have joined forces to create a single vision all of them can contribute to, rather than defining six separate visions" -- AlbertoDiMeglio - 27-Feb-2011	OK
9	11	3.2	This roadmap does not address the DCI vision in Appendix A. The vision is “A grid of virtualised resources, federated across ERA”. Nothing in this section explains how EMI will facilitate virtualisation and federation. -- OxanaSmirnova - 12-Dec-2010 This is not explained here because it is described in Part 2 as being base on important EMI functionality like messaging, integration of virtualization, chnges in the security models, etc. In addition, the roadmap in Part 1 doesn't describe technical objectives. The yearly technical plans are important milestones in the roadmap and are the place where this kind of information must be described -- AlbertoDiMeglio - 27-Feb-2011	OK
10	11	3.2	At this point in the document, this vision (DCI) is not defined, makes reading difficult. -- OxanaSmirnova - 12-Dec-2010 I agree, but I did't find a better way of doing this without repeating the same text in both Part 1 and Part 2. I've split the responsibilties of the two parts, putting in part 1 a description of the implementation details and leaving in Part 2 the definition of the vision. This is the drawback of having the document structured in this way, but this is what has been agreed. -- AlbertoDiMeglio - 27-Feb-2011	OK
11	11	3.2	Line 2: Another semantic problem: roadmaps don’t evolve (not much, anyway), - rather, they describe evolution -- OxanaSmirnova - 12-Dec-2010 Rephrased (assuming I found the correct place where this stated) -- AlbertoDiMeglio - 27-Feb-2011	OK
12	11	3.2	Item 2: Elaborate on what is going to be merged, and why does it lead to redundancies and duplications. Explain that the providers bring in products offering similar functionalities, and EMI middleware is a merger of all contributed components. Similarity in functionalities may result in redundancies. Would be nice to refer here to the Technical Development plan, which explicitly identifies components to be phased out, as well as some new components. -- OxanaSmirnova - 12-Dec-2010 Also in this case, I would say that this is not a technical document, but a roadmap document, that is a set of statements of principles. Describing here what si going to merged, what duplications this would create, etc, is excessive. The point is: we consolidate and simplify, more details can be found in the dedicated documents.I have added a reference to the technical plan -- AlbertoDiMeglio - 27-Feb-2011	OK
13	11	3.2	Item 2: Semantics again: how can innovation change? You perhaps meant “from new technology trends”? -- OxanaSmirnova - 12-Dec-2010 Replace with "evolving technologies" -- AlbertoDiMeglio - 27-Feb-2011	OK
14	11	3.2	Item 3: Explain what are Reference Services: is it a core subset of EMI components, or all of them? Explain also how do components that stayed out of EMI (those to the right of the yellow box?) relate to the Reference Services. -- OxanaSmirnova - 12-Dec-2010 I may be missing something here, but I do not understand how I can add this level of details. It is not know at this time what the Reference Services are in details. Will they be all of EMI, a subset,more than EMI? It depends on what happens during the implementation. What is important is to declare that we wil consider this the main outcome of EMI and the starting point for further development (the yellow boxes). The logos at the right of the yellow boxes represent the MW collaborations providing what is inside the yellow boxes, that is "specialized services, professional support and customization". It is already explained in the text "Support for the services can be provided by the original Middleware Collaborations or commercial companies using standard SLA-based contracts" -- AlbertoDiMeglio - 27-Feb-2011	OK
15	13	3.2	Figure 2: Add numbers to the Phases as in the text (from 1 to 5), to improve readability -- OxanaSmirnova - 12-Dec-2010 I've tried but it actually makes it worse, since I have to decrease the font size to make room for the additional characters. Also this very same picture is used on several documents and I prefer not to change it in only one place -- AlbertoDiMeglio - 27-Feb-2011	OK
16	13	3.2	Item 4: A reference to a document describing the "Works with EMI" progremmae ([R1]?) would be handy -- OxanaSmirnova - 12-Dec-2010 Added [R1] -- AlbertoDiMeglio - 27-Feb-2011	OK
17	14	3.2	Para 4: Please comment on support plans for EMI 2 and EMI 3: Fig 3 creates an impression they will be supported forever -- OxanaSmirnova - 12-Dec-2010 Added reference to the sustainability plan that should describe how support is going to be provided after the end of EMI -- AlbertoDiMeglio - 27-Feb-2011	OK
18	18	4	For each project, mention explicitly: (a) specific common objectives and (b) specific collaboration mechanisms. Currently this information is well hidden in plain text. -- OxanaSmirnova - 12-Dec-2010 This is already described in Part 2 or not yet known -- AlbertoDiMeglio - 27-Feb-2011	OK
19	18	4.1	One would expect this section being identical to 4.2.1 in Appendix A, yet they are not quite the same; either syncronisation or explanation of different accents is needed -- OxanaSmirnova - 12-Dec-2010 They are not supposed to identical, but complementary. The text in Part 2 - 4.2.1 describes the collaboration areas, while the text in Part 1 - 3.2 (new numbering for 4.1) describes the channles and mechanism by which the collaboration activities are performed. Although there may be some overlap, I haven't found any contradiction between the two sections -- AlbertoDiMeglio - 27-Feb-2011	OK
20	22	5.1	Item 1: Briefly explain relations between OSG, Globus and VDT -- OxanaSmirnova - 12-Dec-2010 Done -- AlbertoDiMeglio - 27-Feb-2011	OK
21	22	5.1	Item 1: This looks more technical than others; but since we talk about VOMS and CREAM, some specific examples of future collaboration are needed. E.g., will VDT keep distributing own VOMS and CREAM packages, or will they take it from EMI? -- OxanaSmirnova - 12-Dec-2010 Well, this is exactly what has to be discussed with OSG. In any case the collaboration is more with OSG in terms of interoperability and future software initiatives, rather than sharing middleware. Actually we have stopped taking software from VDT altogether -- AlbertoDiMeglio - 27-Feb-2011	OK
22	24	6	Line 3: Experimental in which sense? Conducting common experiments? Please elaborate. -- OxanaSmirnova - 12-Dec-2010 Replaced experimental with tentative -- AlbertoDiMeglio - 27-Feb-2011	OK
23	24	6	Para 2: Any hint (already here) on who might that be? What if nobody is interested? -- OxanaSmirnova - 12-Dec-2010 I would prefer to keep this as it is. Google is mentioned, but more than that is very difficult to estimate (and even Google is a difficult partner). The text sayins explicitly that "may also come to the conclusion that the use of distributed grid infrastructures based on the concept of resource sharing may not be suitable for commercial companies", therefore we already make allowances for the fact that nobody could be interested. This is again a matter for the sustainabilty plan to explore in more details -- AlbertoDiMeglio - 27-Feb-2011	OK
24	25	7	The text in this section has no actual conclusions; either the section has to be renamed to e.g. “Outlook”, or conclusions should be written. -- OxanaSmirnova - 12-Dec-2010 It has been agreed within the PEB that the Conclusions section should indeed not be a summary of the document but a description of further work to be performed. This is exactly the same format as all other deliverables. I've expanded it a bit to cover the relationship between the collaboration plans and the release plans -- AlbertoDiMeglio - 27-Feb-2011	OK
25	26	A	This Appendix A embedded in the deliverable is rather confusing, as its sheer volume is larger than the deliverable itself, and yet it is not subject to EMI QA (and has no table of contents, making it difficult to browse). For better readability, and to stress that this part did not get through our quality assurance process, it may make sense to format it differently (maybe use different, smaller typeset?) Better still, if the 6 projects can put it on the Web and just refer to it via an URL, instead of including in 6 deliverables and making 20 reviewers reviewing the same text. -- OxanaSmirnova - 12-Dec-2010 Appendix A, now Part 2, is an integral part of this document and it is subject to the EMI QA. the text has been developed by the six DCI project in collaboration and has been thouroughly reviwed by the PEB members between August and October 2010. It has been agreed among the six projects and with the EC to include this document in each project roadmap document "as-is" -- AlbertoDiMeglio - 27-Feb-2011	OK

Any other modification, spelling or grammatical corrections, etc must be done directly in the document using tracked changes or similar mechanisms that allows the authors to identify which correction is suggested.

-- FloridaEstrella - 07-Dec-2010