Service name
(SDTP)

The page title should use the following
format "Service name (SDTP)"

Document Control

Author

Lead author and
main person responsible for the SDTP

Document status

DRAFT

CHANGED REQUESTED

READY FOR SSB
REVIEW

READY FOR COUNCIL
REVIEW

APPROVED

REJECTED

SSB approval date

EGI Council approval date

Date the SDTP was approved

Change log

Track/describe all major changes made
to the SDTP

Change
log for the template

25.11.2016: Added
"service options" and "service requests"; changed all
instructional text into normal text

Section 1

Value Proposition Design

Customer
/ User Profile

(Potential) Customer of the service

A customer commissions the service
provider to receive the service, doing so on behalf of a number of users (see
below) – specify the organisation type/category of
the service e.g. NGI; RI; Resource Provider

(Potential) User of the service

Specify the user type/category of the
service e.g. large research groups; individual researcher; site admins

User profile

(pains/gains)

Describe the situation without the new
or changed service, including potential pain points the service is intended
to resolve or unexploited opportunities for the customer(s)

Service
Overview

Service Name

Clear, short name of service

Service
Phase

Phase of the service design selected
among:

- discovery: researching users needs,
exploring technological or policy constraints

- alpha: service prototype is available
for closed set of users

- beta: service being developed while
available for testing publicly

- production: service available in the
live environment meeting security/performance requirements

- retired: service is not anymore offered

*Note: services in beta and production
phase are live and can be part of the service catalogue (see the page Service Phases for more information)

General description

Provide a high-level description of
what the service does and functionality included

i.e. Grid Compute: A service that allows to run computational
tasks on high quality IT resources, accessible via a uniform/standard
interface and supporting authentication/authorisation
based on a membership within a virtual organisation.
Grid Compute services are federated together from hundreds of providers
across Europe and beyond offering seamless access to computing capabilities
with integrated monitoring and accounting

Value Proposition

(pain relievers / gain creators)

Describe how the new or changed
service alleviates specific user pains and/or supports its intended
customer(s) to exploit new opportunities

EGI Strategy [1]

Describe how this aligns to the EGI
strategy (provide specific reference(s) to the document e.g. page, section
numbers)

Success criteria

Objective

Indicator

Description

Target

Define one or more strategic
objectives for this service

Name of the performance indicator(s)
used to measure the progress towards the objective

Short description of the indicator and
of how it will be measured

Target value for the chosen
indicator(s)

* Success criteria are defined with
the objectives and may be quantified by performance indicators

Section 2

Business Case Design

The following business case has been
developed to support informed decision-making with respect to the extension
or change of the service portfolio from a strategic perspective

Best case

Average case

Worst case

Demand assessment

Describe what is the full market
potential (all user types / categories and size) and most likely uptake
possible

Describe somewhere between the best
and worst case scenario

Describe the minimal uptake of the
service e.g. only by EGI federation; 1 user group

Assumptions

(about market uptake)

What assumptions need to be made to
expect the best case scenario e.g. EC policy supports it; no commercial
alternative; high user friendliness will equal mass uptake

What assumptions need to be made to
expect the average case scenario e.g. requested by multiple user groups
ensuring some uptake

What assumptions need to be made to
expect the worst case scenario e.g. service design is high quality and will
be supported at least internally

Expected organisational
impact on the service provider

In the best case scenario, what organisation changes would need to be made to support the
demand e.g. additional staff, expanded data centre,
no impact

In the average case scenario, what organisation changes would need to be made to support the
demand e.g. additional staff, expanded data centre,
no impact

In the worst case scenario, what organisation changes would need to be made to support the
demand e.g. additional training of staff, no impact

Expected Cost

Provide an estimate of the resources
required to develop (CAPEX) and maintain / operate (OPEX) the service in the
best case e.g. human effort; financial investment

Provide an estimate of the resources
required to develop (CAPEX) and maintain / operate (OPEX) the average case
e.g. human effort; financial investment

Provide an estimate of the resources
required to develop (CAPEX) and maintain / operate (OPEX) the worst case e.g.
human effort; financial investment

Expected Revenue

What revenue types will the provider
obtain in return for the investment described above and possible estimates
e.g. direct payment(s); funding; in-kind contribution

What revenue types will the provider
obtain in return for the investment described above and possible estimates
e.g. direct payment(s); funding; in-kind contribution

What revenue types will the provider
obtain in return for the investment described above and possible estimates
e.g. direct payment(s); funding; in-kind contribution

Risks

What are the organisational,
technical, financial, market and/or legal risks associated to the service
provider e.g. inability to scale to demand

What are the organisational,
technical, financial, market and/or legal risks associated to the service
provider e.g. competitor offers better / cheaper service

What are the organisational,
technical, financial, market and/or legal risks associated to the service
provider e.g. technology is not mature and stable enough to deliver required
customer levels

Supplier Evaluation

If any supplier(s), whether of
potential service components and/or technology, will be needed or have been
identified, describe the rationale and technical evaluation to ensure the
service can/will be supported

Constraints / limiting factors

Describe the factors that may limit or
hold back the success of the service e.g. size of the market; demand in the
market; availability of supply; competition; availability of finances;
quality and skills of employees

Access Policy [2]

Select at least 1 of the following 3
access policies the service can be accessed through; if more than one apply,
specify the scenario:

Policy-based: users are granted
access to the service based on policies defined by the EGI service
provider(s) or by EGI.eu

Wide access: users can freely
access the service provided

Market-driven: users can
negotiate a fee to access the service either directly with the EGI
service provider or indirectly with EGI.eu

Note: services allowing access to
rival services (e.g. computing capacity or storage) are usually provided
under as policy- or market-driven; services allowing access to non-rival
services (e.g. software packages or scientific data) are usually provided
under a wide access policy

Section 3

Service Design

The following aspects must be defined
comprising the service requirements, the service architecture (both
high-level and technical) and the service acceptance criteria

Following, the results of the service requirements analysis:

Service
Requirements

Category

Requirements

Weight

(1-10)

Functional and technical service
requirements

Availability, continuity and
performance-related service requirements

Security and data
protection-related service requirements

Usability-related service
requirements

Organisational service requirements

Service
architecture

The
service architecture provides an overview of the key (logical) service
components and their dependencies to help better understand the structure and
logical as well as technical setup of the service.

High-level
service architecture

These sections describe how the service is built. A service component is a
logical part of a service that provides a function enabling or enhancing a
service. A service is usually composed of several service components. A
service component is usually built from one or more configuration items (CIs).Although a service component underlies one or more
services, it usually does not create value for a customer alone and is
therefore not a service by itself.

Service
components

#

Type

Description

TRL[1]

1

Choose: Enabling or Enhancing

Definitions:

Enabling service components
are the minimum set of service components that make the service
available

Enhancing service components
are any additional service components that improves the service,
however, the service would still run without them, even if at lesser
quality.

2

Add rows as
required

Integration
and dependencies

Insert a
description and/or visualisation (figure) of the
dependencies between the identified service components

Technical
service architecture

Describe the technical service
architecture, taking into consideration the following perspectives:

• Environmental architecture

• Network infrastructure

• Hardware

• Software / applications

• Information

Service acceptance
criteria

The service
acceptance criteria are based on the results from the requirements analysis
and listed in the following table:

Category

Acceptance criteria

Critical

(Yes/No)

Functional and technical
acceptance criteria

- Functionality to be effectively
provided by the service

- Other

Availability, continuity and
performance-related acceptance criteria

Security and data
protection-related acceptance criteria

Usability-related acceptance
criteria

Organisational acceptance criteria

- Criteria for effective communication

- Criteria for effective user or support
staff training

Critical acceptance
criteria indicators

Critical acceptance
criteria according to the above table are regarded as show-stoppers.
That means that, if any of the critical acceptance criteria is not achieved,
the deployment of the service to the live environment will be delayed.

Number of unachieved
critical acceptance criteria preventing deployment

[insert
number]

Number of
unachieved non-critical acceptance criteria preventing deployment

[insert
number]

Service
Options

Service options are
possible choices that the customer can/should specify when commissioning the
service

(e.g. for the service "cloud
compute", the customer can specify the type of virtual machine with the
number of cores, RAM; for the service "FitSM
training" the customer should specify the level of the training and if
he/she wants a certification)

#

Name

Description

Attributes

1

Add a name for this
option

Add a description
for this option; this description is targeted to potential customers

who need to understand what each option
is about and being able to choose the best for their needs

Add attributes as numbered bullet
lists in the form of :

1. attribute
name: [possible values]

2. attribute
name: [possible values] ...

2

3

Service
Requests

Service requests
are user request for information, advice, access to a service; please specify
the list of service requests that will be supported during the provision of
this service

(e.g., provide general information and
advice, change password, increase capacity)

#

Name

Description

1

2

Section 4

Service Transition
Plan

The following table
provides the service transition plan for the new or changed service that
services as the action plan regarding all activities to be carried out

Phase

Activities and timing

Responsibilities (RACI)

Links/References to other documents

Specification, negotiation and
agreement

e.g. complete service portfolio entry template

Development and procurement

Testing

e.g. carry out assessment of service acceptance
criteria

Operation with early life support

Regular operation

[1] http://go.egi.eu/strategy2020

[2] https://www.egi.eu/access-policy/

[3] Technology Readiness Levels (TRL) are a method of estimating technology maturity of components
during the acquisition process. For non-technical components, you can specify “n/a”. For technical components, you
can select them based on the following definition from the EC:

TRL 1 – basic principles observed

TRL 2 – technology concept formulated

TRL 3 – experimental proof of concept

TRL 4 – technology validated in lab

TRL 5 – technology validated in relevant environment
(industrially relevant environment in the case of key enabling
technologies)

TRL 6 – technology demonstrated in relevant environment
(industrially relevant environment in the case of key enabling
technologies)

TRL 7 – system prototype demonstration in operational
environment

TRL 8 – system complete and qualified

TRL 9 – actual system proven in operational environment
(competitive manufacturing in the case of key enabling technologies)