EOSC Service Catalogue and Portfolio Management: FitSM Approach
The service portfolio needs to be driven by user’s needs. How can the EOSC governance be structured in order to ensure adequate representation of users and active participation in the service portfolio management in EOSC?
It is essential that the EOSC uses a set of defined terms and concepts that can ensure clarity between all parties involved. FitSM is a lightweight service management standard that was an output of an EU-funded FP7 project called FedSM, which offers both formal vocabulary and requirements as well as implementation guidance through activities, roles, templates, samples and a maturity assessment (www.fitsm.eu).
FitSM has become commonly referenced and implemented across the e-Infrastructure community, though not limited to it. There are two key definitions that need to be well-understood and order to apply a common framework that will allow the EOSC to function as a federation:
- "Service portfolio", an internal list that details all the services offered by a service provider, including those in preparation, live and discontinued
- "Service catalogue", a user/customer facing list of all live services offered along with relevant information about these services.
As the front-facing interface for all EOSC services, the EOSC Service Catalogue will need to allow for at least two streams of services:
- Any service being submitted from relevant EOSC stakeholders and
- Internal services to the EOSC that build common services such as accounting, monitoring, AAI.
Formal Service Portfolio Management (SPM) will need to be more coordinated in the latter scenario, as in the former, the majority of SPM will happen internal to the given organisations, only submitting production quality services for publication in the EOSC Service Catalogue. Here, a more lightweight approach needs to be taken, only structuring content through a standardised service description template. As the EOSC evolves, further distinction can be made for services that follow/comply with a higher set of principles outlined by EOSC.
What criteria should services of the EOSC meet in order to be part of the service portfolio?
As a general approach, the EOSC should start simple and evolve over time. Publication of services within the EOSC Catalogue should be as inclusive as possible with only a lightweight management that is facilitated by a structured service description template. The EOSC HLEG report started to define some of these principles, which should be the starting point for further evaluation of how individual services could be verified against such criteria and given highlighted acknowledgement through the EOSC Catalogue.
For any services to be technically integrated within a common service architecture, a more formal approach needs to be taken to Service Portfolio Management and how those services are designed and transitioned into the live environment and then defined within a potential EOSC Internal Service Catalogue.
How can certification be organized to ensure that services of the EOSC service portfolio meet a list of community-defined requirements?
The main challenge with community-related certification (or any form of stamp of approval) is with representation. The majority of communities typically do not have a single representative or group that is able to speak on behalf of the overall community, or at least in any official capacity. This may be true in some areas, but not necessarily for all, which is what the EOSC needs to cover. Again, the EOSC should start simple and evolve over time, therefore the EOSC Service Catalogue could allow for the option within the service description template to specify the community governance endorsement of said service.
Integrated community services into the EOSC might be easier in this regard as they would only need to interface with the EOSC Service Portfolio Management process with the community service representative(s).
Author(s)
Sy Holsinger, EGI Foundation
