26th Annual INCOSE International Symposium (IS 2016)

Edinburgh, Scotland, UK, July 18-21, 2016

Understanding Services: Understanding

Stakeholders

Stephen J Ashlin Iain Cardow

QinetiQ Rolls-Royce plc
sjashlin@qinetiq.com iain.cardow@rolls-royce.com

Alan Crawford John K Davies

Babcock International Group University of Leeds
alan.crawford@babcockinternational.com j.k.davies@leeds.ac.uk

Andrew Farncombe Peter Mason

Welwyn Business Services
andrew@farncombe01.demon.co.uk peter.mason@welwynbusinessservices.co.uk

Copyright © 2016 by S J Ashlin, I Cardow, A L Crawford, J K Davies, A Farncombe, P Mason. Published and used by INCOSE with
permission.

Abstract. There are many different services in general use today. New ones are being devel-
oped driven by the move from customers owning equipment to it being provided by suppliers
as a service. We all know what services are, we use them every day. All the systems we de-
velop and deliver end up providing or supporting some sort of service. The aim of the INCOSE
UK Service Systems Engineering Working Group is to identify areas of the engineering
lifecycle, the methods, and the techniques that need to be different for engineering services as
opposed to ‘traditional systems engineering’ for the engineering of products.
When INCOSE was formed there were various definitions of ‘What is a System?’ it took time
to sort out but now is not normally an issue. Today established standards; SEBOK, DoDAF,
MoDAF, Open Group, ITIL, CMMI; have different definitions of a Service. These differences
are not just differences in wording driven by stakeholder views that can lead to significant
differences of what is expected in delivering services. To understand and successfully deliver
services, we need to understand and relate such definitions, and then use them within our en-
gineering of services.
In this work we have used Case Studies for Services that cover various areas of interest for
businesses in INCOSE UK and used them to establish the scope of our work. The use of the
term ‘Service’ has been extracted from literature together with definitions. The definitions
have been grouped, related and where necessary re-worded to provide a map of terms and the
various definitions extracted from literature understood using this map.
The use of Service Oriented Architecture (SOA) outside the IT Sector has been considered,
along with previous work in this area, as the architecture for understanding Services. We have
illustrated this through simple application to one of the case studies. This is a different but
complementary approach to understanding services and work with further case studies is
needed to understand how it can best be applied.
 Introduction
The INCOSE UK Service Systems Engineering Working Group is working to identify areas of
the engineering lifecycle, methods, techniques that need to be different for delivering services
as opposed to ‘traditional systems engineering’ for delivering products. Currently there are
many definitions of ‘What is a Service?’ Wikipedia alone has listed over sixty of them.
(Wikipedia 2016)
In this paper we have identified definitions that can be applied in engineering, analysed the
differences and used them to harmonise knowledge about services, so that parties using dif-
ferent definitions can recognise each other’s view. The definitions have then been mapped to a
framework based on Service Oriented Architecture (SOA) that covers the elements of services.
Further work is being carried out to address the diversity of services by identifying services
with common characteristics such that the same processes, methods and tools will be needed to
support their engineering.
Previous work has looked into a number of areas for engineering services. Garnier (Garnier et
al. 2013) as part of an AFIS initiative (AFIS 2016) has looked into the engineering of services,
starting with the various definitions of ‘Service’ found in the literature, and continued in this
paper.
In addition, they have looked at some areas of Service Oriented Architecture (SOA 2007) and
how it can be applied to case studies. Lui (Liu et al. 2009) and Webster (Webster et al. 2011),
as part of the NECTISE programme involving BAE Systems and University of Leeds, looked
into the provision of Network Enabled Capability (NEC) by the integration of services archi-
tected using SOA, and the migration of legacy assets to a SOA-based System of Systems in
order to re-use their functionality and information content.
The work reported in this paper is aimed at providing understanding that services can be
characterised to enable the grouping of those that require similar engineering, to point out that
various definitions of service exist, clarify ‘What is a Service?’ and illustrate the use of Service
Oriented Architecture for services outside the IT sector.

Approach
The general approach to this work is illustrated in Figure 1 and detailed in the Engineering Plan.
(Ashlin 2014)

Figure 1. General Approach to this work

The literature search was carried out using Google Scholar (Google 2016) and the facilities of
the University of Leeds library (Leeds 2016) these were then compared with Systems Engi-
neering Standards, the work of AFIS (Garnier et al. 2013) and the Cambridge Service Alliance
(Cambridge 2016) and relevant papers added. In particular, the Cambridge Service Alliance
(Benedettini and Neely 2015) carried out a Literature Search of four databases which yielded
26,989 hits which they then whittled down to 127 papers concerned with Complexity in Ser-
vices.

Workshops were held at the Service Systems Engineering Working Group (INCOSE UK
2012) and at the UK Annual Systems Engineering Conference 2013. (INCOSE UK 2013)
Case Studies have been taken from member companies of INCOSE UK, (INCOSE UKAB
2012), member companies of the Yorkshire Computing Network (YCN 2015), and published
documents from the Cambridge Services Alliance (Cambridge 2016)
The eight case studies that have been used are:

 Rail Transport

 Electric Car Rental

 Transport for London Cycle Scheme

 Building Energy Management

 Provision of Military Test, Evaluation & Training Services

 Rapid Acquisition of Manufactured Parts

 UK Government IT – G-Cloud/Digital Marketplace

 Digital Post Production Services

These range across the areas of interest to the businesses within the INCOSE UK, spanning the
Transport, Energy, Defence, Government, IT and Entertainment sectors. They provide diver-
sity in the purpose and nature of the service provided, the way in which they are described and
the processes, methods, tools and technology used to engineer them. They have been used as a
set of exemplars to check the work as it has progressed.
Characteristics of services have been captured from workshops, literature and the Case Studies.
The characterisation has been used to group services that are similar as it is felt likely that these
will benefit from the same engineering approach. However, this is yet to be tested.
The literature search, case studies and workshops identified that there are different definitions
and consequent assumptions about services from the varied sources. These differences are not
just in the wording but more about what was a service: for example, was it the equipment and
processes that provided the service, or was it an abstract concept that was not concerned with
how the service was provided. Different stakeholders will have different concerns about a
service resulting in differences depending on who has defined the term ‘service’.
The range of definitions has been used to identify different aspects of service and produce a
map of service concepts. This can be used to understand why there are different definitions and
which stakeholders will focus on different aspects.
 Characterising Services
To provide guidance on the engineering of new services, or the migration of businesses from
being product-oriented to being service-oriented, ways of grouping services that would require
the same engineering have been considered. Guidance can then be provided for each group.
Effort has been directed to identifying methods by which Service and Service Systems may be
characterised. The case studies, literature searches and workshops have been held to gather the
most important characteristics of services from the perspective of INCOSE members. These
characteristics have been grouped under three headings: Management; Stakeholders and
Technical and according to their complexity and dependence on products to deliver the service,
as well as measures such as the number and type of stakeholders involved in the consumption
and delivery of the service.
Existing methods from literature, e.g. (Tukker, A. 2004), (Cambridge 2016), have also been
identified. Figure 2, adapted from (Tukker, A. 2004), illustrates eight categories of Service and
how they range from pure product to pure service. The Case Studies have been characterised
according to these parameters and the most useful will be used to develop guidance for the
engineering of services.
Service Complexity is a similar concept to system complexity and caused by the interaction
with different services or between services and products. Where there is high complexity and
multiple interactions between services, then the service becomes less predictable.

What is different about a service?

Existing work covered in the literature has focussed on Product-Service Systems, PSS, (Meir,
Roy and Seliger 2010) considers systems to consist of both Products and Services and any
system is expected to lie somewhere along the continuum between pure product and pure
service.
Figure 2 Product-Service Systems: Product and Service Content

This is illustrated in Figure 2. For Product Oriented systems the main concern is the tangible
product. Service rich systems are Results Oriented and their content may be intangible. The
main concern with these systems is that they produce the result but the means by which they do
that is not of concern. Between these two extremes are Use Oriented systems, where the use of
the system is important which concerns both the output and how it is produced.
Examples of such systems can be seen with automobiles. Purchase and ownership is Product
Oriented with the focus on the automobile. Renting an automobile is Use Oriented, as the
person renting the automobile also needs to drive the vehicle so needs to be comfortable and
confident to do that. Using a taxi is Result Oriented, the customer is not interested in the ve-
hicle, provided it does the job.
The three most commonly ascribed characteristics of service are (MacDonald and Payne 2006)
 Intangibility, services usually are intangible while products generally are concrete.
 Uno-actu-principle, services are produced and consumed at the same time hence they
cannot be stored. Whereas products exist over time and can be stored.
 Integration of external factors, a direct contact between the service provider and the
consumers is fundamental. Whereas products are traditionally delivered by the de-
veloper and transferred to the user prior to the in-service phase of the lifecycle, services
are provided by the supplier to the consumer when they are needed.
In terms of the automobile example, a taxi ride is intangible whereas a purchased automobile is
a tangible product. A taxi ride only exists for a short time and cannot be stored. There is direct
contact between the service provider, the taxi and the passenger; whereas if you buy an au-
tomobile you hope it only needs to go back for a check up on an occasional basis.

Existing Service Definitions

Various definitions of Service are used within business and within engineering. Definitions
extracted from standard sources as shown in Table 1.
Table 1: Definitions of Service from Standard Sources

Business Area Definition Source

Economics In economics, a service is an intangible commodity. That is, (Wikipedia

services are an example of intangible economic goods. 2016)

Capability A product that is intangible and non-storable. (CMMI

Maturity 2013)

Computer En- A logical representation of a repeatable business activity (Open Group

gineering that has a specified outcome. 2009)

Service Ori- The IT realisation of some self-contained business func- (SOA 2007)
ented Archi- tionality. Technically, a service is a description of one or
tectures more operations that use (multiple) messages to exchange
data between a provider and a consumer.

UK Defence Services are an implementation-independent specification MoDAF

of a packaged element of functionality. (2012)

Systems Engi- An activity required by one or more users who have agreed (BKCASE
neering on the terms of outcomes and quality of service without 2015)
details to how it is provided.
US Defense A mechanism to enable access to a set of one or more ca- (DoDAF
pabilities. 2011)

The INCOSE Systems Engineering Handbook (INCOSE 2015) does not define ‘Service’ but
uses the term in the definition of Project, System and System Element and extensively through
the text, frequently in the form ‘products and services’. The Cambridge Service Alliance
(Cambridge 2016) uses the term in many forms throughout its publications mostly with regard
to the ‘Servitisation’ of firms who outsource their manufacturing. SOA and MoDAF define
services in terms of providing a specification of packaged functionality. The SEBOK provides
a definition that is also similar to that for a system but where the detail of how the service is
provided is removed. DoDAF has a similar view but refers to service as a wrapper around a
capability rather than including the capability itself.

Understanding Services – the Service Definition Map

In general, these definitions enunciate what a Service is from different stakeholder viewpoints,
but none of them provide a definition that can be used in all cases. A single definition of
‘Service’ would be so general it would be largely meaningless. We have therefore chosen to
provide a series of definitions that cover aspects of Services and link them together in a Service
Definition Map.

Figure 2: Service Definition Map

The Service Definition Map consists of a series of definitions that cover aspects of Services.
and links them together similar to an Entity Relationship Diagram. To do this, existing
standards were considered that provided a series of relevant definitions, e.g. CMMI for Ser-
vices (CMMI 2013)
The resulting map is shown in Figure 1. Note that this shows definitions relating to Service,
they are not a breakdown of Service or different views of service that generally reflect the
stakeholder’s role in the Service. They fall into five areas: the intangible commodity within
CMMI and economics; the Contract, where the Service Level Agreement is the prominent
vehicle; the Specification; the Provision, normally referred to as the Service System, used in
general standards, INCOSE Handbook, and SOA; and the Operation which covers the use and
service support, covered by standards such as ITIL (ITIL 2011).
This is summarised in Table 2.
Table 2: Where different definitions are used

Type Used for definition in Focus

Intangible CMMI, Economics General reference with no main focus

Contract Focus on the use of Service Level Agreements

SLA. Normally together with the Specifica-
tion

Specification Computer Engineering Focus on defining what the Service does

Service Oriented Architectures

UK Defence

Provision US Defense Focus that the service is provided – often by

wrapping functionality

Operation ITIL Focus on how the service is provided and

managed

The Service Definition Map enables stakeholders to share understanding and avoid misun-
derstanding. Further work is needed to test it in detail using the Case Studies and provide
general guidance for its use.

Using Service Oriented Architecture Concepts

The Service Definition Map does not provide a generic architecture or structure for a service,
so, following previous authors, we have considered Service Oriented Architecture, SOA,
which is used widely in the IT Sector as to its utility in the wider arena. The layers of SOA,
which form its structure, have been considered with regard to one of our case studies in order to
illustrate and understand its potential use. Further work is needed to test this in the cases of the
other case studies and to extract how it helps general cases of engineering of services.
Service Oriented Architecture (SOA 2007) is a methodology widely accepted for the provision
of IT and based on a pay-as-you-go concept for the provision of services. Previous work at
University of Leeds and BAE Systems (Liu et al. 2009), (Webster et al. 2011), has looked at the
use of services to provide Network Enabled Capability based on SOA and work in AFIS
(Garnier et al. 2013) has taken some aspects of SOA and related them to three cases studies to
illustrate the use of services. In this paper, the Layers of the SOA Reference Architecture are
summarised, their relationship to the Service Definition Map considered, and an example of
how the layers can be understood in terms of one of the case studies is presented.

Figure 3: SOA Reference Architecture

Figure 3 shows the SOA Reference Architecture viewed as five horizontal layers:
1. Consumer Interfaces – is where consumers interact with the SOA these can be other
systems, other SOAs, cloud service consumers, human users, etc. This decoupling
between the consumer and the rest of the underlying SOA provides organisations with
the ability to support agility, enhanced re-use, and improve quality and consistency.
2. Business Processes – covers the way services are used and support business use-cases,
normally through the integration of a number of services.
3. Services – consists of all the services defined within the SOA. This layer can be
thought of as containing the service descriptions for business capabilities and services
as well as their manifestation during design time, as well as service contract and de-
scriptions that will be used at runtime.
4. Service Components – contains components, each of which provides the implemen-
tation or ‘realisation’ for services and their operations. The layer also contains the
Functional and Technical Components that facilitate a Service Component to realise
one or more services. Service Components reflect the definition of the service they
represent, both in terms of functionality and Quality of Service (QoS).
5. Operational Systems - describes the deployment infrastructure; the programs, plat-
forms, application servers, containers, runtime environments, packaged applications,
virtual machines, etc. that are on the hardware and are needed to support the SOA so-
lution.
The lower layers (Services Layer, Service Component Layer, and Operational Systems Layer)
are concerns for the provider and the upper ones (Services Layer, Business Process Layer, and
Consumer Layer) are concerns for the consumer.
In addition, there are cross-cutting vertical columns covering:
1. Integration – provides the capability to mediate which includes transformation, rout-
ing, and protocol conversion to transport service requests from the service requester to
the correct service provider.
2. Quality of Service – Monitoring and management both at the business level in terms of
Key Performance Indicators (KPIs), and at the IT systems level for the security, health,
and wellbeing of systems, services, applications, networks, storage, and servers.
3. Information – providing a unified representation of the information aspect of an or-
ganisation as provided by its IT services, applications, and systems enabling business
needs and processes.
4. Governance – ensures that the services and SOA solutions within an organisation
accord with the defined policies, guidelines, and standards.
The layers of SOA Reference Architecture have been compared to the Service Definitions
shown in Table 3, together with an example of how the layers could be used for rail transport
service to travel from London to Edinburgh. Some of the Service Definitions can be clearly
related SOA Layers, however, there is not a good one-to-one coverage. This can be expected
as the Service Definitions do not provide an architecture of Services which SOA does.
Table 3: SOA Reference Architecture: Relationship and Example Use

SOA Layer Rail Travel from London to Edinburgh Relationship to Service

Definitions

Consumer In- The on-line booking system used on a lap-top, Service User
terface smartphone or other device.

Business Pro- The linked-up set of transport services for the Service Use
cess end-to-end journey

Services The Underground, Train and Bus Services you decide Service Specification
to use. (or alternatively Taxi, Air and Tram Services)

Service Com- Stations, networks, trains, buses, etc. Service Components

ponents

Operational The actual trains and buses you travel on and the Instances of the Service
Systems tracks, stations and platforms you pass through. Systems

Integration Physical and timely linking between the Underground, Service Interface
Trains and Buses.

Quality of Ser- Performance of the Underground, Trains and Buses, Service Level
vice punctuality, safety, etc.

Information Published timetables and routes, plus current status Partly covered by Ser-
that enable you to find the best routes and trains. vice Specification

Governance Policies, guidelines, standards for the different ser- Service Agreement
vices.
A simple SOA Architecture Diagram for this example is shown in Figure 4. The Business
Process shows the overall activity being supported by the services. This then links to the
Services which are provided by Service Components and physically by Operational Systems.

Figure 4: Example SOA Architecture

Results
Services can be characterised according to their complexity, dependence on products, the
stakeholders involved, and other factors. Methods of characterisation of services have been
identified and are being used to group services that will require similar approaches. Existing
definitions of Service from standard reference documents have been analysed and a Service
Definition Map produced which enables understanding of why different definitions are used by
different stakeholders, and where different artefacts of services are related. The SOA Refer-
ence Architecture used in the IT Sector has been summarised and its application to more
general services considered through a simple example of arranging travel by public transport.
Further work will be carried out to fully harmonise the definitions, mature the Services Defi-
nitions Map and architecture, identify services requiring similar engineering approaches, and
develop guidance.
This paper has provided the understanding that services can be characterised to enable
grouping of those that require similar engineering. It has considered various definitions of
service and clarified ‘What is a Service?’ and provided a map through which other definitions
can be understood. It is not that they are wrong it is just that they are looking at a different
aspect. An illustration of the use of Service Oriented Architecture for services outside the IT
sector has been provided.
Further work is in progress to enable architects and engineers to characterise services, to pub-
lish the Service Definition Map and the definitions of its content, develop guidance for the use
of Service Oriented Architecture, and to publish the Case Studies as exemplars of this work.
 Conclusions
For this paper we asked the questions:

 What is a Service?

 What is different for systems engineering of Services as opposed to Products in terms

of lifecycle, methods and techniques?
We have found seven different definitions of ‘Service’ in use in standards used by systems
engineers which reflect various stakeholders and their areas of business. The Service Defini-
tion Map provides a harmonised set of definitions that allows these various standard definitions
to be understood and related. This map shows the various aspects of services that should be
considered in their engineering. This is a new approach that we see as of great importance for
services but does not exist for the systems engineering of products.
There is no distinct barrier between Products and Service, instead there is a continuum of
Product/Service Systems that range between those where the value is mainly in the product
content, to those where the product is mainly in the Service Content. This indicates that the
systems engineering needed for Products is also needed for Services, however, further con-
siderations are needed for services as seen in the Service Definition Map and the required focus
of effort is likely to be different. For example, for services the emphasis is on the In Service
phase of the lifecycle and the standards used in that area.
An architectural approach for Services is desirable and we have explored the use of Service
Oriented Architecture for services outside the IT sector.

Future work
Further work is needed to develop and publish guidance for the Engineering of Services. The
Service Definition Map and the set of definitions to support it need to be finalised. The use of
ITIL (ITIL 2011) and TOGAF (Open Group 2011) for the development and management of
services need to be further studied and related to the Case Studies. The characterisation of
services needs to be reviewed and issued and the set of Case Studies published.
This work has been carried out by the core team of the INCOSE UK Working Group on Ser-
vice Systems Engineering. The authors thank the other members of the group for their con-
tributions.

References
AFIS - Association Française d'Ingénierie Système. INCOSE French Chapter.
https://www.afis.fr/pages/accueil.aspx
Ashlin, S.J. 2014. INCOSE UK Service Systems Engineering Working Group Plan. 14 May
2014.
Benedettini O and Neely A 2015. Complexity in services: an interpretative framework, Cam-
bridge Service Alliance. http://cambridgeservicealliance.eng.cam.ac.uk/
BKCASE Editorial Board. 2015. The Guide to the Systems Engineering Body of Knowledge
(SEBOK), Fundamentals of Service v. 1.3.2. R.D. Adcock (EIC). Hoboken, NJ: The
Trustees of the Stevens Institute of Technology. Accessed 17 August 2015.
 www.sebokwiki.org. Service Systems Engineering, BKCASE is managed and main-
tained by the Stevens Institute of Technology Systems Engineering Research Center,
the International Council on Systems Engineering, and the Institute of Electrical and
Electronics Engineers Computer Society.
Cambridge Service Alliance 2016. http://cambridgeservicealliance.eng.cam.ac.uk/
CMMI for Services Capability Maturity Model Integrated version 1.3, 2013. Appendix D:
Glossary. cmmiinstitute.com/resources/cmmi-services-version-13
DoDAF 2011 US Department of Defense Architecture Framework. Services Viewpoint.
dodcio.defense.gov/Portals/0/.../DODAF/DoDAF_v2-02_web.pdf
Garnier J-L, Auzelle J-P, Pourcel C, Peyrichon. M. Ingénierie de Services. Génie logiciel, C &
S, 2013, Mars 2013 (104), pp.47-55. <hal-00816280>
Google 2016. Google Scholar https://scholar.google.co.uk/
INCOSE Handbook version 4. 2015 https://www.incose.org/
INCOSE UK 2012. Workshop held at the INCOSE UK Service Systems Engineering Working
Group
http://incoseonline.org.uk/Groups/Service_Systems_Engineering/Main.aspx?CatID=
Groups&SubCat=Service_Systems_Engineering
INCOSE UK 2013. ASEC2013 Annual Systems Engineering Conference 2013,
http://incoseonline.org.uk/Groups/UKChapter/Show_Event_Details.aspx?CatID=Eve
nts&EventID=258&group_type=Special&SubCat=Group
INCOSE UK Advisory Board
http://www.incoseuk.org.uk/Normal_Files/UKAB/UKAB.aspx?CatID=UKAB
ITIL 2011 IT Infrastructure Library for IT Service Management (ITSM)
https://www.axelos.com/glossaries-of-terms
Leeds 2016. University of Leeds library https://library.leeds.ac.uk/
Liu L; Russell, D.; Webster, D.; Luo Z; Venters, C.; Xu J; Davies, J.K., Delivering Sustainable
Capability on Evolutionary Service-oriented Architecture. Ob-
ject/Component/Service-Oriented Real-Time Distributed Computing, 2009. ISORC
'09. IEEE International Symposium, pp.12-19, 17-20 March 2009
MacDonald M, Payne A (2006) Marketing Plans for Service Businesses. A Complete Guide.
2nd Edition. John Wiley Ltd.
Meier H, Roy R, Seliger G. Industrial Product-Service Systems - IPS2. CIRP Annals -
Manufacturing Technology 59 (2010) 607–627
MoDAF:2012. UK Ministry of Defence Architecture Framework. Version 1_2. Service Ori-
ented View Viewpoint. https://www.gov.uk/mod-architecture-framework
Open Group 2009: Service Oriented Architecture Technical Standard.
http://www.opengroup.org/soa/source-book/soa/index.htm
Open Group 2011: TOGAF The Open Group Architecture Framework.
http://pubs.opengroup.org/architecture/togaf9-doc/arch/
SOA 2007. SOA In practice. http://soa-in-practice.com/soa-glossary.html
Tukker, A. 2004. Eight Types Of Product-Service System: Eight Ways To Sustainability? Ex-
periences From Suspronet. Business Strategy and the Environment, 13, 246–260.
doi:10.1002/bse.414
Webster D, Liu L, Russell D, Venters C, Luo Z, Xu J. Migrating Legacy Assets through SOA
to Realise Network Enabled Capability. in New Directions in Web Data Management
1, Studies in Computational Intelligence Volume 331, 2011, pp 311-346, (2011)
isbn={978-3-642-17550-3)
Wikipedia 2016: Service Page: http://en.wikipedia.org/wiki/Service
YCN 2015. Yorkshire Computing Network
http://www.engineering.leeds.ac.uk/computing/research/yorkshire-network/index.sht
ml

Biographies
Stephen Ashlin is a senior Systems Engineer for QinetiQ with experience of applying systems
engineering across the lifecycle including research, acquisition support on a number of military
equipment projects and delivery of major test and evaluation events.
Iain Cardow is a senior Systems Engineer for Rolls-Royce with a background in Development
and Verification engineering. Has experience in applying Systems knowledge across Defence
and Civil Aerospace and Maritime divisions.
Alan Crawford has applied his systems expertise to a variety of engineering domains, most
recently concentrating upon the challenging Defence maritime environment.
John K Davies has worked as a systems engineer and manager in large electronic systems
companies for thirty years and a Visiting Professor at the University of Leeds.
Andrew Farncombe has held senior technical and management posts, including that of
Technical Director, in UK systems companies. He has been a member of INCOSE UK since its
foundation in 1994 and was its Technical Director from 2005 to 2013.
Peter Mason a professional interim manager for digital transformation, has applied his service
systems thinking to a variety of service procurement and commissioning domains, most re-
cently concentrating upon the challenging government digital by default and cyber physical
systems of systems environments.
 Appendix – Set of Definitions

Term Definition Used in examples

A product that is intangible and Business, finance

Service (Abstract)
non-storable CMMI

A binding, written record of a promised

Service Agreement exchange of value between a service Contracts
provider and a customer.

Trusted advisors or intermediaries who IT – automated service

Service Broker
facilitate commercial transactions. composition

Service Cata- A list or repository of standardised ser- Government Service

log/Repository vice definitions G-NET

An element of the Service Design that

Service Component may be a lower level service, or a prod- Design of Services
uct.

The assembly of distributed component Design of Services

Service Composition services into a composite service to through Integration
complete the desired application. INCOSE Handbook v4.0

The party responsible for accepting the

Service Customer Service contracts
product or for authorizing payment.

An indication of an actual or potential

Service Incident Service Operation
interference with a service.

A defined magnitude, degree, or quality

Service Level Service contracts
of service delivery performance.

A service agreement that specifies de-

livered services; service measures; levels
Service Level Agree- of acceptable and unacceptable services;
Service Contracts
ment and expected responsibilities, liabilities,
and actions of both the provider and
customer in anticipated situations.

A measure of service delivery perfor-

Service Level Measure Service Contracts
mance associated with a service level.

A consolidated and standardised set of

services and service levels that satisfy Service company offer-
Service Line
specific needs of a selected market or ings
mission area.

The activities that are performed by an

Government contracts for
Service Management organisation to plan, deliver, operate and
services using ITIL
control services offered to customers
Term Definition Used in examples

A company or other organisation that

Service Provider Service contracts
provides a service.

A repository containing service specifi-

Service Registry and cations provided by Service Providers Service offerings Auto-
Repository that allow Service Brokers to see what mated or non-automated
Services are available.

A communication from an end user that

Service Request one or more specific instances of service Use of services
delivery are desired.

The complete set of requirements that

Requests for supply of
Service Requirements affect service delivery and service sys-
services prior to contact
tem development.

Specification of services –
normally in formal lan-
Service Specification Formal definition of a service guage

MoDAF, SeBOK

Provision of services, in
An integrated and interdependent com- any situation
Service System bination of component resources that
SOA
satisfies service requirements.
Open Group

A resource required for a service system Parts of the Overall Ser-

Service System Com- to successfully deliver services. vice, may be Services or
ponent
Products

A service system component that ceases

Service System Con- to be available or becomes permanently
Power, water, etc.
sumable changed by its use during the delivery of
a service.

Phase of lifecycle when the service is in

Service Use use and those elements specifically con- Facilities management
cerned with that use

People who use services or a higher level

Service User Consumers of the service
service that uses a lower level service.

A computer program that provides an Provision of existing

Service Wrapper interface to existing functionality ena- functionality but as a Ser-
bling them to be run as Services vice DoDAF