Review Report 2: Total Cost of Ownership calculation

[JBodera]

Andy considers this a Major Recommendation, that is listed in many places, chief among them Recommendation 3 in Recommendations concerning future work.

The Feedback following the 2nd Periodic Report states:

Recommendation 3 (Cost Calculation Formulas and Blueprints): Deliverable D7.2 provides insights on the actual costs
incurred by the RIs towards establishing, managing, and operating FAIR data infrastructures. Each of the RIs factors
different parameters in calculating their costs. This makes it difficult to provide a universal cost-calculation formula in
a closed mathematical form. However, the Open Science community and the EOSC ecosystem could greatly benefit
from a blueprint that identifies the main factors that contribute to the Total Cost of Ownership (TCO) of a FAIR data
infrastructure. This blueprint could also describe the relevant importance of the various factors, including for example
insights on how to weight these factors for different types of RIs. It is therefore recommended that the consortium
produces and publishes such a blueprint as part of future deliverables or alternatively as a separate paper. Potentially hidden costs (e.g., legal costs, regulatory compliance) must be also considered, in addition to costs for the establishment and maintenance of the technical/technological infrastructure for FAIR data. on page 4

Moreover, the project should attempt to identify some cost calculation formulas, leveraging its cost calculation exercises that unveiled the various cost factors, along with their relevant importance in the total cost of ownership calculations. on page 7

[JBodera]

The following query was posed to our PO:

Dear Flavius,

My colleague Ornela de Giacomo and WP7 - Sustainability leader discussed internally what could be done for the
comment in the General Project Review Consolidated Report requesting the blueprint for the costs. First, at WP7 they
don’t know exactly what did the reviewer meant by “blueprint”. In the way they understand it, a blueprint is a 
document that should allow to represent a generic case, therefore be based on a good statistical base. Within 
PaNOSC we have facilities that are different amongst them, and at the same time they use different technologies 
and IT standards. Producing a blueprint based on one case doesn’t make any sense. Moreover, we agreed not to
disclose the costs of individual partners, because in many cases these costs come from individual commercial
agreements between them and the provider of a service. Saying “a typical cost for service x for a neutron spallation
source” would make it clear we are talking about ESS, and we are not allowed to share this information by some of 
the partners.

In view of the above could you advise us on what we should provide or if we should skip this recommendation?

Thank you very much.
Kind regards,

Jordi Bodera

and we have obtained the following answer:

Dear Jordi,

As far as I understood the “blueprint” recommendation this is connected to the already good work that the
consortium has done to highlight the cost breakdown. More precisely the deliverable 7.2 already provides valuable 
insights on the actual costs incurred by the RIs towards establishing, managing, and operating FAIR data infrastructures.
The request here is to generalize this type of cost breakdown, by using a mathematical form in order to highlight the 
Total Cost of Ownership of a FAIR data infrastructure. This type of mathematical formula could be very helpful to the 
Open Science Community and the EOSC ecosystem overall.
    The fact that PANOSC has different facilities that use different technologies can be as such leveraged in creating this 
blueprint formula. The purpose is not that of highlighting the costs of individual partners but rather to generalize across
all the different technologies including weights and bounds (upper, lower) but also to highlight all the different other
factors that need to be considered (including also the hidden costs).

I see this recommendation as a “nice-to-have” (so not a "need-to-have") that could be published in a white paper 
bringing added value to the Open Science Community and the overall EOSC ecosystem.


Best Regards,
Flavius Pana