Service Design has its roots at the confluence of various disciplines, mainly marketing, but also design or management. There is consequently a myriad of definitions of what Service Design is, but all of them agree that its main goal is the development or improvement of services that satisfy the user needs.

From its advent in the early 2000s, Service Design has gained attention and today it is the entry point to service development for any organization seriously concerned with user experience and digital transformation. The number of service design agencies or organizations adopting it has grown exponentially. See for instance the Government Digital Service initiative, which materializes the efforts of the British administration in this regard.

Two modeling disciplines, namely business and business process modeling, are at the core of Service Design. On the one hand, business models such as the Business Model Canvas or the e³value model provide a quick and strategic overview of the organization. On the other hand,  business process models, like Service Blueprints, Process Chain Networks or BPMN models are more oriented to show the details of a particular service offering. Note that business modeling should precede business process modeling. Before addressing the development of detailed business process models that will be used to model service operations, organizations need to identify where the value is created. This is where business modeling helps.

Business modeling should precede business process modeling. Organizations must identify where the value is created before deciding the services to offer Click To Tweet

Even though tool support is currently available for some of these modeling notations, there is no comprehensive solution that allows working with all of them. Therefore, different standalone tools must be used for each notation, like generic diagramming tools or web-based apps, such as MS-Visio, Lucidchart, Strategyzer, Creately and the like. Although these can be good options for quick sketching, such tools were not devised to enable later processing of the information gathered in such models.

So, given that the only option to support some notations was to develop a new tool due to the lack of previous tool support (PCN) and the lack of model-based tool support for other notations (Canvas, Service Blueprint or e³value), we developed INNoVaServ, a modeling toolkit to support all modeling tasks part of Service Design. The development of INNoVaServ facilitates the building of technological bridges among the modeling notations used for Service Design and enables the implementation of post-processors for the models elaborated during a Service Design project.

If you want to know more about INNoVaServ, you can continue reading for a comprehensive overview or you can have a look at its website and the tool paper Model-Based Tool Support for Service Design, a work co-authored by Francisco J. Pérez, myself, Cristian Gómez, Valeria de Castro and Esperanza Marcos, which was presented at the 23rd International Conference on Fundamental Approaches to Software Engineering (FASE 2020).

A DSL toolkit for Service Design

INNoVaServ currently bundles five graphical DSLs to support the aforementioned business and business process modeling notations: Business Model Canvas, e³value, Service Blueprint, Process Chain Network and BPMN. Besides, the tool supports the generation of partial views of models based on a particular notation from models made with another one, along with the corresponding relations model.

Each DSL was built atop of Eclipse EMF/GMF and later migrated to Sirius. A series of additional functionalities have been also added to the DSLs, such as the automatic validation and fixing of models using Acceleo. Besides, to materialize the relationships among the notations supported by the tool, a generic relations (or traces) metamodel has been defined to support the creation of relations models. In the meantime, a more complete metamodel, enabling the identification of more sophisticated relationships could be used.

The Epsilon family of languages was then used to implement a set of model transformations so that when any of these transformations is run, a relations model is generated along with the corresponding target model. Specifically, ETL has been used since it supports many-to-many model transformations and it eases the combination of declarative rules with imperative constructions and lazy and greedy rules. This is an essential feature since many of the model transformations developed are not direct but require a certain level of interaction with the user to collect some design decisions that should guide the transformation. EOL was then used to improve user interaction by means of dialog boxes to drive the transformations accordingly.

To handle and visualize the information collected in the relationships models, Modelink, a simple yet useful multi-panel editor provided by Epsilon is used. It consists of 2-3 side-by-side EMF tree-based editors, which allows visualizing the source and target models, along with the relations model. Note that relationships collected in the latter can be directly edited in the editor. Again, it is worth noting that the visualizations provided by Modelink are planned to be improved by developing ad-hoc multi-panel editors like those bundled in MeTAGeM-Trace. For instance, integrated overviews of all the models involved in a given project and their relationships could be supported this way.

The next figure illustrates the relationships that hold between the different notations supported by the toolkit: 1:1 relationships hold between business modeling notations whereas 1:N relationships hold between business process modeling notations. For instance, each Business Model Canvas can be mapped into an e³value model (plus the relevant relationships model) and vice versa. However, a Service Blueprint is needed to visualize the details of each service operation represented in an e³value or Business Model Canvas model.

Business modeling vs business process modeling

Relationship between Business Modeling and Business Process Modeling notations

Since we are considering five different notations, we can bridge them with twenty model transformations. This would yield an overcomplex scenario, which will get even more complex as support for other notations is integrated into the tool.

To address this complexity, we have selected the minimum set of transformations that allow generating models for any supported notation by means of transformation chains. This way, the direct transformations implemented and bundled in INNoVaServ are those shown in the figure below.

As can be shown, to move from a BPMN model to a Business Model Canvas one, intermediate transformations to pass through PCN, Service Blueprint and e³value will be run. Four relations models will be generated consequently.

It should be highlighted that the mappings between models in the same category (either business or business process models) are more comprehensive than those between models of different categories. This is due to the different nature of business organization and business process models. For instance, around 75% of the e³value model can be generated from the related Business Model Canvas, whereas 98% of the BPMN model can be generated from the related PCN model. On the contrary, only 10% of the Service Blueprint can be generated from the corresponding e³value model.

As can be shown, to move from a BPMN model to a Business Model Canvas one, intermediate transformations to pass through PCN, Service Blueprint and e³value will be run. Four relations models will be generated consequently.

It should be highlighted that the mappings between models in the same category (either business or business process models) are more comprehensive than those between models of different categories. This is due to the different nature of business organization and business process models. For instance, around 75% of the e³value model can be generated from the related Business Model Canvas, whereas 98% of the BPMN model can be generated from the related PCN model. On the contrary, only 10% of the Service Blueprint can be generated from the corresponding e³value model.

To illustrate the use of the models and transformations supported by INNoVaServ you can refer to the artefacts developed in the context of a particular Service Design project used as case study. Its main objective was to tackle the issues that arose while managing a drastic growth (x2 in 6 years) in the number of students carrying out the defense of their respective final thesis projects at a public university. All the artifacts (models) developed in the project can be accessed online and edited with the toolkit presented here. For instance, the following figure shows the Business Model Canvas and e³value models for the case study along with the corresponding relations model.

Example of a service design project

A DSL toolkit to support Service Design Processes

All this given, the figure below illustrates the methodological and technical proposal of INNoVaServ by sketching how the notations currently supported by the toolkit fit into the Service Design process traditionally identified with the Double Diamond model from the UK Design Council. This Double Diamond model defines a design process encompassing two different phases of convergent and divergent thinking. During the first one, where business modeling can help, the aim is at discovering the user needs to later define the problem that will be tackled. Later on, business process modeling is used during the second phase to design multiple solutions to the problem identified and to go deep into the details of the solution selected which will be finally delivered. In the following we elaborate a bit on the use of the models specifically supported by INNoVaServ in the context of the double diamond model.

Double Diamond model for service design

Understanding the problem

The Business Model Canvas is probably the most popular modeling notation among managers, designers and the like. It helps to visualize and evaluate a specific value proposition that combines the offering of goods and services. It is built around nine basic modules comprising certain information that illustrates a company’s reasoning regarding the process of earning money. On the other hand, e³value is a business model which allows the graphical representation of a business idea, without going into detail regarding the processes comprising the services offered. To that end, e³value models are focused on added value activities, which are those activities carried out by an actor in order to obtain a certain benefit, as well as value exchanges, that consist of actors (unitary or market segments) exchanging different value objects (goods, money or even services).

Both models are useful at the early stages of the Service Design process depicted above by the double diamond model, because they help to explore and define the problem. For instance, the analysis of the data collected in these models during the case study, along with the underlying information, was used to conclude that the key issues in the final thesis projects area were related with the assignment of final thesis to tutors or supervisors and students. Being this a manually operated service, there was a need to automatize or optimize the way this service is provided in order to accelerate the process.

Designing Solutions

After having identified the problem to address, we shall provide solutions to such problems. In other words, with the information gathered during our visit to the problem space, it is now time to enter the solution space. In order to do that, INNoVaServ supports three business process modeling notations to define the service operations that should serve to address the problems identified: Service Blueprint, Process Chain Network and BPMN.

The Service Blueprint is a graphical tool used to design business service operations, which is focused on defining the interaction between the customer and the supplier that provides a given service. Hence, a Service Blueprint is needed to visualize the details of each service operation due to the fact that every Business Model Canvas or e³value model typically entails several service operations. However, decision nodes cannot be represented in service blueprints, which can interfere with the visualization of processes based on contextual conditions. Besides, it only supports the representation of two entities (service consumer and provider).

On the other hand, the Process Chain Network (PCN), another modeling technique to visualize service operations, offers more detail than the Service Blueprint, which does not differentiate customer independent actions nor reflect the other participant entities. PCN is able to do that through its very own network. This way, in spite of being much less popular than Service Blueprints, probably due to higher complexity, PCN can complement Service Blueprint to enable the comprehensive modeling of service operations.

Finally, due to its widespread adoption, in particular among IT practitioners, tool support for BPMN was also bundled in INNoVaServ.

The models defined with these notations play a key role during the second phase of the service design process, since they are key to develop and test prototypes and solutions. The models elaborated can be used during the divergent moments to discuss about posible solutions without having to implement them. Finally, once a selection has been made, Service Blueprint and (or) PCN models are frequently used by business people to discuss the details of the service operations that must be implemented in order to operate the services offering finally selected to be delivered. Afterwards, having taken into account that IT practitioners are more familiar with BPMN, the Service Blueprint and PCN models are used as input to automatically generate the BPMN models that will drive the implementation of the technical support for the service.

Concluding

INNoVaServ addresses an issue that has been acknowledged as one of the main problems of service design: the lack of proper technical support. The constant and rapid development of new services, goods or product-service offerings to address emerging needs as soon as they appear is indeed a must for any organization. Hence, the increasing interest regarding the field of service design. However, service design is currently considered an emerging field, in which industry is probably ahead of academia. Bringing some degree of formalization to service design has proven to contribute to ensure the success of the process and in turn increases the effectiveness of the artefacts delivered during the process, improving the rationality of the decisions within the company.

Without harming the creativity of designers while still fostering co-creation, model-based processing techniques make it almost immediate to start asking questions to the design artifacts. For instance, the organization is now able to: analyze the e³value model in order to assess if it is involved in too many value exchanges and give back such assessment with quantitative data; compare two Business Model Canvas to identify the number of new partners that appeared; apply process mining techniques in order to assess the performance of a particular process and compare it with the process modeled in a service blueprint or a BPMN model; use formal techniques to validate or simulate the service operations implied in the provision of a given service, etc.

A wide range of possibilities appears as soon as designers are able to persist and post-process their models instead of using them as mere sketching tools. It should be emphasized as well that these possibilities are materialized by means of well-known and contrasted model-based technologies instead of ad-hoc solutions. As a matter of fact, this approach is easily applicable to any other service design technique by simply developing a new visual DSL and a set of technological bridges.

Finally, this work is somehow a step forward in the line we started some time ago, in which our objective is not so much to innovate in model-driven engineering per se as to show the utility of model-based technologies in other areas. One movement in this direction is to broaden its scope of application to other fields where both modelling and automation can decisively help to address their problems of interest. This is the case with service design practitioners: model-driven engineering techniques can help them to materialize and drive forward their ideas by providing them with the appropriate tooling.

Interested in modeling?

Interested in modeling?

Follow the latest news on software modeling and low-code development

You have Successfully Subscribed!

Pin It on Pinterest

Share This