# Principles of Servitization and Definition of an Architecture for Model Driven Service System Engineering

Yves Ducq, David Chen, Thècle Alix

► To cite this version:

Yves Ducq, David Chen, Thècle Alix. Principles of Servitization and Definition of an Architecture for Model Driven Service System Engineering. 4th International Working Conference on Enterprise Interoperability (IWEI), Sep 2012, Harbin, China. pp.117-128, 10.1007/978-3-642-33068-1_12. hal-01515741

HAL Id: hal-01515741

https://inria.hal.science/hal-01515741

Submitted on 28 Apr 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Principles of servitization and definition of an architecture for Model Driven Service System Engineering<fnref n="1" />

Yves Ducq<fnref n="1" />, David Chen<fnref n="1" />, Thècle Alix<fnref n="1" />

¹ University of Bordeaux - IMS/LAPS

351 cours de la Libération

33405 Talence cedex

david.chen@ims-bordeaux.fr

**ABSTRACT.** European manufacturing enterprise will progressively migrate from traditional product-centric business to product-based service-oriented virtual enterprise and ecosystems. However, the changes in this servitization process must be accompanied using specific techniques. This paper aims at presenting the principles of migration from traditional tangible product company to a set of virtual organisations ensuring the various steps of a Product2service life cycle as well as a preliminary result to develop service modelling architecture. The proposed Model Driven Service Engineering (MDSE) architecture is adapted from MDA/MDI approaches as developed in INTEROP Network of Excellence. This architecture defines the various modelling levels and the related constructs to model based on servitization principles. The potential modelling languages to represent these constructs at each level of MDSE will be presented at the same time. Conclusions are given in the end of the paper.

**KEYWORDS:** Service system modelling, Enterprise modelling, MDI/MDA approaches

<footnote n="1">¹ This paper is elaborated on the basis of MSEE deliverable D11.1: Service concepts, models and method: Model Driven Service Engineering, WP1.1, MSEE consortium, 2012.</footnote>
# 1. Introduction

European manufacturing enterprise will progressively migrate from traditional product-centric business to product-based service-oriented virtual enterprise and ecosystems [1]. In this sense, traditional companies have to cooperate in one or several virtual enterprises, considered as service systems dedicated to support the service design, development, and implementation. During this migration process, service system that will provide desired services around the product will have to be modelled, designed, implemented, tested and managed along its entire lifecycle in order to ensure the correct migration of the company.

This paper presents some preliminary result of a research work performed in the frame of the FP7 MSEE Integrated Project [2]. Particularly, the goal of this work is to develop service system modelling language to support service system engineering and implementation. The approach adopted is to use Enterprise Modelling techniques as a basis under the Model Driven Service Engineering Architecture extended from Model Driven Interoperability approach developed in INTEROP Network of Excellence [3].

So, in a first part, the servitization process and the definition of what a service system is will be developed as well principles of system modelling. Then, the Model Driven Service Engineering Architecture will be presented insisting on its interest for the implementation of a coherent and complete virtual enterprise based on business models and on the description of each modelling level. The various levels of the architecture will be detailed as well as the required constructs to represent at each level based on the previous servitization principles. Then, enterprise modelling languages will be proposed to represent the constructs at each level. Finally, the perspectives of this work will be proposed.

# 2. Servitization and virtual organization as a service system

The studies and researches in the domain of Service have been mostly devoted to support tertiary sector domains (e.g. banking & finance, tourism, trade, public administration), with an obvious focus on ICT. At the end of the nineties, the concept of Service in Manufacturing appeared and the evolution from an economy of products towards an economy of services round the products becomes more and more important in manufacturing: this evolution is called **Product Service System (PSS)** or **Servitization**.

According to Wikipedia “a service is to make available a technical or intellectual capacity” or “to supply a work which will be useful for the user without material transformation”.

Most of the time a service is opposed to a good. The following list characterizes a service [4]:

* A service is not owned, but there is a restricted access,

* Services have intangible results,

* Customers are involved in the service production process,
* Other persons than the customers can be involved in the service process as stakeholders, sub-contractors, etc....

* Quality in service is difficult to control while increasing productivity and also difficult to apprehend

* Service cannot be stored.

* Service delivery delay is crucial.

* Service delivery integrates physical and electronic way.

Since a decade, new research thinking has been emerging, trying to systematize the multi-disciplinary knowledge involved in service systems. On their web page, IBM describes service science as “a growing multi-disciplinary research and academic effort that integrates aspects of established fields like computer science, operations research, engineering, management sciences, business strategy, social and cognitive sciences, and legal sciences” [5].

In the computer science domain, Service Oriented Architectures (SOA), have revolutionized information systems, by providing software engineers with powerful methodologies and tools for decomposing complex systems into autonomous components. The final aim of such evolution is to support enterprise vital processes and workflows, by simple orchestrations and compositions in the hand of business specialists.

Clearly the servitization of manufacturing companies covers different levels of service provision and consequently different stages can be followed to evolve. In servitization, the product is considered as the core element of the service to deliver to customers and subsequently we follow a manufacturing approach taking into account the market pressure that oblige to create new models in order to meet the servitization challenge. An appropriate concept to link products, product related services and the needs of the users is the “Extended Product” (EP) [6].

The Extended Product concept belongs to the category of Product-Service System. The Extended Product-Service is characterized by a layer model based on manufacturing product and defining the process extensions (Figure 1). The Extended Product is a complex result of tangible and intangible components.

<figure><img src="image_2.png" /><figcaption>**Figure 1.** *The Extended Product Concept, adopted from [6]*</figcaption></figure>
The Core Product is the physical product that is offered to the market; while the Product Shell describes the tangible “packaging” of the product (e.g. one enterprise sells machine-tools and will add the maintenance which can be done by another company). Supporting Services are intangible additions, which facilitate the use of the product (e.g. maintenance plans or mobility guarantees). Differentiating Services provide individualization of the Extended Product on the market.

Then product extensions are described by the tangible and intangible aspects of a “utility package” to satisfy the customers’ needs. They can be used to gain competitive advantage by offering added value to the customer. While in the past production costs, marketing, quality and reliability or time to market have been key success factors, nowadays innovation is the decisive characteristic [7].

The resulting Extended Product would be the specific solution satisfying the customers demand. As the solution can become very complex, several business partners may be collaborating for the provision of the EP in the frame of an Ecosystem.

Customers are looking for solutions and benefits (not only to acquire products) or even more they are requesting intangibles like leadership on the market, success, fame, etc. Manufacturers need to package their core products with additional services to make them more attractive.

The different stages of service provision are shown in Figure 2.

<figure><img src="image_3.png" /><figcaption>**Figure 2: Servitization process**</figcaption></figure>

**The first stage** is the selling of a product (e.g. a machine tool).

**The second stage** which initializes the servitization process and the evolution toward Product+Service, start by adding a simple service (Product and supporting service) (e.g. the company will add a device on the machine-tool allowing to check continuously the running of the machine etc).

**The third stage** (Product and differentiating service) is an evolution of the previous one. The service is more elaborated and increases the differentiation (e.g. the company can propose to sell the machine plus a service which guarantees a high percentage of availability of this machine).
**The fourth stage**, Product2Service scenarios are in contrast sharply decoupling manufacturing of goods and selling of services, where in most cases physical goods remain the property of the manufacturer and are considered as investment, while revenues come uniquely from the services (e.g. the company doesn't sell the machine-tools but sells hours of running of the machine-tool).

However, in this context, this is difficult for most of the companies to work alone in the Product2Service scenario but need to be associated to other companies all along the service life cycle. Working together in design and production networks results in an extension of companies' "ability to reach" e.g. wider markets and knowledge spheres, a higher level of the companies agility, as well as the possibility to share risks and resources. An industrial model for collaboration to exploit the various opportunities is a Virtual Organisation (VO) (figure 3).

<figure><img src="image_4.png" /><figcaption>**Figure 3: Virtual Organisation**</figcaption></figure>

A virtual organisation is an enterprise that marshals more resources than it currently has on its own, using collaborations both inside and outside of its boundaries, presenting itself to the customer as one unit. It is a set of (legally) independent organizations that share resources and skills to achieve a mission/goal.

However, such a virtual organization must be implemented differently in the different phases of a service life cycle in order to support the service system as shown in figure 4 below.

So from a common Ecosystem (Service Manufacturing Ecosystem) composed of several kinds of companies as research centres, SME's, large companies, consultants..., it is possible to select the companies which will be virtualized for each stage of the life cycle.
<figure><img src="image_5.png" /><figcaption>**Figure 4: Virtualisation of enterprises and modelling for each phase the service life cycle**</figcaption></figure>

Then, the implementation of each virtual organization must be done with agility and without spending too much cost, reaching an interoperable organisation. In order to do so, modelling of each virtual organization will be done through a set of modelling languages used in the frame of a common model driven architecture. In this sense, the next part will present the proposed architecture, describing in detail each modelling level and the required constructs to represent based on the servitization principles.

**3. Model Driven Service Engineering Architecture**

The proposed Model Driven Service Engineering (MDSE) Architecture is elaborated as an adaptation and an extension of MDA/MDI [8],[9] for the engineering of product related services in virtual enterprise environment. Although MDA/MDI approached are more focused on IT system deployment, MDSE architecture aims to allow supporting the needs of modelling the three types of service system components (IT, Human and Physical Means). The main benefits of this model driven approach is to allow a continuum in the modelling from the business to the realisational level and to specify and implement a set of component coherent with the chosen strategy of collaboration in the virtual enterprise.

The adapted MDSE architecture is shown in figure 5.
<figure><img src="image_6.png" /><figcaption>**Figure 5: MDSE architecture**</figcaption></figure>

Similar to MDA/MDI, the proposed MDSE defines a framework for service system modelling around three abstraction levels: Business Service Modelling, Technology Independent Modelling and Technology Specific Modelling.

**3.1 The Business Service Modelling level and related constructs and languages**

The Business Service Modelling (BSM) aims to model the service system, at the global level, describing the running of the virtual enterprise, i.e. the running of the collaboration between the considered enterprises. The models at the BSM level must be independent to the future technologies that will be used for the various resources. In this sense, it's useful, not only as an aid to understand a problem, but also it plays an important role in bridging the gap between domain experts and the development experts that will build the service system (adapted [9]). In fact we develop the BSM in two sub-levels: the Top BSM and the Bottom BSM. The Top BSM sub level models the enterprise and its environment at a global level in order to analyse the possibilities to develop the System Service (the GRAI modeling could be used). The Bottom BSM will allow to model in details the domain concerned by the servitization process (we can use the languages defined by the local modeling). Based on this first analysis, the service system will be decomposed in the various components domains (IT, Organisation/Human and Physical Means) with a detailed description. For instance, at the BSM level (top and bottom), the decisions are listed but not the related decision makers are related decision support systems. Similarly, the type of resources doing the activities is listed but not the precise name or location of these resources. The concepts identified on the basis of the principles of servitization and virtual organization as presented previously are listed below:

* Service

* Product

* Value

* Customer

* Partner
o Stakeholder (provider, intermediary, designer,...)

o Functionality

o Resource (Human type, Physical mean type, IT type)

o Process (business)

o Organization (responsibility, authority)

o Decision

o Decision structure

o Performance indicator

This list of concepts is considered as a list of core concepts.

Based on these concepts, several modelling languages can be used to represent the
virtual organization at the BSM level as indicated in the figure 6 below:

<figure><img src="image_7.png" /><figcaption>Figure 6: Modelling languages at the BSM level</figcaption></figure>

## 3.2 The Technology Independent Modelling level and related constructs and languages

Technology Independent Modelling (TIM), aims to represent the models at a
second level of abstraction independent from the technology used to implement the
system. It gives detailed specifications of the structure and functionality of the
service system that do not propose technological details. More concretely, it focuses
on the operation details while hiding specific details of any particular technology in
order to be suitable for use with several different technologies. At TIM level, the
detailed specification will be elaborated with respect to the components in the
domains of IT, Organisation and Human and Physical means for a service system.
So, the IT related modelling part aims at detailing the model of the enterprise
application, but mainly in terms of functionalities which will be implemented and
without defining which application will be chosen. The functionalities will be of
course derived from the models at the BSM level. These functionalities will be
classified according to their importance in order to prepare the future selection at the
lower level. The functionalities can also cover the requirements in terms of
interoperability with other systems implemented in one company of the ecosystem.
The Physical mean part will be related to the means to add value to the product and
to support the service production. At this level, the functionalities of a specific
machine and the expected performances can be proposed but no name of specific
machine is proposed. As for the IT part, the functionalities can be prioritized and
synthetized in order to propose a questionnaire that would be sent to the various
machine providers. This is obvious that the functionalities are derived from the
models, in particular the models of the physical system and business processes. The
human resource part aims at defining the kinds of skills that are required according
to the models. At this level, the name of a specific resource is not given but his/her
place in the organization, his/her role in this organization and performance to reach
must be detailed. This is obvious that this information can be derived, mainly from
the decisional modelling and the business process modelling as well as from the
physical models mainly for the persons directly involved in the product
manufacturing and the service distribution. Moreover, this information will be sued
for the recruitment or the move of specific human resource as well as for the
planning of the training of existing resource.

Based on these principles, the following constructs are proposed to be
represented in the models at this level:

○ Service

○ Process

○ Organisation

○ Resource

○ Organisation unit

○ Enterprise Application

○ Information

○ Human

○ Physical mean,

Based on these concepts, several modelling languages can be used to represent the
virtual organization at the TIM level as indicated in the figure 7 below:

<figure><img src="image_8.png" /><figcaption>Figure 7: Modelling languages at the TIM level</figcaption></figure>
## 3.3 The Technology Specific Modelling level and related constructs and languages

Technology Specific Modelling (TSM) aims to combine the specification in the TIM model with details that specify how the system uses a particular type of technology (such as for example IT platform, Physical Means or Organisation with Human profile). At TSM level, modelling and specifications must provide sufficient details to allow developing or buying software/hardware components, recruiting human operators / managers or establishing internal training plans, buying and realizing machine devices, for supporting and delivering services in interaction with customers. For instance for IT component, TSM adds to the TIM, technological details and implementation constructs that are available in a specific implementation platform, including middleware, operating systems and programming languages. So, the IT related modelling part aims at detailing the model of the enterprise application, but mainly in terms of detailed functionalities which will be bought or developed in the chosen enterprise application. The functionalities will be of course derived from the functionality modelling at the TIM level. The detailed functionalities can also cover the requirements in terms of interoperability with other systems implemented in one company of the ecosystem. The Physical mean part will be related to the choice of a specific physical mean. At this level, the functionalities of a specific machine and the expected performances will be verified and tested. As for the IT part, the functionalities will be very detailed and detailed actigrams could be used. This is obvious that the functionalities are derived from the models at the TIM level. The human resource part aims at defining the specific resource which will be selected, to verify the appropriateness with his/her place in the organization, his/her role in this organization and performance to reach defined at the TIM level. This is obvious that this information can be derived, in coherence with the decisional modelling and the organization models at the TIM level

Based on the specifications given at TSM level, the next step consists in the realization and the implementation of the designed service system in terms of IT components (including coding) for automated information processing, machine/device components for material handling, and human resource and organization ensuring human related tasks/operations.

Based on these principles and the strong relationship with the TIM level, the following constructs are proposed to be represented in the models at this level:

* Service

* Process

* Organisation

* Resource

* Organisation unit

* Enterprise Application

* Information

* Human

* Physical mean,

* Layout

Based on these concepts, several modelling languages can be used to represent the virtual organization at the TSM level as indicated in the figure 8 below:
<figure><img src="image_9.png" /><figcaption>Figure 8: Modelling languages at the TSM level</figcaption></figure>

5. Conclusion

In order to face the competitiveness, companies must progressively migrate from
traditional product-centric business to product-based service-oriented virtual
enterprise and ecosystems. In order to do so, they must create different virtual
organization all along the service life cycle. To support the migration, enterprise
modelling must be used to allow a progressive implementation of these virtual
organizations in the frame of a common architecture as MDSE architecture proposed
in this work with ensuring a continuum in the modelling, coherent from the business
to the technological level. The related constructs required to represent at each
modelling levels are derived from the servitization and virtual organization
principles. Potential modelling languages are proposed at each modelling level.

The main perspective of this work is to perform a first application to a real case
study in order to validate the architecture and the various concepts. Of course, some
modelling languages are already chosen at each level as the extended actigrams and
BPMN 2.0 at the top and bottom BSM levels for the process modelling or GRAI
Grid at the BSM level for the decisional modelling and the transformation
mechanisms are in progress. But this application could be fruitful for this validation.

References

[1] Thoben, K.-D., Jagdev, H., Eschenbächer, J. (2001) Extended Products: evolving traditional product concepts. In: K.-D. Thoben, F. Weber and K.S. Pawar (ed.) Proceedings of the 7th International Conference on Concurrent Enterprising: "Engineering the Knowledge Economy through Co-operation" Bremen, Germany, June 2001.
[2] FP7 - FoF-ICT-2011.7.3 - Manufacturing Service Ecosystem Project- Annex 1
description of work - July 29th 2011

[3] MDI: Model Driven Interoperability; Available at: http://www.modelbased.net/mdl/;
Accessed on: 15th March 2010.

[4] Christopher Lovelock, Jochen Wirtz and Denis Lapert - Marketing des Services, Paris,
France: Prentice Hall, 2004, 2nd ed., pp 619 ISBN 2-7440-7026-2

[5] http://www.ibm.com/developerworks/spaces/ssme.

[6] Thoben, K.-D., Jagdev, H., Eschenbächer, J. (2001) Extended Products: evolving traditional product concepts. In: K.-D. Thoben, F. Weber and K.S. Pawar (ed.) Proceedings of the 7th International Conference on Concurrent Enterprising: "Engineering the Knowledge Economy through Co-operation" Bremen, Germany, June 2001

[7] Jagdev, H. S.; Browne, J.: "The Extended Enterprise. A Context for Manufacturing". In: Production Planning & Control, 9 (1998) 3, S. 216-229

[8] MDA - The Architecture of Choice for a Changing World [Online] // Object Management Group. - January 2008. - http://www.omg.org/mda/.

[9] MDI: Model Driven Interoperability; Available at: http://www.modelbased.net/mdl/;
Accessed on: 15th March 2010