Western countries have seen a transition to a services-oriented economy. Most services delivered in the service economy are digital services in the sense that they are IT reliant / enabled. The development of sustainable digital services requires an active involvement of different actors with a mix of stakes, interests, roles, work practices, and even differing cultural and linguistic backgrounds. Our work aims to contribute to understanding the dynamics of the socioeconomical-technical environment in which the development of digital services takes place. One of the challenges is to understand what changes actually are relevant in what part of the socio-economical-technical environment and how these changes can be discovered. The focus of the paper is on understanding different aspects or viewpoints to be taken into account when analysing service design contexts. The main contribution of the paper are (a) to identify different aspects of the context of digital service development, (b) to show the feasibility of capturing contexts in a context model, and (c) a case study for digital service design.
Western countries have seen a transition to a services-oriented economy. Marketing
sciences [
Most, if not all, services delivered in the service economy are digital services in
the sense that they are IT reliant / enabled. IT is generally seen as being the key
enabler of the digital service economy [
Marketing sciences [
As a consequence, the development of sustainable (in a broad socio-economicenvironmental sense) digital services requires an active involvement of different actors. These participants are likely to mix different stakes, interests, roles, work practices, and even differing cultural and linguistic backgrounds. The (necessary) involvement of a broad range of participants entails a high risk of communication break-downs. Such break-downs may a.o. lead to the blocking or undermining of: collaboration in general, shared understanding of the impact of design alternatives, achievement of an agreement, and lasting commitment on courses of action to take. Even more, the consequences of these communication break-downs might not surface until later in the development life cycle, making them all the more costly.
On top of that, the high pace of change in technology, the economy, and society at large, creates the additional challenge of how to keep up with these developments. The expectation from modern day digital services is to deliver business value even in situations with contextual variations, e.g., caused by changes in business models of suppliers, user preferences, resource pricing, demand forecast, or legislation. What makes this challenge particularly hard is that such changes are unpredictable and often short-term, while at the same time requiring a quick response. Traditional approaches are, in many cases, too unresponsive.
Our work aims to contribute to the understanding of the dynamics of the socioeconomical-technical environment in which the development of digital services takes place. Our long-term vision is to be able to discover changes in the environment affecting digital service design and to adapt digital service development accordingly, for example by adjusting development processes, tools or practices or by offering assistive functions to the stakeholders involved. One of the challenges attached to this vision is to understand what changes actually are relevant in what part of the socio-economicaltechnical environment and how these changes can be discovered. In this paper, we focus is on understanding different aspects or viewpoints to be taken into account when analysing service design contexts. Our conjecture is that techniques from context modelling could be used for this purpose.
The main contributions of the paper are (a) to identify different aspects of the context of digital service development, (b) to show the feasibility of capturing contexts in a context model, and (c) a case study for digital service design. The remaining part of the paper is structured as follows. Section 2 describes the research method used. Section 3 summarizes the results of a literature analysis on related work. Section 4 presents a case study for digital service design and analyzes this case study. Section 5 shows the feasibility of modelling service design contexts based on the example of a stakeholder local practice in the case study. Section 6 discusses conclusions and future work.
The work reported in this paper started from the following research question which is based on the motivation discussed above: What constitutes the socio-technical context of digital service design and how can this context be modeled?
The research method we used towards this research question, is a combination of literature study and descriptive case study. We started by identifying research areas with relevant work for this question, and analysed the literature in these areas. The purpose of the analysis was to find existing theories, approaches or technologies which help to explain what factors or aspects are relevant to understand the context of digital service design. Due to the collaborative nature of service development, collaboration in information systems development and collaboration support for modelling and decision making were identified as relevant research areas and included in the literature study. Furthermore, the field of context modelling was deemed relevant as approaches from this field have been successfully applied in capability management and decision support systems which both depend on stakeholder involvement and methodology integration.
Since the literature study returned only “candidates” for aspects of service design context rather than proven theories (see section 3), we decided to perform a case study in order to gather information pertinent for the subject area. Qualitative case study is an approach to research that facilitates exploration of a phenomenon within its context using a variety of data sources. This ensures that the subject under consideration is not explored from only one perspective, but rather from a variety of perspectives which allows for multiple facets of the phenomenon to be revealed and understood. Within the case study, we used three different perspectives, which at the same time represent sources of data: the activities conducted during business service design, the resulting artefacts and interviews with actors in different roles involved in the design effort.
Yin [
In this section, we summarize the results of the literature study on collaborative development of information systems (3.1), support for collaborative modelling (3.2) and context modelling (3.3). 3.1
The development of digital services builds on a long tradition of information systems
engineering [
Systems and service innovation is an inherently collaborative process involving
different partners and stakeholders. In particular, when considering the shift from
goodsdominant logic to service-dominant logic, bringing about the need for a stronger
involvement of the different participants [
To improve alignment between business and information technology, information system (IS) developers continuously strive to increase the effectiveness of development artifacts. A key focus area is concerned with making the IS designs more accessible to business stakeholders to articulate their business needs more efficiently. Collaboration support in IS engineering typically includes tool support for the complete IS life-cycle as well as coordination and communication support for the stakeholders involved.
When designing collaboration support, organisational research [
Previous research proposed light-weight collaboration tools to support enterprise
modelling activities. For example, a model-based working environment [
Models should certainly not be treated as “passive objects”, but rather as objects that
one can interact with in a tangible way. Experiences from e.g. the EKD researchers [
In general, such assistive technologies for model development and model
improvement aim at improving or complementing computer-based EM tools. They include the
use of functionality from recommender systems to support modelers in finding suitable
constructs or modeling elements [
Another key aspect of collaborative design is collaborative decision-making. Based
on existing theories on e.g. decision-making [
The idea of context-based approaches is to identify how variations in the deployment context of digital services affect service functionality and delivery, and to integrate context-awareness into service design. For this purpose, context needs to be explicitly identified and captured. Our observation is that not only digital services benefit from context-awareness but also the development methods, tools and practices. Here, the context to a substantial part is shaped by the participant’s background and local practices. Thus, understanding the context could be a means to improve participant involvement and at the same time support digital service agility.
“Context-awareness” raised from being a special and innovative feature of niche
applications, to now be an important characteristic of many IT systems. Deys seminal
work defined context as information characterising the situation of an entity [
Approaches and methods for context modelling were analysed extensively by e.g. [
In the field of context modelling, some work has been done with a focus on
process context [
We see a great potential in applying the study of EM practices for understanding factors and the context that influence collaborative modelling. We need a certain understanding what different stakeholder groups in modeling really do when they model, what the role of modeling artifacts really is, how several actors collaborate in modeling or using models, how EM practices blend into their other work practices, and how information flows are shaped by EM practices. 3.4
The literature analysis presented in the previous section revealed that there is no single, established and accepted theory, approach or model about the context of digital service design. But the analysis resulted in a number of aspects which are expected to be relevant as part of the context, since they originate from either collaborative modelling, collaborative development or context model use.
More concrete, our hypothesis is that the socio-economical-technical environment of digital service development, i.e. the service design context, has to be differentiated into the context of the actual development life-cycle [DL], local practices [LP] of the involved stakeholder groups [SG] and the external environment [EE] of the organization relevant for service deployment [SD] (cf. Figure 1). The local practices represent the various stakeholder groups involved in service design. Here, it is important to understand different work practices, concerns, roles, etc., including their input into and output from collaborative processes. The external environment represents the potentially different settings of deployment and operation of the digital service [DS] under consideration where it is relevant to identify changes and contextual variations affecting service design. The development life-cycle should not only respond to external environment changes and adapt to needs implied by local practices, but also has own procedural and artefact-related variations relevant for the collaboration process. In the case study in the next section, we aim to confirm existence and relevance of these aspects. 4
This section summarizes the design, content and results of a case study on digital service design which was performed in the utilities industry. The purpose of the case study is defined by the research question given in section 2 and can be refined into two subquestions: 1. Can the aspects of digital service design contexts, i.e., actual development lifecycle, local practices of the involved stakeholder groups and the external environment of the organization for service deployment, be observed as affecting digital service design in the case study? This question aims at confirming the hypothesis from section 3.4 that context is a composite construct which has to be differentiated into three aspects. 2. What factors affecting the digital service design can be observed for the different context aspects? This question primarily focuses on the feasibility to single out different factors in the different context aspects. If this should not be possible at all, an approach aiming at automatic detection or measurement of these factors would not be feasible. 4.1
In order to investigate the context of digital service design, we performed an ex-post analysis of a use case from the EU-FP7 project Capability-as-a-Service in Digital Enterprises (CaaS). The company studied is a business services provider from the energy sector. Within this use case, we had access to several information sources: – One researcher worked during 3 months two or three working days every week at the BSPs facilities. The researcher was part of the team operating the business service and designing new business services for the service providers clients. The researcher maintained a work diary and collected information about the work processes, technologies used and practices by observing the co-workers and taking notes. The management of the service provider agreed to this procedure and the co-workers were informed about the purpose of the data collection. – The CaaS project investigated the design of capabilities on the basis of business services offered by the BSP. From a technical perspective, capability design includes the identification of potential variations in business service delivery. Thus, CaaS also captured information about the actual business services, their development processes and aspects relevant for deployment. This information is included in the CaaS deliverables related to the use case of the BSP. The deliverables were accessible to the researchers and could be analyzed. – The internal business processes at the BSP, which were performed for delivering the business process service to the clients, were captured by interviewing different roles in the BSP.
The main subject to investigate was what constitutes the socio-technical context of digital service design in the case study?. As already indicated in section 2, the character of the case study is descriptive. Furthermore, we defined two propositions P1 and P2 reflecting the research questions introduced at the beginning of this section. – P1: Context aspects identified in the literature study can be observed in the case study. – P2: For each context, the case shows examples for potential factors.
To set clear boundaries for the case we defined that only data collected during the three months work of the researcher (see above) at the BSPs facilities (including the deliverables and interviews) shall be taken into account. Not subject of the case study are BPO services provided to other utility industries (water, gas, etc.). 4.2
Due to the space limitations only a summary of the data collected in the case study can be presented in this paper. In this summary, we inserted the codes defined for the aspects of service design context (see section 3.4), e.g. [DL] for the aspect development life-cycle, if the information collected can be linked to the aspect. This linking to codes will be used in section 4.3 when evaluating the case study data.
The industrial case study analyzed in this paper was part of the EU-FP7-project Capability-as-a-Service (CaaS) with SIV.AG from Rostock (Germany) as case study company. SIV offers business process outsourcing services to a variety of medium-sized utility providers [SG] and other market roles of the energy sector in Germany, Bulgaria, Macedonia and several other European countries. Energy distribution companies [SG] are facing a continuously changing business environment [EE] due to new regulations and bylaws from regulating authorities and due to competitors implementing innovative technical solutions in grid operations or metering services, like intelligent metering or grid utilization management. In this context, both the business processes in organizations and information systems supporting these processes need to be quickly adaptive to changing organizational needs. Examples for typical business functions are assets accounting, processing and examination of invoices, meter readings, meter data evaluation, automatic billing and customer relationship management [DS]. Business process outsourcing [DS], i.e. the performance of a complete business process for a business function by a service provider [SG] outside an organization, has to offer and implement solutions for different cases [DL]. One variation is inherent in the business process as such. Even though core processes can be defined and implemented in standard software systems, configurations and adjustments for the organization in question are needed [LP]. The second cause of variation is the configuration for the country of use, i.e. the implementation of the actual regulations and bylaws [EE]. The third variation is related to the resource use for implementing the actual business process for the customer, i.e. the provision of technical and organizational capabilities [SD]. Basis for these services is SIVs software product kVASy4. Integrated with the business process environment, the native kVASy4 services providing business logic for the energy sector are implemented using a database-centric approach. From an company perspective, SIV consists of the SIV group [SG] (overall management and provider of kVASy4, SIV Utility Services (SUS) [SG] (provider of business process outsourcing solutions) and Architecture and Technology (AUT) [SG] (software development and method provider). Different deployment models are used including a provider-centric model (kVASy4 and the business processes are run at SIV), a client-centric model (kVASy4 is installed at the client site and the manual work of the business process is performed at SIV) and mixed models (e.g. kVASy4 in the cloud, work and process performed partly at the client and partly at SIV). SIV aims at a more dynamic way of providing business process outsourcing services to their customers for ad-hoc up-scaling of services for existing customers such as automatic validation of exchanged messages [DL]. Furthermore, SUS is interested in a more flexible or even automatic allocation of tasks to knowledge workers [LP].
In the context of the use case, we analyzed the process of adapting an existing business service [DL] to new requirements with respect to the work flow, the roles involved and the technologies. Business services usually are developed for a defined customer group, but what is delivered to one specific customer from this group still has to be adapted in various aspects; three of these aspects already have been discussed above (business process of organization, country of use, resources used for delivery). Furthermore, in this business process outsourcing scenario, the service design process has to accommodate requirements from two perspectives: (a) adapting the outsourcing solution to the customers demand (i.e. SIVs customer) [DL, SG] and (b) adapting the outsourcing solution to new business requirements of the service provider (i.e. SIV). Independently of the perspective, it became clear that we have similar development and operating processes, technology stacks and roles involved, which is illustrated in Fig. 2 [DL].
The development process encompasses all steps for designing, developing, deploying and operating business services, i.e. from requirement to the running system. In the scenario we distinguish three different phases in the development process: – The conceptual solution addresses the development of business services which fit to the strategic objectives and meet the practical demands of SIV’s client or SUS [LP]. Focus here is on the business logic, not on the technical implementation. – The technical solution prepares the conceptual solution for execution. This usually requires an enhancement or refinement of the conceptual solution when adapting it for a specific technical platform for execution [DL, EE]. – The executable solution represents the technical solution deployed on a specific platform. This running system is managed by the enterprise that uses it or by a service provider [EE].
The technology stack encompasses all IT-tools and platforms requires for the above phases of the engineering process. This includes tools and notations or languages for modelling the conceptual solution, as well as software development environments, operating platforms and monitoring tools used during execution of the solution. During the engineering process different professions and roles are involved, such as business analyst, solution engineer or knowledge Worker. 4.3
The main technique for analysing the case study data was to link the data to the propositions. Thus, we will discuss both propositions in the light of the case study data. As both propositions are related to the factors identified in section 3 and summarized in 3.4, we will start the analysis by providing an overview what information is visible in case study data regarding the factors. This summarized in table 2.
P1: Context aspects identified in the literature study can be observed in the case study. The case study data and table 2 shows that all aspects of the service design context identified in the literature analysis and included in our hypothesis (section 3.4) are visible in the case study.i.e. the case study supports the hypothesis. Among the stakeholder groups participating in the business service design were the BPO unit in SIV utility services (subsidiary of case study company - SUS), the product management unit in the SIV group (PMU) and the unit in charge of developing the business services (Architecture and Technology unit - ATU).
P2: For each context aspect, the case show contains examples for potential indicators. For all context aspects, factors can be identified. For brevity reasons, only some examples are presented. In the development life-cycle context, factors for changes visible in the case study are adjustments in business processes requiring the integration of new technologies, information sources or domain experts from the client’s side. In the external deployment context, technical changes in the deployment environments or deployment models would cause adaptations. Examples of factors in the local practice are discussed in the next section. 5
The intention of this section is to investigate feasibility of capturing the context of
digital service design by using the case discussed in section 5. For this feasibility study, we
decided to focus on the stakeholder groups and their local practices, as this seems to be
the most challenging one among the three service design context aspects. The external
deployment context and changes occurring here were to some extent already
investigated in the CaaS project ([
More concrete, we considered the stakeholder group SUS (i.e. the BPO unit - see
section 4) and what we learned from the case about SUS’s local practices. In order to
identify potential factors in this local practice context, we used the general idea of the
CaaS context modelling method (CM) ([
The analysis of the case material about the SUS local practice returned the following factors influencing service design: – changed work procedures for achieving more efficiency: When SUS sees the necessity to modify the work processes of their knowledge workers this often results in a need to also adapt the supporting information systems or services. The necessity to modify either originates from new targets regarding costs or revenue defined by
SIV management or relates to optimization possibilities detected internally in SUS. Adaptations typically include the information to be provided in entry forms or the sequence of actions. – new or changed qualification profiles of knowledge workers: when new BPO products are defined, they might lead to different qualification profiles of the knowledge workers. SUS will typically try to meet these new profiles by training some of the existing staff members and to define adequate work procedures. In addition to new service designs, this might even influence existing services.
Furthermore, we also found factors influencing the digital service delivery, i.e., factors probably relevant for the deployment aspect of the context: whenever the indicators agreed on in the service level agreement with the client were violated, the SUS would require adaptation in the service delivery which might also effect the service design. An example is the maximum time for treating exceptions. If the maximum is exceeded, the SUS normally would react by assigning more knowledge workers to the client in question. However, if downtimes or performance problems of the IT-platform used for the BPO service would be the cause, changes in the technical architecture might be needed.
For the above factors, we tried to identify suitable indicators and ways to capture them. Like the focus on variations, this step again was inspired by CM and resulted in the following table:
For both factors identified, the table shows that there might be several sources indicating their existence and several possible origins. The above factors probably only are a fragment of all existing factors, as we did not do a complete analysis of the SUS local practice but only used the available material from CaaS.
With the factors and indicators identified, we were also able to produce an initial
context model of the SUS local practice context using the CaaS CDT tool ([
The long-term vision motivating the work in this paper is to be able to discover changes in the environment affecting collaborative service design and to adapt digital service development accordingly. As a first step to achieving this vision, we investigated the constituents of this environment, i.e. of digital service development contexts. Based on a literature study we identified three context aspects: the actual development life-cycle; local practices of the involved stakeholder groups; and the external environment for service deployment. The existence and relevance of these three context aspects were confirmed in an industrial case. The case also showed factors relevant for identifying changes in all three contexts. For one selected context aspect, the local practice context of a specific stakeholder group, we also identified indicators for all factors and captured factors and indicators in a context model.
The main limitation of the paper obviously is that only one industrial case was investigated. More cases are required to confirm that the identified context aspects are applicable in general and to learn more about potential factors and indicators in the context aspects.
Future work will have to include several lines of investigation aiming at achieving our vision: more theoretical work is needed to understand the dynamics of collaboration in service development. The relevant changes in the service development environment might be related to each other and the way to identify relevant changes probably is different in the three context aspects. Based on a better understanding of these dynamics, another line of future work has to address development of a methodology to capture all relevant context factors and indicators of the three context aspects, and to establish in what situations changes are required and what kind of change this has to be. Furthermore, we probably need a set of instruments, like process adjustments, assistive tools or changes in group composition, which provide actual ways of adjustment in the situations identified.