Egi cost models
1 / 20

EGI Cost Models - PowerPoint PPT Presentation

  • Uploaded on

W. EGI Cost Models. m egi from indirect methods [email protected] 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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' EGI Cost Models' - dorie

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Egi cost models


EGI Cost Models

megifrom indirect methods

[email protected]


  • 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


  • 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

Significant roi
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!)

The cxos
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!

Other support staff groups
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!

The story so far
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.

  • 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!


  • 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!

Cern grid deployment group
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)

Grid support group at cern
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

Data management group at cern
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

A range of functions
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

The ballpark
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)

Egi the challenge
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?

Boot strap scenarios
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!

Summary conclusions
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