=Paper=
{{Paper
|id=Vol-2238/paper7
|storemode=property
|title=The Context of Collaborative Digital Service Development
|pdfUrl=https://ceur-ws.org/Vol-2238/paper7.pdf
|volume=Vol-2238
|authors=Henderik A. Proper,Kurt Sandkuhl
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/ProperS18
}}
==The Context of Collaborative Digital Service Development==
https://ceur-ws.org/Vol-2238/paper7.pdf
The Context of
Collaborative Digital Service Development
Henderik A. Proper1 and Kurt Sandkuhl2
1 Luxembourg Institute of Science and Technology, Luxembourg
e.proper@acm.org
http://www.list.lu
2 University of Rostock, Germany
kurt.sandkuhl@uni-rostock.de
http://www.uni-rostock.de
Abstract. Western countries have seen a transition to a services-oriented econ-
omy. 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 back-
grounds. Our work aims to contribute to understanding the dynamics of the socio-
economical-technical environment in which the development of digital services
takes place. One of the challenges is to understand what changes actually are rel-
evant 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 con-
texts. 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.
Keywords: digital service · service development · context.
1 Introduction
Western countries have seen a transition to a services-oriented economy. Marketing
sciences [14, 32] suggests that the notion of economic exchange, core to the economy,
has shifted from following a goods-dominant logic to following a service-dominant
logic. The former takes the view that economic exchange revolves around transactions,
where value is exchanged, e.g. in terms of a transfer of goods versus monetary value.
The latter shifts this towards the view that the creation of value involves the integration
of resources, of providers and users, to the benefit of the latter. For instance, in the
airline industry, jet turbine manufacturers used to follow a classical goods-dominant
logic by selling turbines to airlines. However, since airlines are not interested in owning
turbines, but rather in the realization of airtime, manufacturers nowadays sell airtime to
airlines rather than jets or jet turbines.
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 en-
abler of the digital service economy [30]. Businesses such as AirBnB, Uber, Netflix or
74
Spotify also show how the digital transformation results in (disruptive) innovations of
traditional sectors.
Marketing sciences [14, 32] also observes that the shift towards services as the fun-
damental basis of economic exchange has profound implications on the way organiza-
tions operate and value is created. Firstly, it leads to an increased interdependence be-
tween different actors and the need for integration of their resources in creating value.
Secondly, further changes are triggered in terms of business models with a stronger
involvement of users / customers in all phases of value creation.
As a consequence, the development of sustainable (in a broad socio-economic-
environmental 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 socio-
economical-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 af-
fecting 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-economical-
technical environment and how these changes can be discovered. In this paper, we fo-
cus is on understanding different aspects or viewpoints to be taken into account when
analysing service design contexts. Our conjecture is that techniques from context mod-
elling could be used for this purpose.
The main contributions of the paper are (a) to identify different aspects of the con-
text 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.
75
2 Research Method
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 [34] identifies different kinds of case studies: explanatory, exploratory and de-
scriptive. The case study presented in section 4 has to be considered as descriptive, as
it is used to describe the phenomenon of process outsourcing and the real-life context
in which it occurs. As mentioned in the introduction, section 3 will discuss the results
of the literature study and section 4 will present the case study. Based on the case study
results, we conclude that there is a potential of capturing the context of service design
in context models. In order to demonstrate the feasibility of these ideas, we model one
aspect of the context design context by modelling: the context of a local practice. This
argumentative-deductive step in our research work is discussed in section 5.
3 Results from the Literature Analysis
In this section, we summarize the results of the literature study on collaborative de-
velopment of information systems (3.1), support for collaborative modelling (3.2) and
context modelling (3.3).
3.1 Collaborative Development of Information Systems
The development of digital services builds on a long tradition of information systems en-
gineering [4], business process engineering [1], and enterprise architecture [23]. Each
76
of these specialisations of, what might be broadly called, “enterprise and information
systems engineering” have developed their own strategies to deal with the need to in-
volve different stakeholders, in particular when confronted with fast changing contexts.
As confirmed by our own experiences [22, 33, 27, 24], engaging such a broad collection
of stakeholders is not trivial. It also entails an immediate risk of (costly) break downs
in the communication [10, 24] among the participants.
Systems and service innovation is an inherently collaborative process involving dif-
ferent partners and stakeholders. In particular, when considering the shift from goods-
dominant logic to service-dominant logic, bringing about the need for a stronger in-
volvement of the different participants [14, 32] to ensure value co-creation.
3.2 Support for Collaborative modelling
To improve alignment between business and information technology, information sys-
tem (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 [7], workplace stud-
ies [19] and computer supported cooperative work [19] provide important contributions.
Workplace studies have a focus on how artifacts (traditional or digital) are embedded in
human activities, e.g., as a tool, as material, or as a knowledge repository.
Previous research proposed light-weight collaboration tools to support enterprise
modelling activities. For example, a model-based working environment [25] empowers
information carriers and enterprise architects to collaboratively and incrementally de-
velop and manage a model in a bottom-up fashion by using “Hybrid Wiki”, i.e. Wiki
pages enriched with types and attributes. This results in a collaborative model-based
collaboration environment that supports the evolution of both the user-model and its
data [25]. Its goal is to empower non-expert users to collaboratively gather and consol-
idate information in a flexible information system (SocioCortex) [25].
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 [31]
indicate that the use of e.g. Post-Its and Brown-Paper makes collaborative modelling
more engaging to stakeholders than the use of graphical models on traditional com-
puter screens. The potential disadvantage of the use of Post-Its, etc, is of course that
the information gathered in this way is not directly available in a useful digital format.
In [3], the authors define the concept of participative modelling (i.e. communication en-
gagement) which should involve innovative tools and technologies. According to Barjis
et al., these tools must be able to capture complexe and advances interaction. Partic-
ipatory modelling, therefore investigates how tools such as multi-touch tabletops and
mobile devices or data-glasses [17, 16] can be applied in EM, what differences in group
productivity, role distribution or model acceptance exist compared to conventional mod-
elling on plastic walls and white-boards and what adaptations in notations and support-
ing tools should be made (see, e.g., [15]). Furthermore, the “game metaphor” [13] has
77
also been considered to enable the “playing of games with models” to more tangibly
engage stakeholders.
In general, such assistive technologies for model development and model improve-
ment 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 [11], the use of semantic technologies to interpret the
meaning of labels and detect similar constructs in other models [12] or to investigate
model patterns or model fragments [8] which could be reused to make models more
detailed or precise, or to extend them. In doing so, assistive technologies can also make
modeling more accessible to broader user communities.
Another key aspect of collaborative design is collaborative decision-making. Based
on existing theories on e.g. decision-making [20], group-based modelling [26], and col-
laboration engineering [6], we have already conducted research on different strategies
supporting collaborative design and decision-making in the context of e.g. enterprise
architecture [21, 22, 33, 24].
3.3 Context modelling
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 explic-
itly 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 in-
volvement 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 [9]. How-
ever, design and development of context-awareness still require substantial engineering
work, i.e. there is no general development methodology for context-based systems. One
reason for this probably is the variety of interpretations of the term context in the area
of engineering [18]. An essential part of developing context based systems is to analyse
and conceptualise the elements of the specific context required for the application under
development, including their dependencies and mechanism of use.
Approaches and methods for context modelling were analysed extensively by e.g. [18].
Based on such work, four major scientific work streams can be identified: foundations
and essential features of CM, approaches to represent context models, application cases
for context models and, most relevant for our work, methods for context modelling.
In the field of context modelling, some work has been done with a focus on pro-
cess context [2], context modeling in digital enterprises [5] and context in decision
support [29]. Some of these works also investigate variation as a contribution to con-
text modelling, but none of them includes all perspectives represented in an enterprise
model. In particular the importance of the product perspective is neglected in all ap-
proaches. Furthermore, there is no approach addressing networked organisations, which
supports our proposal for a specialised context modelling method.
78
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 un-
derstanding what different stakeholder groups in modeling really do when they model,
what the role of modeling artifacts really is, how several actors collaborate in model-
ing or using models, how EM practices blend into their other work practices, and how
information flows are shaped by EM practices.
3.4 Conclusion: Aspects of Service Design Context to be investigated
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 rel-
evant as part of the context, since they originate from either collaborative modelling,
collaborative development or context model use.
Fig. 1. Different aspects of the service design context
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 organiza-
tion 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 un-
derstand different work practices, concerns, roles, etc., including their input into and
output from collaborative processes. The external environment represents the poten-
tially different settings of deployment and operation of the digital service [DS] under
79
consideration where it is relevant to identify changes and contextual variations affecting
service design. The development life-cycle should not only respond to external environ-
ment 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 Case Study
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 sub-
questions:
1. Can the aspects of digital service design contexts, i.e., actual development life-
cycle, local practices of the involved stakeholder groups and the external environ-
ment 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 Case Study Design
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 En-
terprises (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 pro-
cesses, 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 in-
cludes the identification of potential variations in business service delivery. Thus,
CaaS also captured information about the actual business services, their develop-
ment 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.
80
– 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 Summary of Case Study Data
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 organiza-
tions 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 evalu-
ation, 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
81
is SIVs software product kVASy4. Integrated with the business process environment,
the native kVASy4 services providing business logic for the energy sector are imple-
mented using a database-centric approach. From an company perspective, SIV consists
of the SIV group [SG] (overall management and provider of kVASy4, SIV Utility Ser-
vices (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 busi-
ness 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 mod-
els (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].
Fig. 2. Roles, processes and technology stack in development process
82
The development process encompasses all steps for designing, developing, deploy-
ing 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, op-
erating 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 Case Study Analysis
The main technique for analysing the case study data was to link the data to the propo-
sitions. 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.
Table 1. Context aspects and their presence in case study data
Aspect Code Description
Stakeholder Groups [SG] SIV group and management; SIV Utility Service; Architec-
ture and Technology, Utility providers (BPO clients)
Development Life-Cycle [DL] Iterative process including development of conceptual solu-
tion, technical solution, executable solution and adaptation
to new requirements
Local Practice Context [LP] Visible for all stakeholder groups shown in the first row of
the table
External Deployment Context [EE] Visible in different deployment models and various deploy-
ments for different clients
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 con-
text identified in the literature analysis and included in our hypothesis (section 3.4) are
83
visible in the case study.i.e. the case study supports the hypothesis. Among the stake-
holder 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 indica-
tors. 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 vis-
ible 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 Modelling Service Design Context
The intention of this section is to investigate feasibility of capturing the context of digi-
tal 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 investi-
gated in the CaaS project ([5]). Although CaaS used the perspective of capabilities, this
made clear that adaptation of business services to changes in the delivery environment
are required and technically feasible. Adaptations to the development process of digital
services were to some extent subject to research work in situational method engineering
(SME). Although automatic, indicator-based detection of changes has not been investi-
gated in SME, we learn from SME that changes in the development process may occur
and include, e.g., the sequence of tasks or the aids to be used. However, for local prac-
tices and what activities, events or changes cause effects on digital service design, more
work seems to be needed.
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) ([28]): to look for variation in work processes
and identify the reasons for these variations. CM recommends to focus on the busi-
ness processes performed and identify variation points and variations aspects in these
processes. Variations points basically are activities in the process which might be per-
formed in different ways or lead to alternating sequences of the following activities and
variation aspects are the reasons for this.
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 neces-
sity 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
84
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 prod-
ucts 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., fac-
tors 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 ques-
tion. 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:
Table 2. Factors and indicators in the SUS local practice context
Factor Indicator Origin
New BPO product Annual strategy document for SUS SIV management
informal discussions
Changed work procedure new process description SUS management
changed instructions for knowledge workers SUS process owner
changes in agreements with client SUS management
For both factors identified, the table shows that there might be several sources indi-
cating 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 ([28]). The
identified factors would match to context sets in CDT, the indicators to context ele-
ments. For the indicators, we would in a next step have to identify operationalizations
in term of machine-detectable operational indicators. An example would be new work
steps (detected by, e.g., a text analysis routine) in the document defining the instruc-
tions for knowledge workers by the SUS process owner. Such an operational indicator
corresponds to context indicators in CDT. However, the variation points and variation
aspects that normally are part of a CDT context model could not be identified as this
would require detailed descriptions of the processes performed in the local practice.
85
Thus, one conclusion from the feasibility study is that the process-oriented viewpoint
of CM is not sufficient and has to be complemented by additional perspectives, like
role or responsibility-oriented viewpoints. Another conclusion is that the basic idea of
analyzing variations and identifying their reasons seems to be promising.
6 Summary and Conclusions
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 dif-
ferent 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. Fur-
thermore, 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.
References
1. van der Aalst, W.M.P., ter Hofstede, A.H.M., Weske, M.: Business Process Management: A
Survey. In: van der Aalst, W.M.P., ter Hofstede, A.H.M., Weske, M. (eds.) Business Process
Management, Int. Conf., BPM 2003, Eindhoven, the Netherlands, June 26-27, 2003, Proc.
LNCS, vol. 2678, pp. 1–12. Springer (2003)
2. Anastassiu, M., Santoro, F.M., Recker, J., Rosemann, M.: The quest for organizational flex-
ibility: driving changes in business processes through the identification of relevant context.
Business Process Management Journal 22(4), 763–790 (2016)
3. Barjis, J.: Collaborative, Participative and Interactive Enterprise Modeling. In: Filipe, J.,
Cordeiro, J. (eds.) Enterprise Information Systems, 11th Int. Conf., ICEIS 2009, Milan, Italy,
May 6-10, 2009. Proc. LNBIP, vol. 24, pp. 651–662. Springer (2009)
86
4. Bernus, P., Mertins, K., Schmidt, G. (eds.): Handbook on Architectures of Information Sys-
tems. Int. Handbooks on Information Systems, Springer (1998)
5. Berzisa, S., Bravos, G., González, T.C., Czubayko, U., España, S., Grabis, J., Henkel, M.,
Jokste, L., Kampars, J., Koç, H., Kuhr, J.C., Llorca, C., Loucopoulos, P., Pascual, R.J., Pas-
tor, O., Sandkuhl, K., Simic, H., Stirna, J., Valverde, F.G., Zdravkovic, J.: Capability driven
development: An approach to designing digital enterprises. Business & Information Systems
Engineering 57(1), 15–25 (2015)
6. Briggs, R.O., Vreede, G.J.d., Nunamaker, J.F.: Collaboration Engineering with Thinklets to
Pursue Sustained Success with Group Support Systems. Journal of MIS 19(4), 31–63 (2003)
7. Corradi, G., Gherardi, S., Verzelloni, L.: Through the practice lens: where is the bandwagon
of practice-based studies heading? Management learning 41(3), 265–283 (2010)
8. Delfmann, P., Herwig, S., Lis, L., Stein, A., Tent, K., Becker, J.: Pattern specification and
matching in conceptual models - a generic approach based on set operations. Enterprise
Modelling and Information Systems Architectures 5(3), 24–43 (2010)
9. Dey, A.K.: Understanding and using context. Personal and ubiquitous computing 5(1), 4–7
(2001)
10. Faller, H., de Kinderen, S., Constantinidis, C.: Organizational Subcultures and Enterprise
Architecture Effectiveness: Findings from a Case Study at a European Airport Company. In:
Proc. of the 49th Hawaii Int. Conf. on System Sciences (HICSS), Kauai, Hawaii (2016)
11. Fellmann, M., Zarvic, N., Metzger, D., Koschmider, A.: Requirements Catalog for Business
Process Modeling Recommender Systems. In: Thomas, O., Teuteberg, F. (eds.) Smart Enter-
prise Engineering: 12. Internationale Tagung Wirtschaftsinformatik, WI 2015, Osnabrück,
Germany. pp. 393–407 (2015)
12. Fill, H.G., Karagiannis, D.: On the Conceptualisation of Modelling Methods Using the
ADOxx Meta Modelling Platform. EMISA 8(1), 4–25 (2013)
13. Groenewegen, J., Hoppenbrouwers, S.J.B.A., Proper, H.A.: Playing ArchiMate Models. In:
Bider, I., Halpin, T.A., Krogstie, J., Nurcan, S., Proper, H.A., Schmidt, R., Ukor, R. (eds.)
Enterprise, Business-Process and Information Systems Modeling – 11th Int. Workshop (BP-
MDS 2010) and 15th International Conf. (EMMSAD 2010) held at CAiSE 2010. LNBIP,
vol. 50, pp. 182–194. Springer, Tunis, Tunesia (June 2010)
14. Grönroos, C., Ravald, A.: Service as Business Logic: Implications for Value Creation and
Marketing. Journal of Service Man. 22(1), 5–22 (2011)
15. Gutschmidt, A., Sandkuhl, K., Borchardt, U.: Multi-touch table or plastic wall? design of
a study for the comparison of media in modeling workshops, leipzig, germany, july 6-8,
2016, revised papers. In: Abramowicz, W., Alt, R., Franczyk, B. (eds.) Business Information
Systems Workshops - BIS 2016 International Workshops, Leipzig, Germany, Revised Papers.
LNBIP, vol. 263, pp. 123–135. Springer (2017)
16. Hornecker, E., Buur, J.: Getting a grip on tangible interaction: a framework on physical space
and social interaction. In: Proc. of the SIGCHI conference on Human Factors in computing
systems. pp. 437–446. ACM Press, New York, New York (2006)
17. Ishii, H.: Tangible bits: beyond pixels. In: Proc. of the 2nd international conference on Tan-
gible and Embedded Interaction (2008)
18. Koç, H.: Methods in designing and developing capabilities: A systematic mapping study
conference, poem 2015, valencia, spain, november 10-12, 2015, proceedings. In: Ralyté, J.,
España, S., Pastor, O. (eds.) The Practice of Enterprise Modeling - 8th IFIP WG 8.1. Working
Conference, PoEM 2015, Proceedings. LNBIP, vol. 235, pp. 209–222. Springer (2015)
19. Luff, P., Hindmarsh, J., Heath, C.: Workplace studies: Recovering work practice and inform-
ing system design. Cambridge university press (2000)
20. Mintzberg, H., Raisingham, D., Théorêt, A.: The Structure of Unstructured Decision Pro-
cesses. Administrative Science Quarterly 2(21), 246–275 (1976)
87
21. Nabukenya, J., van Bommel, P., Proper, H.A.: A Theory-Driven Design Approach to Collab-
orative Policy Making Processes. In: Proc. of the 42nd Hawaii Int. Conf. on System Sciences
(HICSS-42), Los Alamitos, Hawaii. IEEE Computer Society Press (2009)
22. Nakakawa, A., van Bommel, P., Proper, H.A.: Definition and Validation of Requirements for
Collaborative Decision-Making in Enterprise Architecture Creation. Int. Journal of Cooper-
ative Information Systems 20(1), 83–136 (2011)
23. Op ’t Land, M., Proper, H.A., Waage, M., Cloo, J., Steghuis, C.: Enterprise Architecture –
Creating Value by Informed Governance. Enterprise Engineering Series, Springer (2008)
24. Proper, H.A., Winter, R., Aier, S., de Kinderen, S. (eds.): Architectural Coordination of En-
terprise Transformation. Enterprise Engineering Series, Springer (2018)
25. Reschenhofer, T., Bhat, M., Hernandez-Mendez, A., Matthes, F.: Lessons learned in aligning
data and model evolution in collaborative information systems. In: Proceedings of the 38th
International Conference on Software Engineering Companion. pp. 132–141 (2016)
26. Rouwette, E.A.J.A., Vennix, J.A.M.: System Dynamics and Organizational Interventions.
Systems Research and Behavioral Science 23, 451–466 (2006)
27. Sandkuhl, K., Stirna, J., Persson, A., Wißotzki, M.: Enterprise Modeling: Tackling Business
Challenges with the 4EM Method. Springer (2014)
28. Sandkuhl, K., Stirna, J.: Capability Management in digital Enterprises. Springer (2018)
29. Schaub, F., Könings, B., Weber, M.: Context-adaptive privacy: Leveraging context awareness
to support privacy decision making. IEEE Pervasive Computing 14(1), 34–43 (2015)
30. Spohrer, J., Maglio, P.P., Bailey, J., Gruhl, D.: Steps Toward a Science of Service Systems.
IEEE Computer 40(1), 71–77 (January 2007)
31. Stirna, J., Persson, A.: Ten Years Plus with EKD: Reflections from Using an Enterprise Mod-
eling Method in Practice. In: Proper, H.A., Halpin, T.A., Krogstie, J. (eds.) Proc. of the 12th
Workshop on Exploring Modeling Methods for Systems Analysis and Design (EMMSAD
2007), held in conjunction with the 19th Conf. on Advanced Information Systems (CAiSE
2007). pp. 97–106 (2007)
32. Vargo, S.L., Lusch, R.F.: Institutions and axioms: an extension and update of service-
dominant logic. Journal of the Academy of Marketing Science 44(1) (January 2016)
33. Wagter, R., Proper, H.A., Witte, D.: Enterprise Coherence Governance in the Public Sector.
In: Proc. of the 15th IEEE Conf. on Business Informatics (CBI 2013). pp. 117–124. IEEE
Computer Society Press (2013)
34. Yin, R.K.: Case Study Research – Design and Methods. Sage Publications, London, United
Kingdom, 4th edn. (2009)