# Requirements for Observing, Deciding, and Delivering Capability Change

Georgios Koutsopoulos, Martin Henkel, Janis Stirna

► To cite this version:

Georgios Koutsopoulos, Martin Henkel, Janis Stirna. Requirements for Observing, Deciding, and Delivering Capability Change. 12th IFIP Working Conference on The Practice of Enterprise Modeling (PoEM), Nov 2019, Luxembourg, Luxembourg. pp.20-35, 10.1007/978-3-030-35151-9_2. hal-03231358

HAL Id: hal-03231358

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

Submitted on 20 May 2021

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
Requirements for observing, deciding, and delivering
capability change

Georgios Koutsopoulos, Martin Henkel and Janis Stirna

Department of Computer and Systems Sciences, Stockholm University, Stockholm, Sweden
{georgios,martinh,js}@dsv.su.se

**Abstract.** Dynamic business environments create the need for constant change in modern enterprises. Enterprise transformation is associated to changes in enterprise capabilities since capabilities are an essential element in business designs. Capability modeling methods need to evolve accordingly and the development of such methods needs to be systematic. This study, as part of a Design Science project, aims to elicit requirements for a capability modeling method for addressing change. Literature sources and a case study at a healthcare organization that undergoes several changes are used to elicit requirements. The requirements are presented in the form of a goal model for the method under development.

**Keywords:** Capability, Enterprise Modeling, Adaptation, Transformation

# 1 Introduction

The degree of dynamism in business environments is on the rise, leading to organizations constantly trying to adapt according to situations existing in their external or internal environment. Organizations struggling to “catch-up” is a common phenomenon and the distance is only going to be amplified as the organizations’ rate of change is usually lower than their environment’s [1]. Therefore, in the area of Information Systems (IS), a challenging task has emerged in the form of providing support methods and tools for the organizations facing constant change. As a response to this situation, various methods have been developed, for example [2, 3] in order to support the adapting organizations in their constantly changing needs.

Enterprise Modeling (EM) is a discipline that has attempted to tackle the abovementioned challenge in various ways. It captures organizational knowledge and provides the necessary motivation and input for designing IS [4]. In addition, the notion of capability has emerged in IS engineering as an instrument for context-dependent design and delivery of business services [5]. Capability modeling is one specific area of EM that utilizes the concept of capability. Capabilities are an important aspect of enterprises, since they encompass the majority of the concepts relevant to change, such as, goal, decision, context, process, service, and context [5, 6].

In a way similar to any method supporting enterprise transformation, modeling methods need to evolve as well, in order to improve the organizations' ISs. Capability
modeling should therefore evolve accordingly, improving not only the way capabilities are implemented during design phase of the system, but also adjustments and changes performed during run-time [5].

This study is part of a research project aiming to provide methodological and tool support for changing organizations by supporting capability modeling within dynamic contexts. It follows the framework of Design Science research [7, 8] and this study concerns the step of the elicitation of requirements for the design artifact, in particular, the envisioned method for capability modeling and analysis. Goals, being a type of requirement [9], are elicited from two different sources, literature and a case study in the public healthcare sector of Sweden, and presented as a goal model for the envisioned method. They can be seen as relevant to any similar approach.

The rest of the paper is structured as follows. Section 2 consists of a brief presenta-
tion of the basic concepts and related literature. Section 3 describes the methods used
for this study. Section 4 presents the requirements elicited from literature. Section 5
introduces the case, along with two specific change implementations and the require-
ments elicited from the case. Section 6 summarizes the elicited requirements in a goal
model. Section 7 presents a discussion of the elicited requirements and section 8 pro-
vides concluding remarks and briefly explains the next steps of this research project.

## 2 Background

EM is defined as the process of the creation of an enterprise model that captures all the enterprise's aspects that are required for a given modeling purpose. A key aspect in EM is the integrated view on the various aspects of the enterprise. An enterprise model therefore consists of a set of interlinked sub-models, each of them focusing on a specific aspect like processes, goals, concepts, business rules [10]. Concerning applicability, EM is applicable for any organization, public or private, or its part.

The focus for *capability modeling* is enterprises ability and capacity to deliver value,
to achieve goals, or to sustain a long term function. The importance of capabilities lies
in the fact that it assists a holistic view of the enterprise since it encompasses several
aspects due to the association of the concept with several key concepts such as goals,
business services, processes, actors, environment. EM has been used to depict enter-
prise capabilities in several ways including stand-alone modeling approaches like
VDML (Value Delivery Modeling Language) [11] and CDD (Capability-Driven De-
velopment) [5]. Several Enterprise Architecture (EA) frameworks include the concept
of capability and offer capability viewpoints. Popular EA frameworks that include ca-
pability modeling are (i) Department of Defense Architecture Framework (DoDAF)
[12], (ii) NATO Architecture Framework) (NAF) [13], (iii) Ministry of Defence Archi-
tecture Framework (MODAF), and (iv) Archimate [14]. There have also been research
contributions that provide suggestions on how to model capabilities based on existing
modeling methods like i* [15] or Capability Maps [16] or introducing new notations
like CODEK [2] to include the elements required to capture how a capability can
change or be changed in dynamic environments.
# 3 Methods

This study belongs to a project elaborated within the Design Science paradigm, in particular, following the guidelines of [7], according to which a method is considered a design artifact. As with any other artifact, a capability modeling method needs to be scoped and have requirements defined for it. The activity aims to answer the question “What artifact can be a solution for the explicated problem and which requirements on this artefact are important for the stakeholders?” [7]. In this study, the defined requirements concern the method and not the case since the method developer is considered as the stakeholder and not the case study’s organization’s stakeholders. Thus, the task performed is defining requirements for the method; not for the included use case. The requirements for a method for modeling changing capabilities have been elicited by using a *literature review* and a *case study* and visualized as a *goal model*.

## 3.1 Literature review

In an earlier study [17], a literature review concerning capability meta-models was conducted. The papers identified in that study are useful for this study as well, often including requirements for modeling capability changes. A part of that study was to identify papers using a snowballing technique on the initial set of papers that was identified through systematic literature review. Several of the papers that were excluded during snowballing for not including a meta-model have been deemed useful to include in this study as a means to identify capability change requirements. The requirements were either directly extracted from papers related to capabilities or indirectly from papers that addressed issues related to change and enterprise information. In the former case, the requirements for capability change were identified using observation, decision support and delivery as the main change functionalities [17]. In the latter, the requirements concerning change were identified in the related papers and were associated to enterprise capabilities.

## 3.2 Case study

The case study was performed at a regional public healthcare organization, which we refer to as RH, responsible for healthcare provision in a Swedish county. The organization desired to remain anonymous, therefore, its real name is not published, along with the names of any collaborating companies. The studied part was the organization's capability to provide its residents with healthcare guidance via phone. To get information about what kind of change request the organization needs to handle, a number of meetings were held. The following activities took place in iterations.

*Unstructured group interviews* were used to identify change requests that the RH Guidance service had received recently. For this, four meetings were held, initially engaging two experts/strategists at RH, and the last three sessions involving one.

*Workshops* were held to identify the main actors and their relationships, this resulted in the creation of a value network model; three workshops were held.
*Document studies* were performed to study the current documentation of the capa-
bility under study.

For the analysis of how the identified change request would impact the organization, an *experiential approach* [18] was applied. That is, for each identified change request the interviewers also asked the experts to identify the potential change impact.

3.3 Requirements – Goal Modeling

The activity of defining requirements is associated to Requirements Engineering (RE).
The aim of RE is to change the current reality by defining briefly and precisely the
essence of the desired change [9]. In other words, it defines a goal but not how the goal
should be fulfilled. The core activities of RE are (i) elicitation, which concerns the
identification of requirements from relevant sources which are also identified during
this activity, (ii) documentation of the identified requirements and (iii) negotiation,
which concerns the identification and resolution of any possible conflicts. Two more
cross-sectional activities are validation and management. The result of the process is a
set of goals, scenarios or solution-oriented requirements which are generally known as
requirement artifacts and comprise a requirements specification.

Various research methods can be applied to define requirements for an artifact like
survey, action research, observation, case study, interview and document studies. In
this study, literature review and case study are the two methods employed. The overall
requirements are expressed in the form of a goal model. Goal, as a type of requirement
artifact [9], is defined as a desired state of affairs that needs to be attained [10]. Goals
are often refined into sub-goals forming a goal hierarchy.

The goal model in this study has been developed using the “For Enterprise Model-
ing” (4EM) method [10]. The available components in a 4EM Goals Model are goal,
problem, cause, constraint and opportunity, however, the model in this study consists
only of goals. Regarding the design of the model, the 4EM modeling toolkit used for
creating the 4EM Goals Model has been developed in the University of Rostock using
the ADOxx meta-modeling platform.

4 Requirements from Literature Review

This study is a continuation of a capability literature review [17], from which the ma-
jority of the requirements for capability change have been derived. That study involved
the development of a framework that facilitated the classification of change concepts
in the current literature. The main classification found was the division of key concepts
into three functionality parts: (i) observation, (ii) support change decision and (iii) de-
livery [17]. These three should be the main concerns for a method.

The *observation* part directly refers to the context of the organization and its capa-
bilities. Observing context has been identified as an essential element of change in sev-
eral studies concerning capabilities and/or change [19–21]. What has also been empha-
sized is that the context that is relevant to an organization and its capabilities remains
unclear, therefore, effort is needed to identify which contextual factors are relevant to
a capability’s performance [22]. Indirectly, these factors are also affecting whether a capability change is needed and thus should be taken into consideration for inclusion by a capability change method developer. Another part that concerns the context observation is the functional differentiation between a system monitoring itself and the environment [23, 24], or in other words, the internal and external context. This fact is another requirement for a capability change. Finally, any identified relevant contextual factors need to be measured [5], therefore, these factors need to be associated to Key Performance Indicators (KPIs). KPIs are the way to monitor capability performance and fulfillment of the enterprise. If the goal model does not include ways to measure the goals, KPIs need to be established [10]. Summarizing, the identified goals that are associated to observing are 2, 9 and 12-15 as shown in Table 1.

Regarding *supporting change decisions*, the decision needs to be associated to a set of criteria [17, 24], for example, rules and constraints [21] that need to be identified prior to not only the decision, but also the processing and analysis of the relevant data captured through observation. This analysis of captured context data needs to be addressed by the method as well, for example with algorithms that monitor the need for adjustments [25]. Regarding the decision itself, it may concern selecting among existing variants or alternatives [19–21, 24] or deciding on the development of an existing alternative. A capability change method is required to provide support for the identification of existing or new capability alternatives that can efficiently produce the same valuable outcome employing variable delivery behaviors. Finally, since capabilities aim to fulfil intentions, a decision needs to comply with these intentions. Goals, objectives, needs, business requirements, desires states etc. are different concepts of intentions [17] that the decision needs to comply with. Table 1 includes goals 3 and 5-8 that have been identified through these findings and are associated to decision support.

The last part of capability change that the method is required to address is the *delivery* of the capability. Initially, this concerns both the delivery of the capability and the delivery of any change to the capability, or, in other words, the delivery of the transition from an as-is state of a capability to a desired to-be state. Also referred to as transformation or adjustment [5], it may have several forms. A new capability can be introduced or an existing capability can be modified or retired. This is in line with [26], with replacing the concept of maintenance with modification in order to reflect the change to a capability. A significant finding in capability and change delivery literature is the association between capability and resource. Besides the fact that the concept of resource is the most commonly encountered concept in existing capability modeling approaches [17], it has also been associated to capabilities in several studies like [19, 27–29]. Several ways to associate the two concepts have been suggested, for example, as a constraint, but the most common type is that a capability consists of resources. The combination of these resources along with the information describing the relationships and capacities of the resources comprise the capability configuration. In addition, capabilities are also interrelated [17]. Therefore, the method artifact under development needs to address the capability configuration and the allocation of resources to capabilities along with the architecture of capabilities within an enterprise. Based on these findings, goals 4, 10, 11 and 16-20 are associated to capability delivery.
Table 1 summarizes the goals for the capability change modeling method that were elicited from the literature review.

<table><caption>**Table 1.** Goals elicited from the literature review.</caption><thead><tr><td>No</td><td>Name</td><td>Description</td></tr></thead><tbody><tr><td>1</td><td>To manage capability change</td><td>Changing an enterprise capability is the primary goal of the method as a response to the ever-changing environment of the enterprise.</td></tr><tr><td>2</td><td>To observe business context</td><td>Considering the organization as a system, the environment of the system needs to be monitored to increase awareness of the factors that significantly affect changes.</td></tr><tr><td>3</td><td>To support decision on capability change</td><td>Deciding whether a change is needed and how it should be performed is an essential part of any change process. The method should support decision making about change of enterprise capabilities.</td></tr><tr><td>4</td><td>To manage capability delivery</td><td>The method should support capability delivery. A capability may be delivered by several activities that need to be analyzed.</td></tr><tr><td>5</td><td>To identify decision criteria</td><td>Any decision on a capability change needs to be based on a structured set of relevant criteria. The method should support its identification.</td></tr><tr><td>6</td><td>To identify capability alternatives</td><td>The method should support identification of alternative capability configurations during design time, or new alternatives identified through monitoring the capability delivery at run-time.</td></tr><tr><td>7</td><td>To analyze observed context data</td><td>The data captured from the environment need to be analyzed and processed according to the factors relevant to the change. The method should support these activities.</td></tr><tr><td>8</td><td>To ensure that decision complies with intentions</td><td>Intentional elements reflect the goals that a capability fulfills. The method should facilitate the inclusion of relevant intentional elements in the decision towards a capability change.</td></tr><tr><td>9</td><td>To elicit internal and external business context</td><td>It is important to identify which contextual factors are affecting the capability so that they can be monitored properly.</td></tr><tr><td>10</td><td>To manage transition delivery</td><td>The method should support addressing the change to an existing capability and to introduce an entirely new way to deliver.</td></tr><tr><td>11</td><td>To manage capability architecture</td><td>The capabilities associated to a capability, along with their relationships of various types need to be modeled in order to facilitate positioning the capability and identify the change's impact.</td></tr><tr><td>12</td><td>To observe external business context</td><td>Decomposing goal no2, it is important to support the enterprise's awareness of its external dynamic environment and the factors that affect its capabilities.</td></tr><tr><td>13</td><td>To observe internal business context</td><td>There is great value in monitoring the internal environment of the enterprise systematically to identify possible required changes and their possible impact. The method should facilitate this task.</td></tr><tr><td>14</td><td>To measure relevant properties</td><td>Not only measuring but also identifying the external and internal properties that are relevant to an existing or incoming capability's performance is essential to assess whether a change is needed or not, and this needs to be addressed by the method artifact.</td></tr><tr><td>15</td><td>To establish KPIs</td><td>KPIs are an established approach to evaluate performance. The method should include associating the capability's relevant properties to KPIs.</td></tr><tr><td>16</td><td>To manage introduction of a new capability</td><td>A significant characteristic of a changing enterprise is introducing new capabilities that aim to address emerging needs derived and affected from dynamic factors of the enterprise's environment. This goal refers to the introduction of using a configuration that produces a new capability.</td></tr></tbody></table>
<table><tr><td>17</td><td>To manage retirement of existing capability</td><td>Outdated or harmful enterprise capabilities need to be removed [30]. The sustained existence of an outdated capability may hinder the delivery of other capabilities, therefore, it should be removed. The method should support the retirement of an organization's capabilities.</td></tr><tr><td>18</td><td>To manage modification of existing capability</td><td>Modifying a capability refers to changing the way an existing outcome is delivered. In other words, a new configuration that delivers an already existing outcome. The method aims to facilitate this process.</td></tr><tr><td>19</td><td>To manage capability configuration</td><td>Capabilities consist of various resources of different types like material resources, human resources, time etc. The method should support configuring a capability as a structured set of resources.</td></tr><tr><td>20</td><td>To allocate resources to capability</td><td>Based on the configuration of the capability, the allocation of resources may support enabling a potential and turning it into a capability. Thus, it is important for a capability change method to assist in the association of resources to a capability.</td></tr></table>

# 5 Requirements from the Case Study

## 5.1 Case Overview

RH is a public organization that is responsible for healthcare in a Swedish county. One of the organization's capabilities is to provide healthcare advice via phone to any resident and visitor of the county. The task is performed by specially trained professional nurses. They are being supported by specialized software that incorporates various information sources. The abovementioned capability is known by the 4-digit phone number used by the persons contacting the nurses, namely 1177. The strategic goal of 1177 is to reduce the workload of other healthcare organizations by filtering the cases that are not in urgent need of physicians' attention and support these cases by providing useful advice.

RH owns 1177, however, several collaborating public and private organizations are involved by providing resources for it. Being inter-organizational, the configuration of the capability is complex. The complex configuration results in any proposed change in the capabilities of RH to require an in depth analysis of which parts will be affected and how. There are changes proposed that not only affect what is being done but also influence the collaborations with partner organizations in the form of needed or existing contractual agreements.

RH and its capabilities associated to 1177 constantly change. The driving forces for change come both via top-down and bottom-up developments. The top-down perspective is associated to politicians pushing for reforms not only to improve overall quality but also to facilitate the residents using the service and reduce costs. The bottom-up perspective concerns changes proposed by the employees and partners involved in the delivery of the capabilities. In addition, the capability needs to be updated because of new technological developments, for example, the desire to use video calls.

Any incoming change request involves an analysis to determine its effects. The method artifact developed needs to address all the relevant aspects. In order to assist the elicitation of requirements for the method, two recent change requests have been selected, (i) an improvement in the guidance support that enables the responding nurses
to guide the callers directly to a healthcare provider by assessing their symptoms and (ii) enabling the nurses performing health guidance to book times directly at local emergency clinics. These two change requests have been selected because they include both internal improvements that the callers may be unaware of, as in case 1, and external improvements that affect external partners that the callers are in contact with, as in case 2. Both cases, which are explained in detail below, concern changes affecting external parties and IT systems.

## 5.2 Change Case 1: Guidance Support Improvement

The nurses are using a Guidance support system while handling a caller's case. The system has been developed and is being used nationwide. The caller states existing symptoms and the system presents possible sub-symptoms to the nurse. Different levels of emergencies are handled in different manners, from advising on self-treatment, which is also included in the system, to calling an ambulance or suggesting a healthcare provider. A part of the system provides the nurses with a catalogue of healthcare providers. The provider catalogue is developed and maintained by a private provider, in comparison to the guidance system, which is developed by a national public provider.

An improvement that has been proposed is to associate each provider in the catalogue to a specific set of symptoms that the provider is likely to handle. In this way, the callers can be directed to a provider without the need to reach a diagnosis of their situation in advance. On the contrary, the diagnosis part is skipped and a relevant provider is identified directly through stated symptoms. There are multiple benefits from this improvement. Initially, the delivered service is improved since the patient is guided to providers with the best expertise. In addition, the capability becomes more efficient in terms of cost and effort, along with the fact that there is better use of human resources, especially physicians, who can spend time on handling only the cases that are really relevant to their expertise. While this research project was running, a group of expert physicians had already been formed and started mapping providers to symptoms. The idea was to create a web system that can be used directly, and an XML file containing symptoms and providers that could be used in other systems.

## 5.3 Change Case 2: Time Booking at Emergency Clinics

Another proposed change for RH concerns the 1177 capabilities' direct association to the actual healthcare providers, and in particular, to the local emergency clinics which are also governed by RH. These clinics are meant to treat acute, yet, not life-threatening health problems. For example, they can treat severe allergic reactions, bone fractures or concussions. A resource that is worth noting is the journal system used in the local clinics, developed by a private journal system provider, since it is the one that needs to be accessed by the nurses. More specifically, it has been proposed that 1177's nurses should be enabled to book time slots in emergency clinics while handling acute cases. To date, the nurses can only suggest a clinic to the caller if they estimate that the clinic can handle the case. This change will benefit not only the callers, providing the convenience of having a booked time which also increases the feeling of safety, but also
the main emergency units of major hospitals, whose workload will be reduced by di-
recting less severe cases to the local clinics. In addition, it improves RH's ability to
control the flow of the patients, directing them through the booked timeslots to the
clinics with the shortest queue at the moment.

**5.4 Analysis of Changes**

This section discusses how the changes related to the three areas of capability change: observation, decision, and delivery relate requirements in the literature.

Concerning the impetus for changing the capabilities is the RH ability to perform
*observation*, which can be seen as related to detecting changes in political, social, tech-
nological and economic factors. This is an important fact regarding monitoring of ca-
pability context because it provides initial guidelines concerning the selection of con-
textual factors that should be monitored to identify needed changes or possibilities for
improvement. In addition, the contracts needed to perform the changes, as discussed
below, also require monitoring the legal context of the organization and the capability.
To measure the capability delivery, RH has a number of KPIs established that measures
for example the number of residents that ask for guidance. Goal 28 was derived from
these findings.

Regarding the *decision* on capability change in the case, it can be concluded that an
important aspect in the two changes was the ownership of capabilities and associated
resources. An important finding from the first change is that the ownership of the ca-
pability and the resources is significant for the configuration of the capability, along
with any included tasks that have been outsourced. Developing new resources as part
of the changes requires using existing resources owned by different organizations. For
example, developing the symptom-provider system relies on data from the provider
catalogue, owned by the private provider, and the expert group, owned by RH. The
developed system and XML will in return, feed data to the provider catalogue system.
A potential source of conflict and problems lies in the fact that an organization that
collaborates with external partners to improve the efficiency of its services needs to
have clear organizational boundaries set. This was derived from the case concerning
the interactions and agreements among RH, the private provider and the national public
provider in the first change, and RH, the journal system provider and the local emer-
gency clinics in the second one. Using an external organization's resources or outsourc-
ing tasks requires clearly stated boundaries set in the form of informal agreements or
formal contracts. This will provide certain control over the cross-organizational config-
uration of the capability. The method should provide support for this type of capabilities
and should assist the identification of resource ownership and contact points, either
manual or automated, for example in APIs. An additional finding is that configuring a
capability through a resource allocation supports the identification of alternatives. That
is, reallocating resource sets may enable an existing potential and turn it into a new
capability or alternative. The important association between goals 6 and 19 was identi-
fied based on these findings, along with the complementary goals 21-28.

Regarding the *delivery* of changes in the case it could be observed that the first
change is a capability modification. Existing resources will be used in different ways
to create new resources, and improve the delivery process, without changing the final outcome that is delivered, since it will be still fulfilling the same goal. The second change is a case of introducing a new capability. Even though the resources allocated to the capability are already existing, a new goal has been set and the delivered value is new. Both cases concern the reuse of resources in different manners. Goals 21-28 are also associated to delivery findings.

Considering the interrelated capabilities, it is important to identify new resources, like the symptom-provider system, created through the capability delivery and to take into consideration the needed resources, not only to develop the new resources, but also to maintain it. That may be a way to identify new capabilities.

## 5.5 Requirements

A summary of the goals elicited through the RH case are shown in table 2. They complement the goals elicited from literature, therefore the numbering continues.

<table><caption>**Table 2.** Additional goals elicited from the case study.</caption><thead><tr><td>Goal</td><td>Name</td><td>Description</td></tr></thead><tbody><tr><td>21</td><td>To specify capability ownership</td><td>The ownership of the capability facilitates positioning a capability within its ecosystem. The method should support identifying which actor, organization, unit etc., owns the given capability.</td></tr><tr><td>22</td><td>To specify resource ownership</td><td>The ownership of resources may be different than the ownership of the capability they are associated with and allocated to. This is common for inter-organizational capabilities. The method should address the possible ownership conflicts and their resolution.</td></tr><tr><td>23</td><td>To manage internal resources</td><td>In comparison to the external resources that can only be identified, the internal resources of the organization can also be managed and assigned to one or more capabilities.</td></tr><tr><td>24</td><td>To identify external resources</td><td>External resources associated to a capability may not be owned by the same organization as the capability. Identifying them defines resource ownership and the method should support it.</td></tr><tr><td>25</td><td>To identify outsourced tasks</td><td>Capabilities are associated to tasks as components of processes that deliver the capabilities. Inter-organizational capabilities include tasks that have been outsourced to external collaborators. The method should support their identification.</td></tr><tr><td>26</td><td>To support defining organizational boundaries</td><td>Task and resource ownership identification is associated to the limits of the organizations, also known as organizational boundaries. The method artifact should include their definition.</td></tr><tr><td>27</td><td>To identify collaborating organizations</td><td>Organizations providing resources allocated to a capability should be identified as part of the capability's and organization's ecosystem. The method should facilitate capability configuration.</td></tr><tr><td>28</td><td>To monitor political, economic, social, technological and legal context</td><td>Political, economic, social, technological and legal contextual factors are important for the elicitation of the context, which is relevant to a capability's performance.</td></tr></tbody></table>
# 6 Goal Model for Capability Changes

The requirements for business capability change are expressed in the form of a goal model using the 4EM approach. Figure 1 depicts the Goals model that integrates goals elicited from both sources used in this study.

<figure><img src="image_2.png" /><figcaption>Fig. 1. The 4EM Goals model for capability change.</figcaption></figure>
The main goal 1 in the model is managing capability change. It is refined in goals 2-4 reflecting the three main functionalities, observation, decision support and delivery. Observation, in return, is refined into goals 12 and 13, distinguishing between the internal and external context that needs to be observed and supported by goal 9, the elicitation of the context to observe. Goal 14, which concerns measurement, supports goals 12 and 13 and is supported by goal 15, which concerns establishing KPIs to facilitate measurement. Goal 9 is supported by goal 28 depicting specific context fields that can assist the elicitation of contextual factors. Decision support is supported by goals 5-8, which depict the analysis of context data, the identification of decision criteria and capability alternatives, and ensuring that the decision complies with intention elements. Finally, delivery is supported by goals 10, 11 and 19, depicting management of transition delivery, capability architecture and capability configuration accordingly. Goal 19 also supports goal 6. Goal 10 is refined into goals 16-18 to depict the different categories of transition, which are the introduction of a new capability and the modification or retirement of an existing capability. Goal 19 is supported by goal 20, allocating resources to a capability. It is, in return, supported by goals 22-24, that depict the specification of resource ownership, the identification of external resources and management of internal resources. Goal 22 is also supporting goal 21 and goal 24 is supporting goal 22. Goal 22 is supported by goals 25-27 which concern the identification of outsourced tasks, supporting the definition of organizational boundaries and the identification of collaborating organizations accordingly.

Visually, the model consists of two parts. The upper part, which includes the goals elicited through the literature review, and the lower part, which includes the goals that were elicited from the case study and complement the initial set. The red dashed line depicts the border between the two sets of goals.

# 7 Discussion

The two sources of requirements for the method under development have provided requirements that were not only consistent, but also complementary to each other. The fact that the initial set of literature requirements are not all included in the case study requirements does not mean that they do not exist. On the contrary, the majority of requirements are overlapping. This applies to several goals from the literature. For example, in the case study, the need to monitor specific contextual fields, i.e. political, social, economic, technological and legal fields, supports the more generic goal found in the literature; to observe the business context. Therefore, the initial goal of the need to perform observations is present in the case. Even though there has been no explicit mention of the observation part, there were implications of different sources of observed data that motivated change requests. For example, there was political influence and pushing from employees to improve the service and reduce costs using new technologies. Additionally, the attributes of any relevant method supporting observation like PESTLE analysis [31] which seems highly consistent with this study's findings, should be taken into consideration.
The two change requests tackled in the case study have provided the opportunity to elaborate requirements on two types of capability change. Change 1 concerns the modification of an existing capability and change 2 concerns the introduction of a new capability. An interesting observation is that both cases are resolved by the reallocation of existing resources, both internal and external to the organization. This resulted in emphasizing the need for a clear definition of the boundaries of an organization, a task which can be assisted by identifying the resources and tasks that belong to collaborating organizations. Contracts may not be needed in every possible occasion, however, any type of boundary needs to be controlled in order to avoid possible conflicts and problems, even by informal agreements. Any method that aims to support changes and include inter-organizational capabilities should take this into consideration. In addition, as depicted in the goals, there is a significant difference between internal and external resources and tasks. The former can be managed while the latter can only be identified and the method should tackle these specific activities. The goal model has also made possible to emphasize the importance of capability configuration, since it is the only goal that currently supports both decision support and delivery.

A noteworthy fact concerns the increasing frequency of inter-organizational collaborations [32], leading to inter-organizational capabilities, however, the literature sources have not addressed this issue to date. Capability modeling has not elaborated on inter-organizational capabilities and this provides a great opportunity for the method under development to contribute to this part of changing capabilities as well. The inter-organizational capabilities studied in this case can prove as a starting point for researching the behavior of changing inter-organizational capabilities, being private to private, public to public or public to private as in the RH case.

# 8 Conclusion

In this paper, we have elicited requirements for developing a modeling method that uses the concept of capability to manage enterprise transformation in dynamic environments. Reusing the systematic literature review findings of our previous work has provided a set of goals. A case study from a public healthcare organization in Sweden has confirmed the main goals derived from literature and complemented the final set with goals concerning inter-organizational capability changes. The result has been presented in the form of a goal model that integrates all requirements from both sources.

Concerning future work, the requirements elicited from literature need to be practically validated. In addition, the requirements elicited from the case study belong to a single case and should be validated and possibly refined by enterprise transformation practitioners. The goal model presented in this study is the first step of an iterative process that is planned to proceed in the near future. When defining requirements will have been completed, the development of the method will begin.
Acknowledgment

We would like to express our gratitude to the employees of RH who took their time in
letting us interview them to identify and describe the cases presented in the paper.

References

1. Burke, W.W.: Organization change: theory and practice. Sage Publications (2017).

2. Loucopoulos, P., Kavakli, E.: Capability Oriented Enterprise Knowledge Modeling: The CODEK Approach. In: Karagiannis, D., Mayr, H.C., and Mylopoulos, J. (eds.) Domain-Specific Conceptual Modeling. pp. 197–215. Springer International Publishing, Cham (2016).

3. Proper, H.A., Winter, R., Aier, S., de Kinderen, S. eds: Architectural Coordination of Enterprise Transformation. Springer International Publishing, Cham (2017).

4. Persson, A., Stirna, J.: An Explorative Study into the Influence of Business Goals on the Practical Use of Enterprise Modelling Methods and Tools. In: Harindranath, G., Wojtkowski, W.G., Zupančič, J., Rosenberg, D., Wojtkowski, W., Wrycza, S., and Sillince, J.A.A. (eds.) New Perspectives on Information Systems Development. pp. 275–287. Springer US, Boston, MA (2002).

5. Sandkuhl, K., Stirna, J. eds: Capability Management in Digital Enterprises. Springer International Publishing, Cham (2018).

6. Loucopoulos, P., Stratigaki, C., Danesh, M.H., Bravos, G., Anagnostopoulos, D., Dimitrakopoulos, G.: Enterprise Capability Modeling: Concepts, Method, and Application. Presented at the October (2015).

7. Johannesson, P., Perjons, E.: An Introduction to Design Science. Springer International Publishing, Cham (2014).

8. Hevner, A.R., March, S.T., Park, J., Ram, S.: Design Science in Information Systems Research. MIS Quarterly. 28, 75–105 (2004).

9. Pohl, K.: Requirements engineering: fundamentals, principles, and techniques. Springer, Heidelberg; New York (2010).

10. Sandkuhl, K., Stirna, J., Persson, A., Wißotzki, M.: Enterprise Modeling: Tackling Business Challenges with the 4EM Method. Springer, Berlin, Heidelberg (2014).

11. Object Management Group (OMG): Value Delivery Modeling Language, https://www.omg.org/spec/VDML/1.0, (2015).

12. USA Department of Defense: Department of Defense Architecture Framework 2.02, https://dodcio.defense.gov/Library/DoD-Architecture-Framework/, (2009).

13. NATO: NATO Architecture Framework v.4, https://www.nato.int/nato_static_fl2014/assets/pdf/pdf_2018_08/20180801_180801-ac322-d_2018_0002_naf_final.pdf, (2018).

14. The Open Group: Archimate 3.0.1. Specification, https://publications.opengroup.org/i162, (2017).

15. Danesh, M.H., Yu, E.: Modeling Enterprise Capabilities with i*: Reasoning on Alternatives. In: Iliadis, L., Papazoglou, M., and Pohl, K. (eds.) Advanced Information Systems Engineering Workshops. pp. 112–123. Springer International Publishing, Cham (2014).

16. Beimborn, D., Martin, S.F., Homann, U.: Capability-oriented modeling of the firm. Presented at the IPSI Conference, Amalfi, Italy January (2005).

17. Koutsopoulos, G., Henkel, M., Stirna, J.: Dynamic Adaptation of Capabilities: Exploring Meta-model Diversity. In: Reinhartz-Berger, I., Zdravkovic, J., Gulden, J., and Schmidt, R.
(eds.) Enterprise, Business-Process and Information Systems Modeling. pp. 181–195. Springer International Publishing, Cham (2019).

18. Kilpinen, M.S.: The emergence of change at the systems engineering and software design interface, (2008).

19. Běrziša, S., Bravos, G., González Cardona, T., Czubayko, U., España, S., Grabis, J., Henkel, M., Jokste, L., Kampars, J., Koç, H., Kuhr, J.-C., Llorca, C., Loucopoulos, P., Juanes Pas-cual, R., Sandkuhl, K., Simic, H., Stirna, J., Zdravkovic, J.: Deliverable 1.4: Requirements specification for CDD, CaaS-capability as a service for digital enterprises. Riga Technical University. (2013).

20. Fleurey, F., Dehlen, V., Bencomo, N., Morin, B., Jézéquel, J.-M.: Modeling and Validating Dynamic Adaptation. In: Chaudron, M.R.V. (ed.) Models in Software Engineering. pp. 97–108. Springer, Berlin, Heidelberg (2009).

21. Andersson, J., de Lemos, R., Malek, S., Weyns, D.: Modeling Dimensions of Self-Adaptive Software Systems. In: Cheng, B.H.C., de Lemos, R., Giese, H., Inverardi, P., and Magee, J. (eds.) Software Engineering for Self-Adaptive Systems. pp. 27–47. Springer, Berlin, Heidelberg (2009).

22. Zdravkovic, J., Stirna, J., Kuhr, J.-C., Koç, H.: Requirements Engineering for Capability Driven Development. In: Frank, U., Loucopoulos, P., Pastor, Ó., and Petrounias, I. (eds.) The Practice of Enterprise Modeling. pp. 193–207. Springer, Berlin, Heidelberg (2014).

23. Weyns, D., Malek, S., Andersson, J.: FORMS: Unifying reference model for formal specification of distributed self-adaptive systems. ACM Transactions on Autonomous and Adaptive Systems. 7, 1–61 (2012).

24. Morandini, M., Penserini, L., Perini, A.: Towards goal-oriented development of self-adaptive systems. In: Proceedings of SEAMS ’08. p. 9. ACM Press, Leipzig, Germany (2008).

25. Grabis, J., Kampars, J.: Adjustment of Capabilities: How to Add Dynamics. In: Sandkuhl, K. and Stirna, J. (eds.) Capability Management in Digital Enterprises. pp. 139–158. Springer International Publishing, Cham (2018).

26. Henkel, M., Bider, I., Perjons, E.: Capability-Based Business Model Transformation. In: Iliadis, L., Papazoglou, M., and Pohl, K. (eds.) Advanced Information Systems Engineering Workshops. pp. 88–99. Springer International Publishing, Cham (2014).

27. Azevedo, C.L.B., Iacob, M.-E., Almeida, J.P.A., van Sinderen, M., Pires, L.F., Guizzardi, G.: Modeling resources and capabilities in enterprise architecture: A well-founded ontology-based proposal for ArchiMate. Information Systems. 54, 235–262 (2015).

28. Rafati, L., Roelens, B., Poels, G.: A Domain-specific Modeling Technique for Value-driven Strategic Sourcing. Enterprise Modelling and Information Systems Architectures. 13, 1–29 (2018).

29. Loucopoulos, P., Kavakli, E., Chechina, N.: Requirements Engineering for Cyber Physical Production Systems. In: Giorgini, P. and Weber, B. (eds.) Advanced Information Systems Engineering. pp. 276–291. Springer International Publishing, Cham (2019).

30. Koutsopoulos, G.: Modeling Organizational Potentials Using the Dynamic Nature of Capabilities. In: Joint Proceedings of the BIR 2018 Short Papers, Workshops and Doctoral Consortium co-located with 17th International Conference Perspectives in Business Informatics Research (BIR 2018), Stockholm, Sweden, September 24-26, 2018. pp. 387–398 (2018).

31. Law, J.: A dictionary of business and management. Oxford University Press, Oxford [England] ; New York (2009).

32. Ziemann, J., Matheis, T., Freiheit, J.: Modelling of Cross-Organizational Business Processes - Current Methods and Standards. Enterprise Modelling and Information Systems Architectures. Vol 2, 23-31 Pages (2015).