VI-SEEM Service catalog service enablers guide

From VI-SEEM Wiki
Jump to: navigation, search

VI-SEEM service catalog/portfolio

The VI-SEEM catalog/portfolio management system currently allows two different data entry procedures: via the RESTful API or via the temporary service administration tool (SPMT WRITE DJANGO UI). The third way to enter data will be the write UI, which is in the final phase of the development. In this text, the data entry through the temporary service administration tool will be described. SPMT implements the service portfolio and catalogue that has been described in VI-SEEM D3.2: “Service registry, operational and service level monitoring”. The SPMT READ user interfaces are available under the following links:

The Service Administration interface (SMPT WRITE UI) can be access via https://services.vi-seem.eu/api/admin

Authentication and Authorization

Authentication to the SPMT WRITE UI is handled via VI-SEEM AAI. Anyone with a VI-SEEM AAI account can create an account in the SPMT WRITE UI. However, access rights deny any write operation in the SPMT.

Authorization in SPMT is handled via the tool itself. A user has access rights to the tables of the SPMT database only if it is authenticated by the SPMT WRITE UI administrator. In V1 of the SPMT WRITE UI every user account that is registered as service owner will have write permission to all data of existing services, as well as the right to create new services. In future versions of the tool fine great authorization will prevent a service owner from editing services that do not belong to him.

Picture1.png

Figure 1 - The SPMT Admin interface dashboard.

Creating a new service

To create a new service, the admin must click on the “Service” left menu option.  A list of existing services is presented. By selecting an existing service one can edit the details of such a service. To create a new service, the admin clicks on “Add Service”, as shown in Figure 2.

Picture2.png

Figure 2 - The services page The new service (and edit service) page provides a way for the admin to enter the main service details, Figure 3.

Picture3.png

Figure 3 - The main service description interface Follows a description of the information that should be provided.

  • Name: Should be descriptive from a customer point of view, and should be quite simple, such that someone non-technical has a chance of understanding what the service is.
  • Description External: Should be similar to the name describe above, and consider the value provided by the service, in fairly non-technical terms. These descriptions will be needed for the Service Catalogue, which will be shown to users and customers. HTML is allowed here for formatting purposes.
  • Description Internal: Should be similar to the name describe above, and consider the value provided by the service, in fairly non-technical terms. These descriptions may seem obvious but help everyone within the organization understand the service. HTML is allowed here for formatting purposes.
  • Service Area: If an organization provides multiple services, they are likely to want to categorize them in various ways. These can be internal classifications (perhaps related to departments, or physical locations) or external ones that are of interest to a customer. In VI-SEEM it should have one of the following values:
    • Data Storage
    • Data Discovery
    • Compute
    • Application specific
    • Authentication and authorization
    • Service provisioning

The service area is a string. The values must be accurately set as one of the strings above to avoid creating more service areas than necessary.  

  • Service Type: Customer-facing service or supporting service. A customer-facing service is an IT service that is visible to the customer. Typical data to be recorded are those connecting to the community, although information from the supporting layer can be recorded as well for internal use by the IT service provider. A supporting service is an IT service that is not directly used by the community, but is required by the VI-SEEM as a service provider to deliver customer facing services (for example, a directory service or a backup service). Supporting services may also include IT services only used by the VI-SEEM as a service provider. In VI-SEEM it should have one of the following values.
    • Customer facing service
    • Supporting Service
  • Request procedures: Describe how the service should be requested by a new client. This field accept HTML in order for the admin to be able to add a button and make the field actionable.
  • Funders for service: What is the broad model for funding this service: pay per use, subscription, indirect funding (EC, State funding) etc.
  • Value to customer: Value to customer should capture what needs this service meets on the customer side. Why is it beneficial for them? What problems does it solve? Why is it the best solution for them? This supports marketing and promotion of the service.
  • Risks: While many risks can be thought of, here you should list the major ones. For a paid service, this may be lack of customers willing to pay. For an indirectly funded service, not being able to meet the promises made to the funding body. Here it is important to consider the bigger picture with regards to the service and the service provider. Understanding the risks allows them to be balanced against benefits, and lets the service provider understand which services it is beneficial to offer.
  • Competitors: While it is important to define yourself based on your value proposition, it is always necessary to consider competing services. Even if your solution is better and cheaper, perhaps the cost for customers to switch from the market leader to you is too high.
  • Service Owner: This is the individual who has accountability for the whole service, from a management point of view. He will have an understanding of the service from technology through to user, and maintain an overview of the effectiveness and success of the service. The user can select one of the existing service owners or creating a new one by pressing the “+” button.
  • Contact Information: Contact details for the customer, either the service owner or a general contact point. The user can select one of the existing service owners or creating a new one by pressing the “+” button.  
  • Contact Information internal: A contact person within the organization must be assigned for communications, questions and issues relating to the service. At first it may be the personal contact information of the Service Owner, and this may be sufficient in small organizations, but it is preferable to move toward a more generic email contact such as owner.servicename@companyname.com.
  • Logo: A PNG image to be used a the logo for that service  

Adding all this information the user completes the registration of the main service information. Up to now the service is created in the SPMT but it is only available in the service portfolio and not the service catalogue. To view the services in the service portfolio the user can visit the following URL: https://services.vi-seem.eu/ui/portfolio/services/

Adding Service Versions (also named Service Details)

All services registered in the service portfolio must have at least one version code associated with them. Service versions might be in one of the following Statuses based on the “Status” parameter: New, Approved, Under Development, Pre-production, Active, To be Retired, Retired. A service becomes part of the service catalogue when at least one version of it is “Active” and the “Is in catalogue” flag is set to true. Figure 4 shows a screenshot of the “Service Version” page where the list of “service” / “version”.

Picture4.png

Figure 4 - The Service Versions catalogue

Service versions can be added by the “Add Service Details” button. Figure 5 displays the edit / add “Service Details” thus a new Version for a service.

Picture5.png

Figure 5 - Adding the service details Follows a description of the information that should be provided.

  • Id Service: The name (unique) of the service that this version corresponds to
  • Version: The name of the version i.e. 1.0, 2.1.3
  • Status: One of the following: New, Approved, Under Development, Pre-production, Active, To be Retired, Retired
  • Features Current: Briefly outline the main current features and functionalities of the service. The field accepts HTML values for better formatting.
  • Feature Future: Briefly outline the main future features and functionalities of the service. The field accepts HTML values for better formatting.
  • Usage policy has: Each service listed in the SP needs to have a corresponding usage policy
  • Usage policy URL: The URL that the usage policy is located
  • User documentation has: Each service listed in the SP needs to have a corresponding user documentation
  • User Documentation URL: The corresponding URL
  • Operations documentation has: Each service listed in the SP needs to have corresponding operation documentation.
  • Operations documentation URL: The corresponding URL
  • Monitoring has: Each service listed in the SP needs to be linked with the monitoring system so that it is appropriately monitored
  • Monitoring URL: The corresponding URL
  • Accounting has: Each service listed in the SP needs to have a proper accounting of its usage that is propagated to the central accounting service.
  • Accounting URL: The corresponding URL
  • Business continuity plan has: Each service in the SP needs to have a business continuity plan associated with it.
  • Business continuity plan URL: The corresponding URL
  • Disaster recovery plan has: Each service in the SP needs to have a tested disaster recovery plan.
  • Disaster recovery plan URL: The corresponding URL
  • Decommissioning procedure has: Each service in the SP needs to have a decommissioning procedure
  • Decommissioning procedure URL: The corresponding URL
  • Cost to run: How much does it cost (estimate) to provide this service in a suitable unit, such as €/core hour, €/TB stored or transferred, €/hour of consulting.
  • Cost to build:  How much does it cost (estimate) to provide this service in a suitable unit, such as €/core hour, €/TB stored or transferred, €/hour of consulting.
  • Use cases: Briefly outline a collection of possible scenarios related to the service which allow fulfilling the customer requirements.
  • Is in catalogue: True if this service version should also appear in the service catalogue as well, instead of the service portfolio only.

Internal Dependencies

In some cases, a service may be built up not only from components, but also from whole other services combined with additional components. In this case there is a dependency between one service and another, and it makes more sense to list the dependency on the other service as a whole rather than simply the components within it. Dependencies can be internal services but also external services operated by other organizations.

External Services and External Dependencies

These two fields are not used at the current implementation of the Service Management process.

Service Areas

Service areas as described in the section of the Service Description can take predefined values such as:

  • Data Storage
  • Data Discovery
  • Compute
  • Application specific
  • Authentication and authorization
  • Service provisioning

The STMP admin interface is used to define new service areas or assign an icon to existing ones. The icon is used in the READ UI if of the SPMT to preset the services in different categories. See: https://services.vi-seem.eu/ui/catalogue/services/

Picture6.png

Figure 6 - The Service Area creation UI.

Users Customers of the service

Which group will use and benefit the value provided by the service, e.g. in the academic domain they may not pay for it but they are the main beneficiaries. Each service might be used by multiple type of users or customers.

Picture7.png

Figure 7 - The list of Users / Customers for all the registered services of VI-SEEM


Picture8.png

Figure 8 - The Users / Customers of a service WRITE interface. There are 4 types of users / customers of a service. These are:

  • Individual researchers
  • Community Managers
  • Service Providers
  • Data Project Principle Investigator (PI)

If any of those types are users of a service, then the service owners has to declare it and also add some information related to the role or the benefits that this service plays for specified service. Then the service name (id) needs to be added in order for the user / customer to be associated with a specific service.

Components

Core Service building blocks (components, activities etc.): The building blocks that make up the core service (minimum set of components or standard set). They can also be collections of the core components with different sets of additional components that are offered to customers. For example, there may be a base package called ‘storage’ and an enhanced package called ‘versioned storage’, directory service etc. Service components have a Name i.e. Relational Database, a Description and a file representing the service component logo. Service components might be common for different services.

Picture9.png

Figure 9 - The service component creation UI

Service component Implementation

The service component implementation corresponds to the technical implementation of a service components. For example, for a relational database a possible implementation is the MySQL or PostgreSQL databases.

Picture10.png

Figure 10 - Service components implementations To insert a new service component implementation, the user needs to enter the following details

  • Component Id: The corresponding service component
  • Name: The name of the service component
  • Description: The description of the service component implementation

The following figure shows an example of a service component implementation detail.


Picture11.png

Figure 11 - The service component implementation information

Service component implementation Details (Version)

The service component implementation details provides information on the specific version of a service component. Figure 12 show the information needed for the service component implementation details


Picture13.png

Figure 12 - Service component implementation details

Service Components Implementations Details Link

Finally, the user must link a specific version of a service component implementation version with a service version. This is done via the “Service Components Implementations Details Link” view. Figure 13 shows how we can link Service VI-SEEM Login version 1.0.0 with PostgreSQL version 9.4.6


Picture13.png

Figure 13 - The Service Components Implementations Details Link view

Service owners and contact information

A service owner is the individual who has accountability for the whole service, from a management point of view.

Contact information (internal): A contact person within the organization must be assigned for communications, questions and issues relating to the service. At first it may be the personal contact information of the Service Owner, and this may be sufficient in small organizations, but it is preferable to move toward a more generic email contact such as owner.servicename@companyname.com.

Contact information (external): Contact details for the customer, either the service owner or a general contact point. Each service needs to be associated with a service owner and have internal and external contact information. External contact information is shown in the service catalogue as well as the service portfolio.  Service owner and internal contact information is only shown in the service portfolio.