Deliverable Review Form

Identification of the deliverable or milestone
Project: EMI Deliverable or milestone identifier: DNA1.2.1
Title: DNA1.2.1 - Service Level Agreement Template Doc. identifier: EMI-DNA1.2.1-1277517-SLA_Template-v0.5.doc
Author(s): Alberto Di Meglio Due date: PM 2

Identification of the reviewer
Name: Francesco Giacomini Affiliation: INFN EMI Activity/External project or Institute: SA1

Review date 10/10/2010
Author(s) revision date 17/11/2010
Reviewer acceptance date 29/11/2010

Reviewed document

General comments

The template and the accompanying document are of good quality and represent a good starting point to establish an SLA-based relationship between a software provider and a software user.

I have some doubts on the structure of the SLA template (see comment #10).

There are some formatting issues with the tables of contents.

Disclaimer: I guess that the text of the SLA template is some boilerplate typically used in similar situations. I don't have much experience with this "legalese" so take my comments keeping that in mind.

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

It will be difficult to apply the SLA-based approach to all the products under the EMI umbrella and to all the Support Units behind those products. We should probably identify a few of them, experiment with them and accumulate some knowledge on the best way of doing it. This also implies a more systematic measurement of the performance of the support and maintenance tasks.
-- FrancescoGiacomini - 2010-10-10

This looks more like a comment on the activity of appliying SLAs to EMI than a comment on the deliverable itself. However, in this case my opinion is that we should apply the SLA to EMI, not to individual products or services. We will collect metrics and see how good we are. Some PTs may be better than others, but the only way of knowing this is by collecting numbers. The metrics used in the SLA are not different from what SA1 is already requested to collect for all PTs and services.
-- AlbertoDiMeglio - 2010-11-17

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

Page Section Observations Is Addressed?
1 6 1.3 [R3] I hope DSA1.1 will be released at the same time as this deliverable.
-- FrancescoGiacomini - 2010-10-10

This I cannot really control, but I agree that it would be best to have DSA1.1 out first
-- AlbertoDiMeglio - 2010-11-17

DONE
2 6 1.4 A paragraph on the amendment procedure of the SLA template would be useful.
-- FrancescoGiacomini - 2010-10-10

Added
-- AlbertoDiMeglio - 2010-11-17

DONE
3 8 2 I would remove all the footnotes, all the terms, including the URLs, are mentioned in the Terminology table.
-- FrancescoGiacomini - 2010-10-10

It seems to me easier to look at the foot of the page rather than going back to the Terminology table at the front of the document. Since both reviewers have expressed this comment, I guess that resistance is futile and I've complied
-- AlbertoDiMeglio - 2010-11-17

DONE
4 10 3.1 Footnote 7 may become a reference.
-- FrancescoGiacomini - 2010-10-10

Done
-- AlbertoDiMeglio - 2010-11-17

DONE
5 10 3.2 Is it really needed to describe the EMI Work Packages?
-- FrancescoGiacomini - 2010-10-10

Yes, because they play different roles in the monitoring or application of the SLAs, I'd like these roles to be clear. I agree that the definitions could be added by reference, but in my opinion it is easier to have the text included rather than asking to look in another document
-- AlbertoDiMeglio - 2010-11-17

DONE
6 12 3.4 IGE should appear in the Terminology table.
-- FrancescoGiacomini - 2010-10-10

I guess you mean IGE. Added
-- AlbertoDiMeglio - 2010-11-17

Yes, I really mean IGE.
-- FrancescoGiacomini - 29-Nov-2010

DONE
7 15 5 September 2010 is already in the past.
-- FrancescoGiacomini - 2010-10-10

Well, yes, that is the date of the submission to the internal reviewers, the date will have to be updated when this is released officially
-- AlbertoDiMeglio - 2010-11-17

DONE
8 21 4(SLA) Are we really affected by fiscal years?
-- FrancescoGiacomini - 2010-10-10

Removed "fiscal", just once per year
-- AlbertoDiMeglio - 2010-11-17

DONE
9 21 4(SLA) "terminate the relationship if all parties cannot abide by the revisions". Shouldn't the previous revision still hold, unless expired?
-- FrancescoGiacomini - 2010-10-10

Usually the revision expires and replaces the previous versions. A revision is made to fix some type of issue on either side, leaving the previous version in effect may not be possible or desirable. I've explicitly mentioned that new versions expire the previous ones
-- AlbertoDiMeglio - 2010-11-17

DONE
10 22 5.1(SLA) I would expect that the bullets in the list would become paragraph/subsections in the following pages but I can't see them, apart from something on Web-based support. There should be at least a description of what each of those services means. Then the Customer responsibilities and the EMI Responsibilities should be structured around those services.
-- FrancescoGiacomini - 2010-10-10

One of the most critical comments from the CERN legal services around the first version of the SLA template has been that the SLA document itself should not describe the services, just the associated service levels. The description of the services must be provided to the Customers in a separate document, which in our case is the EMI User Support Plan. This is supported also by my analysis of a number of SLA from companies providing services to CERN. The Service Description and the SLA are always provided as separate documents.
-- AlbertoDiMeglio - 2010-11-17

DONE
11 22 5.2.1(SLA) "Component" has not been defined. And in any case I would replace it with "Product".
-- FrancescoGiacomini - 2010-10-10

Added definition of Component in the Glossary. However, I'm not sure Component and Product are equivalent. A Product is a generic EMI Middleware Service, Client or Library, but it cam be composed of several Components
-- AlbertoDiMeglio - 2010-11-17

DONE
12 22 5.2.1(SLA) Using "you" to mean the customer is inappropriate, unless it is defined before, e.g. in Section 3 (of the SLA) in correspondence with Customer.
-- FrancescoGiacomini - 2010-10-10

Indeed, it should be Customer everywhere. I replaced all the occurences of "you" were appropriate
-- AlbertoDiMeglio - 2010-11-17

DONE
13 22 5.2.2(SLA) Where are (or will be) the Designated Contacts specified? Maybe in Section 11 (of the SLA), "Communication"? If so, tell it.
-- FrancescoGiacomini - 2010-10-10

Yes, it is section 11. I've explicitly added the word "designated"
-- AlbertoDiMeglio - 2010-11-17

DONE
14 23 5.2.5(SLA) Bullet (a): is it reasonable to require to backup and secure all programs and data on affected services?
-- FrancescoGiacomini - 2010-10-10

I would say so, we need to protect us. If we suggest a workaround or a fix and this causes loss of data, we cannot be held responsible. This is a standard clause everywhere. If you check the instructions of most software updates, service packs, etc, there is always written something to that effect. We could explicitly say that whatever happens is not our fault, but having a concrete action as a reference is safer. if someone says: "You completly lost three years of analysis data!!!", I believe it is better to ask "Did you run the backup before installing the fix?" than saying "Sorry, not my fault. Thanks for using EMI"
-- AlbertoDiMeglio - 2010-11-17

DONE
15 23 5.2.5(SLA) Bullet (b): it is not about "Backup and Removal of Data", which is the title of the section.
-- FrancescoGiacomini - 2010-10-10

Not sure I understand this. It talks about backup and removal of data and software, I've added "and Software" to be more specific, but the rest looks fine to me
-- AlbertoDiMeglio - 2010-11-17

DONE
16 23 5.3(SLA) The link http://www.eu-emi.eu/support/EMI_Support_Plan.pdf doesn't exist (yet).
-- FrancescoGiacomini - 2010-10-10

True, I need the official version of the Support Plan before i can upload it to the web. Hopefully it will be there before this is submitted
-- AlbertoDiMeglio - 2010-11-17

DONE
17 24 5.3.2(SLA) The link http://www.eu-emi.eu/services/lifecycle/support_periods.htm doesn't exist (yet).
-- FrancescoGiacomini - 2010-10-10

Same as above, we need to define those support periods for each Product. i have to mention links to this artefacts, but I cannot provide the content. We can put an overall EMI Releases support policy statement, as soon as the policy is defined in the EMI Support Plan
-- AlbertoDiMeglio - 2010-11-17

DONE
18 25 5.3.5(SLA) Can EMI charge any cost to a Customer?
-- FrancescoGiacomini - 2010-10-10

Yes. For example, in case we are asked to have someone provide on-site technical support, we can ask for travel and subsistence to be paid by the Customer. We have no special provision for this in the EMI budget. The travel and subsistence budget is usually for attending EMI events or conference, workshops, etc.
-- AlbertoDiMeglio - 2010-11-17

DONE
19 25 5.4(SLA) The link http://www.eu-emi.eu/support/EMI_Support_Plan.pdf doesn't exist (yet).
-- FrancescoGiacomini - 2010-10-10

See comment 16
-- AlbertoDiMeglio - 2010-11-17

DONE
20 27 5.4.1(SLA) Will we really provide Product Forums? it seems to me a lot of work and overlaps with already established communication channels for the communities around the existing services.
-- FrancescoGiacomini - 2010-10-10

This is something that was foreseen by NA2. The liferay system INFN is setting up has functionality to host forums of this kind. This are sort of users-help-users forums, not standard support channels. Most companies have this self-help tools in place, it helps building an expert community and decreases the load on the official support channels
-- AlbertoDiMeglio - 2010-11-17

DONE
21 27 4.3(SLA) - but should be 5.4.2 Is this section about the normal User Support or is it something else?
-- FrancescoGiacomini - 2010-10-10

Updated section number. The section is supposed to be about the standard user support. I can modify it, if you give me some more specific comment
-- AlbertoDiMeglio - 2010-11-17

DONE
22 27 6.1(SLA) The text of the Comments for the "Web Support" Service needs some rewriting.
-- FrancescoGiacomini - 2010-10-10

I would need some more specific comment on this. This is the current writing "Web support requests are automatically acknowledged upon reception. Requests received after office hours will be stored in the support system, however no action can be guaranteed until the next working day"
-- AlbertoDiMeglio - 2010-11-17

DONE
23 28 6.2(SLA) GGUS doesn't have the concept of Severity, only of Priority, which is a field set by the user during submission, with 4 possible values. There is no criteria on how to select a certain value.
-- FrancescoGiacomini - 2010-10-10

Actually, GGUS by definition of user support system has only Severity, the problem is that they call it Priority and give the Priority levels a mix of Priority and Urgency values. It's rather messy. I suggest we interpret the GGUS field as Severity and map the values to the more standard Severity values that we want to use. I've added a map of values in the table for clarity
-- AlbertoDiMeglio - 2010-11-17

DONE
24 29 9.1(SLA) The probability of "acts of God" is so small that we could ignore them.
-- FrancescoGiacomini - 2010-10-10

The term "acts of God" is an official legal term in Contract Law used as an "implied defense under the rule of impossibility: i.e, the promise is discharged because of unforeseen, naturally occurring events that were unavoidable and which would result in insurmountable delay, expense, or other material breach"
-- AlbertoDiMeglio - 2010-11-17

DONE
25 29 9.2(SLA) What does "assignment" mean in this context?
-- FrancescoGiacomini - 2010-10-10

In legal parlance an Assignment is "a transfer of rights between two parties". This clause means that the Customer cannot transfer its support rights to another party. For example if we have an SLA with a project for one year, when the project ends the SLA cannot be transferred to another projects carrying over the same activities without prior written consent of EMI
-- AlbertoDiMeglio - 2010-11-17

DONE
26 33 Appendix: Definitions The definition of Severity is slightly different than the one used in DSA1.1 (Maintenance and User Support Plan), merging the concepts of Severity and Impact as introduced in DSA1.1. This is not a big deal in fact; it's more important to address comment #23, on matching what GGUS offers.
-- FrancescoGiacomini - 2010-10-10

I haven't found a detailed definition of the Severity levels in DSA1.1 (which BTW, I think it's something missing from the deliverable, there should be a more precise definition of the Severity levels in the User Support section). The only definition I've found is "Severity: a measure of the degradation of the quality of service of the affected component". The definition of the severity levels in the SLA Template doesn't seem to be in contradiction with this generic definition of Severity in DSA1.1
-- AlbertoDiMeglio - 2010-11-17

DONE

-- FloridaEstrella - 01-Oct-2010

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r6 - 2010-11-30 - AlbertoDiMeglio
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback