EGI Cost Models

1. W EGI Cost Models megifrom indirect methods Jamie.Shiers@cern.ch

2. Introduction • So far, there have been various hints at possible – and even impossible – sizes for an eventual EGI “virtual organisation” • To cover scenarios where all or parts of its functions may be distributed • We need – rather soon – to come up with some concrete scenarios for discussion • IMHO – the place is here & the time is now! • The following admittedly hand-waving arguments show that the range of possible sizes is not infinite! • This has strong implications on possible funding and start-up scenarios • I do not wish to re-emphasize on each slide the absolute fundamental necessity that the functions & services offered by an EGI must be of clear value to the funding bodies and application communities • Preferably performed more efficiently and cheaper – even if in some / many cases implemented in a distributed and / or federated manner

3. Methodology… • Estimate minimum management overhead; • Estimate minimum FTEs per 'agreed' function; • More detailed calculations will be presented during rest of workshop – these numbers can be ‘plugged in’ to the model! • Consider mitigations; • Summary

4. Significant RoI • The requirement for a significant return-on-investment already gives some indication of a possible size of an EGI • RoI = “Cost savings” + “Functionality benefit” • For each “FTE” invested, ideally would like a return of a factor (2-3?) • A return of ± 10% is simply uninteresting • A return of an order of magnitude if simply unrealistic! • This would suggest a threshold (average) contribution of ~1FTE • (If you invest << 1FTE, your return will also be << 1FTE!)

5. The CxOs • Whether you take a company / organisation of the size of Oracle (~40,000), one the size of CERN (<3,000) or a SME the “pinnacle of management” – i.e. the CEO, CFO, CTO etc. is roughly constant • It is the layer(s) below that scale with width and depth • Executive Vice Presidents for Inter-galactic marketing etc. • How many people: • 5th floor, B60 at CERN (directorate): 17 people (at least 1 retired) • EGEE project office (Bob & friends): ~15 people • WLCG “project office”: ~6 people • LCG Management Board: ~30 people (plus alternates) • I doubt that the EGI management + assistants will be <<10 – so let’s use 10 for sake of argument!

6. Other Support Staff / Groups • Assuming that EGI is an independent – and non-hosted – organisation, additional support teams are needed • HR, legal, purchasing, transport, IT, security & maintenance etc. • OK, you can perhaps out-source some / many / all of these, but that doesn’t make them free! • If EGI were to be “hosted” by a kind organisation, may hope to get some of these functions “for free” – or at significantly reduced cost • But again, for simplicity, let’s assume something like 10 – 15 for the sum of these functions • Maybe a serious underestimate!

8. The Story so Far… • So far, we have a “virtual organisation” of 20 – 30 staff, but no clearly defined “EGI functions” • See also, e.g. http://www.terena.org/about/people/ • The cost of such an organisation is 0.5 – 1 FTE per participating NGI • Maybe we’d better start looking for some application communities who would like to contribute! • But we have probably failed pretty miserably on RoI! • Time to look at some of the functions! • Again with some simple analogies / hand-waving arguments! • I will simply look at some of the groups around me, their size, their roles & functions – more detailed analyses will presumably be part of the presentations that follow!

9. Caveat • There are two main reasons for choosing these examples: • I have been part of each of these three groups (or their ancestors / descendents) during the period of ramping up Grid production services – I hence have “insider knowledge” of what they do! • The information is readily accessible and verifiable • I already suggested some time ago that a more in-depth study – perhaps as part of D3.1, perhaps (also) performed by WP5 – should complement these estimates • We do have staffing numbers for a wide range of “WLCG Sites” – detailed info on Tier0 & Tier1 + a survey of Tier2s • I am not suggesting these groups be part of EGI!

10. CERN Grid Deployment Group • This group – in it’s 4th iteration – provides the following key functions: • CERN ROC • (m/w) Integration, Certification, Testing • Pre-production Service (together with other PPS partners) • Includes critical functions such as SAM, … • i.e. CERN’s contribution to EGEE SA1/SA3 • All of these functions are candidate functions for EGI – although there are a variety of implementation models • IT-GD consists of about 30 people, mainly funded by EGEE (see caveat on previous slide)

11. Grid Support Group at CERN • This new group inherits functions that were previously provided in IT-GD & IT-PSS • To keep it simple, primary role in EGI-speak is Application Support • It consists of about 35 people focusing on HEP AS plus a few others on non-HEP VOs • I am not suggesting such a size “centralized” in EGI, but we already discussed an absolute minimum size of 2 (e.g. per NGI as appropriate), with perhaps 5 people in a “central” team

12. Data Management Group at CERN • Performs data management and (related) middleware development for CERN, HEP and to some extent (e.g. gLite FTS, LFC, DPM…) EGEE+ communities • Also offers DB services to physics community • Roughly the same number of people as GD & GS • Not so easy to count as many “visitors” registered in all groups • Again, these are key functions that must – somehow – be provided in the “EGI era” • Of course, models whereby some of these functions are performed by one or more NGIs (funding model?) – as is the case in EGEE (I/II/III) – can be discussed

13. A Range of Functions… • Depending on how you count, the “EGI portfolio” consists of some 10 – 15 functions • Taking an average of 5 FTEs per function, you arrive at a size of 50 – 75 – to which the CxOs, legal etc must be added • I’m basing this purely on the number proposed for EGI Application Support, as proposed at December 7th Meeting in Munich… • For some functions – such as the examples given in previous slides – 5 FTEs is clearly far too few • e.g. (overall) operations (see presentation), middleware dev. (ditto?) • But for others, this may be about right (e.g. Application Support) and there is the possibility of “dual roles” • e.g. Application Support experts performing Out-reach, training and other functions part-time

14. The Ballpark • Using 3 simple arguments… • Minimum useful investment to get useful RoI; • Size of existing “grid deployment / support / development” teams; • Size calculated based on range of functions in DoW and from NGI questionnaire … we arrive at roughly the same size • Will be interesting to cross-check against ‘functional calculations’ tomorrow and Thursday as well as equivalent EGEE calculations! • The “optimal” RoI will depend not only on the exact functions provided, but also on the implementation model • But we’re O(1FTE + overheads)

16. EGI – The Challenge • I believe that the challenge can be distilled into the “Essence of this Workshop” • How can a core set of key functions be built and presented in such a fashion as to be “stunningly attractive” – and hence virtually irresistible – to NGIs? • It would seem (most) unlikely that an EGI offering all possible functions “centrally” would be affordable – let alone desirable • But some are almost certainly essential and will hopefully be clearly identified through this workshop! • We are still left with the “boot-strap” issue: • How to ensure EGI starts on-time and takes over from EGEE III in a smooth and non-disruptive manner?

17. Boot-Strap Scenarios… • It seems most unlikely that enough NGIs will be in a position to pay for the range of functions – still to be defined – that will be required as from day 1 • But if a core set of functional – together with the needed continuity from EGEE III – is not provided then we will not have met our key objectives! • Can we hope for “start-up” money – e.g. from the EU – to cover the years when additional NGIs are ramping up internally and joining the overall EGI world? • This would still require that we identify the absolute core functionality as well as the initial contributing NGIs • Plus work on an urgent plan for attracting additional NGIs and / or Application Communities in a timely fashion!

18. Summary & Conclusions • Through a variety of hand-waving arguments and analogies with existing structures, we have come up with a basic costing model of ~1-2 (and not much more…) FTEs per participating NGI / Application Community • We should be careful in counting total costs – obvious overheads (buildings, heating, IT infrastructure, snow-clearing in the winter…) should not be overlooked • The question of location could have an important influence on total costs – but so could “hosting” – i.e. benefiting from the existing infrastructures of a host institute • However, the decision should be based on the overall package – where, when & how the agreed range of functions can be offered in the most attractive and professional manner

19. Backup Slides

20. The End