1. EOSC Service Architecture
Sergio Andreozzi
EGI Foundation
2nd EOSCpilot Governance Development Forum workshop, 3 October 2017, Tallinn (Estonia)

2. Outline What does the EOSC needs to support
Roles involved in using/managing the EOSC services
Architecture
Types of services
Next steps

3. EOSC as an evolving system serving a multitude of actors
What: Open Science
A systemic change in the modus operandi of science and research
Affecting the whole research cycle and its stakeholders
Commissioner Carlos Moedas Open Science Presidency Conference Amsterdam, 4 April 2016
This is the first slide of “What”
EOSC as an evolving system serving a multitude of actors

4. EOSC supporting collaboration & sharing
Open Science
“Open Science represents a new approach to the scientific process based on cooperative work and new ways of diffusing knowledge by using digital technologies and new collaborative tools. The idea captures a systemic change to the way science and research have been carried out for the last fifty years: shifting from the standard practices of publishing research results in scientific publications towards sharing and using all available knowledge at an earlier stage in the research process.” “Open Science has an impact on the entire research cycle, from the inception of research to its publication, and on how this cycle is organised.”
EOSC supporting collaboration & sharing

5. Open Science opens up the entire research enterprise…..
EOSC “users”
Open Science opens up the entire research enterprise…..
Open Science opens up the entire research enterprise (inner circle) by using a variety of means and digital tools (outer circle) [EC - DG R&I 2016, p. 36]
EOSC as a facilitator of new scholarly and scientific processes

6. EOSC “users” Scientists Managers Infras provider Service provider
Use functions and tools to perform their domain specific research activities and to collaborate
Scientists
Managers
Infras provider
Service provider
Service developer
Data scientists
Facilitate the operation, assistance and quality assurance of the EOSC system and the coordination among its different stakeholders
Develop new analytical models, new processes and tools to analyse data and derive knowledge
Provide access to computational, storage and network resources, according to declared SLAs
Develop services for scientists by understanding their requirements and the Open Science vision
In order to reach efficency and sustainability EOSC must offer facilities that support all the OS actors roles. Note: we may need to further specialise them (especially the manageres) and other may have to be introduced (e.g. research managers/administrators monitoring research trends)
Operate and provide access to their own portfolio of services according to declared SLAs

7. EOSC “users” (cont.) These users
operate with different types of resources and
demand different services and working environments
Scientists and developer scientists need services to produce research artifacts (including methods and tools) and need virtual research environments to support their multidisciplinary collaboration
Developers of services often demand for access to appropriate platforms, including those providing facilitated access to computational and storage resources
Scientists
Managers
Infras provider
Service provider
Service developer
Data scientists

8. EOSC “users” & “resources”
Research asset / artifacts inclusive of papers, datasets, scientific software, scientific workflows, notebooks, compound “research objects”
virtual research environment specifically set up for supporting any research question / endeavor / goal
Scientists
Managers
Infras provider
Service provider
Service developer
Data scientists
Service that includes all the functions exploited to deliver, monitor, and orchestrate the EOSC system
Policies and Procedures defined to govern the EOSC system
SLA used to define the level of service expected from the service provider
Scientific software that is almost daily produced, usually developed in the form of scripts / small programs and non- necessarily following strong software engineering practices, likely developed by non- professional computer scientists
Computational and storage resources that are made accessible according to the policies and SLA EOSC is expected to deliver
Software that is produced, published, and managed according the FAIR principles EOSC is expected to deliver
In order to reach efficency and sustainability EOSC must offre facilities that support all the OS actors roles.Note: we may need to further specialise them (especially the manageres) and other may have to be introduced (e.g. research managers/administrators monitoring reserach thrends)
Scientific service that is made accessible according to the policies and SLA EOSC is expected to deliver

9. An abstract scenario Provides server “S”
Service Catalogue
Publishes Service X on Service Catalogue
Service “X” runs on “S”
INFRASTRUCTURE
PROVIDER
SERVICE
PROVIDER
SERVICE Developer
Service X was developed by
Server “S”
Executes the service on his data
gets result
Dataset D
Finds the Service
DATA SCIENTIST
SCIENTIST D
Collaborate
Finds D and use it in a
Scientific paper
Publishes result (e.g. dataset)
In the Data Catalogue D
DATA Catalogue

10. A Real-World Scenario: PanCancer (Science Demonstrator funded in EOSCpilot)
Cancer researchers and the end users of BUTLER platform
Scientists
Managers
Infras provider
Service provider
Service developer
Data scientists
Provisioning services Ensuring SLAs are delivered Supporting users
The data experts who produce the data and are aware of the application requirements of it
Cloud and data storage resource providers
In order to reach efficency and sustainability EOSC must offre facilities that support all the OS actors roles.Note: we may need to further specialise them (especially the manageres) and other may have to be introduced (e.g. research managers/administrators monitoring reserach thrends)
BUTLER and Onedata software developers
Service providers running: - Onedata-based service
- Cloud compute and Offering storage + computing capacity

11. How: Experts suggestions
It should “federated, globally accessible, multidisciplinary environment” where researchers, innovators, companies and citizens can publish, find, use and reuse each other's data, tools, publications and other outputs for research, innovation and educational purposes [OSPP EOSC report expanded from HLEG EOSC report,
It should “build on existing capacity and expertise where possible”
It is approached as a “federated environment for scientific data sharing and re-use, based on existing and emerging elements in the Member States, with lightweight international guidance and governance and a large degree of freedom regarding practical implementation”
“It should enable trusted access to services, systems and the re-use of shared scientific data across disciplinary, social and geographical borders”
Here it starts “How”
Basic “principles” for the implementation of the EOSC system architecture
(from the HLEG on EOSC)

12. Excerpts from the EOSC Declaration
federation
more capacity for more users
co-created
with users
federation-enabling services needed
EOSC Declaration, 10 Jul 2017

13. EOSC as a System-of-Systems
Componets can both enter in EOSC and disappear
Components:
Exiting and emerging RIs, e-Infras, data repositories, registries,…

14. EOSC as a System-of-Systems
RIj
DRs
DRz
RIx
RIt
E-Infraa Ra
E-Infrab
E-Infraa
RIk
RIg
Componets can both enter in EOSC and disappear Rw
Components:
Existing and emerging RIs, e-Infras, data repositories, registries,…

15. System-of-systems: characterising properties
Operational and
managerial independence
Each system is independent and it achieves its purposes by itself and for its own objective rather than for the purposes of the SoS
Geographical distribution
A SoS is distributed over a large geographic extent
Added-Value
A SoS has capabilities and properties that do not reside in the component systems
RIj
DRs
DRz
RIx
RIt
E-Infaa Ra
Evolutionary development
A SoS evolves with time and experience
E-Infab
RIg
RIk
E-Infaa Rw
Heterogeneity of constituent systems
A SoS consists of multiple, heterogeneous, operating systems embedded in networks at multiple levels
The EOSC architecture is designed to satisfy these principles

16. Need for a federation and access layer
EOSC Hub
EOSC Domain 1
EOSC Domain 2
EOSC Domain 3
EOSC Domain n

17. Example of hub concept as designed by the EOSC-hub project
EOSC-hub is a project successfully evaluated in the H2020 EINFRA Call – Planned start 1/1/2018

18. Abstract Class of Services
PID Service
Alert Service
Recommender Service
Data Catalogue
IT Security
Operational Service Mgmt
Citation Service
Metadata Enrichment
Metadata Linking
Metadata Validation
Environment continuity
Operations bridge
Workflow Service
Service Catalogue
Repository Service
Repository Validation
Policy and Licence Helper
Semantic Integration Helper
VRE Factory
Service continuity
Services for EOSC Managers
Service Desk
VRE Factory
Shared Workspace
Social Networking Service
Scientists
IDE as_a_service
RStudio
MatLab
Validation Environment
Service Catalogue
IT Security
Environment operations
Software Repository
Assessment Environment
VRE Factory
Data Scientists
Service Desk
Services for …
Python
Validation Environment
Transition Environment
Service Catalogue
IT Security
Operations bridge
Environment operations
Data Catalogue
Service transition
Service Developers
VRE Factory
Service Desk

19. Abstract Class of Services (cont.)
Service Dashboard
Service Catalogue
IT Security
Multi-supplier coordination
Resource Catalogue
Service continuity
Service Providers
Service Desk
Services for EOSC Managers
Infrastructure Dashboard
Infrastructure Providers
Service Desk
Multi-supplier coordination
Services for …
The identification of the EOSC services is intended to be an iterative process that will evolve
through the requirements received from the demonstrators
with the evolution of the other elements that are involved in its development, like rule of engagement, incentives and rewards, policies, and governance
For the set of necessary services identified, it is not yet specified who will be the service provider that will operate and delivery these services

20. Validation and monitoring of EOSC principles of engagement: examples
Scientists
Managers
Infras provider
Service provider
Service developer
Data scientists
Scientists exploiting EOSC must have a known identity and profile
EOSC Scientists produced artifacts must be deposited and findable
Developed software services in EOSC must have an explicit licence associated with them
All EOSC services must be registered in the EOSC catalogue of services
Infrastructure providers must ensure the established SLA
Service Desk operational hours are …

21. EOSCpilot WP5: Main Delivereables
D5.1 : Initial EOSC Service Architecture the high-level EOSC (reference) service architecture [12]
Initial EOSC Service Architecture the high-level EOSC (reference) service architecture
D5.4 : Final EOSC Service Architecture [24]
Final EOSC Service Architecture describes the high-level EOSC (reference) service architecture updated after input from executed service pilots and WP6 Interoperability.

22. Summary EOSC Service Architecture System of systems approach
Initial actor roles identified
Initial service layers identified
Initial analysis of types of services per layer performed
Service federator role vs. federated system/domain

23. Thank you :-) For feedback: Donatella Castelli EOSCPilot WP5 Leader