<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Enterprise Engineering for Business Opportunity Recognition - A Design Science Approach</article-title>
      </title-group>
      <contrib-group>
        <aff id="aff0">
          <label>0</label>
          <institution>Johannes Kepler Universität</institution>
          ,
          <addr-line>4040 Linz</addr-line>
          ,
          <country country="AT">Austria</country>
        </aff>
      </contrib-group>
      <fpage>41</fpage>
      <lpage>52</lpage>
      <abstract>
        <p>Recognizing business opportunities in a timely and accurate way is crucial for business operation today. Due to steadily improving technologies in almost all areas relevant for organizations, organizational actors need multifaceted support when digital transformation processes are instantiated, targeting technology utilization for business opportunities. Although initial triggers enable a quick start of transformation processes, requirements evolve over time whenever stakeholders adopt novel organizational practices and technologies to achieve business objectives according to recognized opportunities. Consequently, requirements need to be refined by the time of emergence, and handled step-by-step to implement respective digital transformation steps. For structuring this socio-technical, and thus, complex endeavor, we suggest and introduce a design science approach for methodology development. The initial development step has its focus on relevant knowledge items and relations guiding organizational actors when elaborating on digital transformation processes. Streamlining technology, technical and organizational issues when recognizing transformation potential facilitates the exploration of corresponding business practices.</p>
      </abstract>
      <kwd-group>
        <kwd>Digital Transformation</kwd>
        <kwd>Opportunity Recognition</kwd>
        <kwd>Framework</kwd>
        <kwd>Design Science Research</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>The increasingly dynamic organizational environments resulting of radical societal,
technological and market developments challenge established organizational practices
[1]. The resulting situation has been described as hyper-turbulent market conditions in
which competitive advantages are gained and eroded by market participants capabilities
of reconfiguring organizational resources [2]. Following this context organizational
capabilities focused on enabling this reconfiguration have been of increasing interest for
researchers and practitioners. A focus on specific capability constructs like agility,
ambidexterity or innovation as well as more dynamic approaches towards the concept of
organizational capabilities in general have been described as result as well as driver of
these increasingly turbulent environments [3–5]. Whilst these capability constructs
show differences in their conceptualization, they strongly indicate the necessity for
organizations to obtain capabilities enabling them to react to changed circumstances to
sustainably navigate the turbulent environments they find themselves in.</p>
      <p>The application of technology, information technology (IT) in particular, to gain
competitive advantage can be considered as one of the most volatile and complex
aspects of organizational environments. A variety of research fields investigate the
intersection of traditional aspects of organizational change with digital technologies and
testify to the increasing importance and complexity of integrating technology into
modern organizations. Whilst research interest in the fields of Digital Innovation, Digital
Entrepreneurship or Digital Transformation has skyrocketed in the past years, detailed
reviews of the fields indicate conceptual ambiguity and numerous knowledge gaps [3,
6, 7].</p>
      <p>
        Within organizations the pressure resulting from the complexity of adapting to
shifting technological circumstances changed in a large part by technological developments
challenges established ways of cooperation between technology and domain experts.
Expectations towards the IT departments change from being reactive service providers
towards becoming proactive drivers of IT induced change [
        <xref ref-type="bibr" rid="ref11">8</xref>
        ], roles dedicated towards
the identification and adaption of potentials induced by technologies are introduced [
        <xref ref-type="bibr" rid="ref12">9</xref>
        ],
and strategic concepts are altered to focus on the integration of such potentials at the
highest level of organizational planning [
        <xref ref-type="bibr" rid="ref13">10</xref>
        ]. Whilst such organizational processes
intended to identify potential ways of technology-usage are increasingly established they
have been described as under researched, lacking conceptual underpinnings and
knowledge on involved micro processes [6].
      </p>
      <p>
        Such processes require the integration of diverse technical and organizational
knowledge elements carried by individuals distributed within and outside the
organization and therefore reflect a complex enterprise engineering problem. In a previous study
a description framework for micro processes and knowledge elements involved in
digital transformation opportunity recognition (DTOR) has been developed to reduce
problem complexity [
        <xref ref-type="bibr" rid="ref14">11</xref>
        ]. Yet to support practitioners and collect application experience,
for feasibility testing, a corresponding methodology has to be developed. This paper
describes our approach to designing and developing such a DTOR methodology
thereby expanding on the previous work which solely focused on the provision of a
description framework.
      </p>
      <p>The structure of the paper is as follows: section two presents and motivates the
application of design science research for digital transformation opportunity recognition;
section three further elaborates on our approach for designing and evaluating our
methodology for its capability to feature completeness with respect to content and its
integrative capacity of the presented complex setting through the provision of sharing
cognitive structures; section four concludes the paper reflecting on the presented approach
and presenting an outlook on future research.</p>
    </sec>
    <sec id="sec-2">
      <title>DTOR Methodology Development as DSR Approach</title>
      <p>
        For developing the DTOR methodology, we rely on a design science research (DSR)
approach to integrate relevance and rigor [
        <xref ref-type="bibr" rid="ref15 ref16">12, 13</xref>
        ], but also develop an artefact
iteratively [
        <xref ref-type="bibr" rid="ref17">14</xref>
        ]. In their seminal work, Hevner et al. [
        <xref ref-type="bibr" rid="ref16">13</xref>
        ] discuss that DSR does not only
focus on the design of an artefact, but also integrates relevance and rigor as “truth and
utility are inseparable” [
        <xref ref-type="bibr" rid="ref16">13</xref>
        ]. It has been stated that differentiating routine design from
design science research is important [
        <xref ref-type="bibr" rid="ref16 ref19">13, 16</xref>
        ]. The latter aims at solving existing
problems that occur in reality (e.g., in companies) focusing on people, organizations and
technology [
        <xref ref-type="bibr" rid="ref16">13</xref>
        ]. The solution, hence, contributes to the knowledge in the field [
        <xref ref-type="bibr" rid="ref16">13</xref>
        ].
Focusing on existing, real-world problems is a precondition to fulfill the relevance
requirement of research [
        <xref ref-type="bibr" rid="ref15 ref16">12, 13</xref>
        ]. To meet the requirement of rigor, DSR projects have to
be based on an existing knowledge base, in particular existing foundations and
methodologies [
        <xref ref-type="bibr" rid="ref15 ref16">12, 13</xref>
        ]. By applying the appropriate methodologies based on the identified
foundations, DSR produces a “viable artefact in the form of a construct, a model, a
method, or an instantiation” [
        <xref ref-type="bibr" rid="ref16">13</xref>
        ]. Furthermore, it has been often stated, that creating
artefacts directly depends on underlying kernel theories [
        <xref ref-type="bibr" rid="ref16 ref17 ref20 ref21">13, 14, 17, 18</xref>
        ] as part of the
existing knowledge but also as way to test the artefact [
        <xref ref-type="bibr" rid="ref22">19</xref>
        ]. To apply DSR, methods
and processes are at hand, be there high level design processes [
        <xref ref-type="bibr" rid="ref22 ref23">19, 20</xref>
        ] or more
operational frameworks [
        <xref ref-type="bibr" rid="ref17">14</xref>
        ]. Peffers et al. [
        <xref ref-type="bibr" rid="ref17">14</xref>
        ] provide a method and process of six
activities, defining possible research entry points for DSR as well as likely process iterations.
The six activities include (1) problem identification and motivation, (2) define
objectives of a solution, (3) design and development, (4) demonstration, (5) evaluation, and
(6) communication [
        <xref ref-type="bibr" rid="ref17">14</xref>
        ]. Depending on the initiation or intended solution, the research
entry points relate to activities 1 to 4 [
        <xref ref-type="bibr" rid="ref17">14</xref>
        ]. Consequently, DSR projects based on this
framework do not necessarily cover all activities.
      </p>
      <p>
        We follow a DSR approach for developing the DTOR methodology due to various
reasons. The underlying research problem investigates how organizations are able to
tackle the challenge to identify digital opportunities to stay competitive [2]. To the best
of our knowledge, there is currently no structured model, method or framework to solve
this problem [6]. Hence, and secondly, it is necessary to design and develop a new
artefact, as solving this problem is not possible via routine design [
        <xref ref-type="bibr" rid="ref16 ref19 ref24">13, 16, 21</xref>
        ]. Adopting
a problem-centered approach, the DTOR methodology development starts with the first
activity as defined by Peffers et al. [
        <xref ref-type="bibr" rid="ref17">14</xref>
        ]. We rely on the existing body of knowledge for
safeguarding rigor but also to clarify the contribution of the DTOR methodology [
        <xref ref-type="bibr" rid="ref15 ref16">12,
13</xref>
        ]. Identifying dynamic capabilities as a kernel theory for strengthening theoretical
integration [
        <xref ref-type="bibr" rid="ref17 ref22">14, 19</xref>
        ], our research design foresees iterations on different stages to learn
from demonstration and evaluation for developing a stable artefact [
        <xref ref-type="bibr" rid="ref17 ref24">14, 21</xref>
        ]. Moreover,
each artefact design is challenged by various problem dimensions on different levels as
enabled by DSR [
        <xref ref-type="bibr" rid="ref17 ref22">14, 19</xref>
        ], as the improvement of the problem context evolves along
each design cycle (cf. https://wwwhome.ewi.utwente.nl/~roelw/DSM90minutes.pdf).
2.1
      </p>
      <sec id="sec-2-1">
        <title>DTOR Methodology Development</title>
        <p>
          The design cycle for the proposed DTOR methodology has three dimensions (see Table
1). Many DSR projects focus on developing an artefact such constructs, models,
methods and instantiations [
          <xref ref-type="bibr" rid="ref16">13</xref>
          ]. Due to the complexity of the underlying research problem,
the DTOR methodology integrates a model, consisting of abstractions and
representations, a method referring to algorithms and practices, and instantiations implemented
in or related to the organizations context, i.e. an organization [
          <xref ref-type="bibr" rid="ref16">13</xref>
          ]. Therefore, in the
current state of this research, we identified three problem dimensions on different
levels. For each dimension, in line with Peffers et al. [
          <xref ref-type="bibr" rid="ref17">14</xref>
          ], we distinguished objectives,
artefact design, demonstration and evaluation.
        </p>
        <p>The first problem dimension is nurtured by observations in the business realm and
academic literature. By reviewing the literature, we found some non-integrative and
standalone approaches to tackle DTOR. Concise capturing of constitutive elements and
their relations according to the DTOR process is missing. Identifying and defining such
constitutive elements and a set of their patterns with respect to content is hence the
objective of this dimension. Consequently, the artefact design focuses on a semantic
definition and visibility of constitutive elements and their relations. Demonstration
relies on a case-based approach in a workshop setting conveying semantics and
appearance in a mutually adjusted way providing distributed knowledge elements. Evaluation
considers definition and accuracy of the constitutive elements and their relations, but
also completeness and integration capability (as further described in section 3).</p>
        <p>The next dimension refers to procedural deficiencies of the DTOR process.
Combining the constitutive elements is challenging, as they are distributed among various
knowledge carriers (i.e., people in an organization). Even more, diverse motivations for
DTOR processes (e.g., identifying general opportunities of technologies for the
company vs. identifying specific technologies for a business unit) exist. Thus, we aim at
providing a DTOR process to overcome these challenges. In designing the artefact, we
focus on two different aspects. First, allowing identification of the goal of a specific
DTOR process and ensuring that people involved are able to develop a common
understanding of that goal. Second, we focus on the mapping of settings towards DTOR
process scenarios. Therefore, collaboration features in this context need to part of the
design. For demonstration, we plan developing a process case for a more detailed
procedure. This includes specifying actor roles (e.g., humans, digital services or systems),
activities and functions, data inputs and outputs, as well as the flow of control including
entry and end states in an experimental setting to control for biases. The focus of the
evaluation lays on running the DTOR process from the actor or system perspective and
checking for completeness, structural adequacy and outcome.</p>
        <p>Finally, hindrances when applying DTOR lack methods for problem identification
(i.e., the DTOR process). In addition, they lack structured adoption of non-integrative
standalone approaches with procedural deficiencies for specific organizational
contexts. Hence, we aim at providing some guidance for identification and adoption of
instances of constitutive elements of the DTOR process in an integrative and
organization-specific way. In the artifact design, we focus on a set of principles for instantiating
the DTOR process based on specific organizational context in given scenarios.
Consequently, demonstration relies on a scenario case demonstrating the instantiation,
involving stakeholders from the field, legacy systems and overlaying technologies for rapid
prototyping. The evaluation is similar to the second problem dimension, but with focus
on evaluation completeness of processes in terms of scope, level of detail, structural
adequacy, and outcome.
As presented in section two, the first problem dimension identified with respect to the
proposed DSR approach is the lack of knowledge on such processes’ constitutive
elements and their relations. The individual and collaborative inability to structure the
diverse and numerous elements required for DTOR processes confronts individuals and
organizations with an unstructured and set of distributed and possibly relevant
knowledge elements that requires high migration effort. The complexity of the
challenge “roams free” and reduces the individuals and thereby the organization’s
capability for sensing potential opportunities provided by digital technologies in their
respective domains.</p>
        <p>We assume that by fulfilling two central objectives - completeness and integration
capability – a defined set of DTOR processes’ constitutive elements and their structural
relations can provide the foundation for overcoming the challenges resulting from the
inherent complexity of DTOR processes. The first objective of completeness can be
described by two requirements. First conceptual completeness – reflecting the
capability of providing an abstract structure incorporating all knowledge elements and their
relations relevant in a DTOR process. Secondly, completeness with respect to content–
reflecting its capability of providing a complete set of content categories for the abstract
constitutive elements. The second central objective, i.e. integration capability, is
reflected by the necessity to provide a structure for facilitating shared understanding,
supporting the integration of instantiations of elements constituting and resulting from
collaboratively executed DTOR processes.
3.2</p>
      </sec>
      <sec id="sec-2-2">
        <title>Artefact Design</title>
        <p>To develop the artefact we plan several design cycles. The first cycle aims at fulfilling
three basic requirements: (1) conceptual completeness, (2) completeness with respect
to content, and (3) integration capability. The following section will outline the artefact
design structured along these three requirements.</p>
        <p>
          Conceptual Completeness. At the center of our initial artefact design stands the DTOR
framework [
          <xref ref-type="bibr" rid="ref14">11</xref>
          ]. It was developed following a design perspective on the DTOR process
and provides a description framework for involved conceptual elements as well as their
relationships. The DTOR framework represents the recognition process for digital
transformation opportunities as an organizational actor’s technology-informed view on
certain organizational representations, which can then result in the recognition of DT
opportunities. Based on the Function-Behaviour-Structure (FBS) Ontology [
          <xref ref-type="bibr" rid="ref26">23</xref>
          ] - a
description language for design processes independent of the design domain - and the
situated (FBS) framework [
          <xref ref-type="bibr" rid="ref27">24</xref>
          ] – a model of a designer’s interaction with design
elements in three worlds -, the DTOR framework provides a rich set of conceptual
underpinnings and micro processes for DTOR processes. The three core conceptual elements
of the DTOR framework are an organizational representation (OR) a technology lens
(TL) and finally. a digital transformation opportunity (DTO). Figure 1 depicts the
DTOR framework in its basic form.
        </p>
        <p>A DTO represent potential technology driven alteration to an organizations value
creation path and is a hypothetical construct therefore located within the interpreted
world of a designer. An OR is an externalized depiction of an organization or one of its
aspects therefore located in the external world. Finally, a TL represents the internal
representation of a technological construct along its dimensions of function, behavior
and structure and is again located in the interpreted world. DTOs can be identified by
(1) reflecting external requirements on the organization, by (2) reflecting external
representations of the existing organization through a certain TL or (3) through
constructive memory processes using current and previously interpreted ORs as a basis for
producing DTOs via push-pull processes.</p>
        <p>
          The DTOR framework provides a rich and detailed overview of micro processes
involved in DTOR processes. Whilst this fits the purpose of a detailed description
framework, not all aspects (e.g. providing detailed process descriptions of internal
thought processes of a designer) can be considered relevant for the objective of the
proposed artefact. In our artefact design focused on providing conceptual completeness
we have therefore included the three central elements of OR, TL, and DTO as well as
the central idea of reflecting onto certain ORs through TL whilst omitting more detailed
micro processes irrelevant for potential appliers of the DTOR methodology.
Completeness with respect to Content. The second requirement of this initial design
cycle for the DTOR methodology is focused on the artefact’s capability of providing a
complete set of content categories of the constitutive elements. To develop such a set,
we chose a deductive approach. After identifying exemplars for digital transformation
initiatives within literature we used a three-staged approach to derive defined categories
for each of the three central DTOR elements. For the first step, literature cited in a
recent literature review on digital transformation was defined as a candidate set for
coding by an individual researcher. Instances of digital transformation initiatives which
contained information on the effected OR, the utilized TL and the resulting DTOs were
coded in an open coding approach [
          <xref ref-type="bibr" rid="ref28">25</xref>
          ] until theoretical saturation was reached [
          <xref ref-type="bibr" rid="ref29">26</xref>
          ]. In
the second step a team of independent researchers developed a categorization scheme
as well as a coding sheet [
          <xref ref-type="bibr" rid="ref30">27</xref>
          ] based the initial results of the first step. In the final
(currently ongoing) stage the coding sheet is utilized by another researcher to identify
triplets of OR, TL and DTO in reports of public organizations. After a first adoption of
the coding sheet following results from the third step, we currently identify a set of
seven categories for OR, ten for TL and nine categories for DTOs. At the current stage
the derived content categories are still formalized as definitions utilized in a coding
process. Table 2 provides an example for each category per constitutive element.
is defined as an organizational perspective focusing
on how the organization creates, delivers and
captures value.
refers to the representation of a composite
technology, consisting of a combination of physical
technology, software technology, and work techniques
as self-contained structure concept.
refers to a potential support of organizational value
creation activities resulting from alterations in
information supply.
        </p>
        <p>The next step in artefact development will be to transform these representations of
the identified categories as patterns for OR, TL and DTOs thereby enabling the
provision of a complete set of patterns with respect to content for the constitutive elements
derived from the DTOR framework.</p>
        <p>Integration Capability. The third requirement with respect to the proposed artefact in
its first design cycle is its capability to serve as a shared conceptual structure capturing
integrating instantiations of elements constituting and resulting from real world DTOR
processes. Concerning the design of the artefact this requirement is a challenge in two
ways: (1) to provide a shared conceptual structure that can be conveyed within the time
constraints of a methodology application, a focus on certain elements of the detailed
DTOR description framework becomes necessary, (2) the integration capability of the
proposed artefact will be dependent on the way it is conveyed to appliers of the artefact
via the proposed treatment. Concerning challenge one – as previously stated – we have
decided to limit the set of constitutive elements to the core aspects of the DTOR
framework for the first design cycle. We do not exclude adding additional elements presented
in the initial framework in later cycles yet currently expect that the identified elements
will be sufficient to provide the required integration capability. Concerning challenge
two, we currently identify the approach of separating our treatment into two stages as
most promising. First, a unilateral and indirect communication instrument to convey
the content of the artefact, secondly, a bilateral person-to-person communication
focused on ensuring the correct understanding of the presented artefact and providing us
with feedback for artefact design. Alternatively, we have considered following the
approach of understanding the treatment as individual artefact within its own design cycle.
3.3</p>
      </sec>
      <sec id="sec-2-3">
        <title>Demonstration and Evaluation</title>
        <p>
          For demonstration of the artefact – which represents the subsequent activity in Peffers
et al.’s [
          <xref ref-type="bibr" rid="ref17">14</xref>
          ] DSRM - we are planning to utilize a case-based approach. As participants
we are considering students of the business and business informatics domain each
primed with different knowledge elements concerning a hypothetical organization.
These knowledge elements will include several ORs and TLs as the test case. We intend
to demonstrate the proposed artefact in three different workshop settings based on the
test case: (1) participants do not receive any guidance (control group), (2) treatment
will be limited to the unilateral and bidirectional communication instrument, (3) in
addition to unilateral and bidirectional communication instrument a researcher will be
present to guide group work. Following this approach, we expect to gain insights
regarding the fitting of the current artefact with respect to the design objectives.
        </p>
        <p>Evaluation draws from the demonstration in different ways. Fist, in case the current
artefact design is generally insufficient we expect to be able further refining the artefact.
Secondly, we focus on the evaluation of completeness. Conceptual completeness of the
elements and relations can be concluded from the applicability of the framework for
coding without the need of further instructions. However, regarding completeness with
respect to content, we assume that it can hardly be evaluated directly in the workshops,
but rather evolves from design. Finally, we evaluate against integration capability of
the framework by applying post-hoc interviews. Overall, we focus on evaluating
definition (e.g., rephrasing the constructs in the according context) and intelligibility
specificity (respectively accuracy) of the constitutive elements and their relations.
4</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Discussion and Outlook</title>
      <p>The presented research in progress details the current design science approach for
developing a methodology for a business opportunity recognition framework. The
development of the methodology aims to structure the process for organizational actors when
being challenged to identify opportunities for technology utilization within the
organization. Timely recognition of such opportunities is of high strategic importance, albeit
its complexity which results from intertwining technology-related decision making
with business development.</p>
      <p>
        In order to reduce the complexity we suggest to structure the development of the
methodology along the design science research stages and steps as proposed by Peffers
et al. [
        <xref ref-type="bibr" rid="ref17">14</xref>
        ]. Since three different underlying problem dimensions could be defined for
opportunity recognition, the design cycles can be structured accordingly. In this paper
we provided the motivation for the first identified problem dimension, i.e. the relevant
entities that need to be considered for opportunity recognition and reviewed the
respective state of analysis and development.
      </p>
      <p>Based on our analysis of the developed framework for digital transformation
opportunity recognition (DTOR) the methodology development can be tackled by the defined
DSR approach, since it allows capturing recognition processes’ constitutive elements
and their relations. In this way the knowledge gap for defining the universe of discourse
can be narrowed step-by-step. Knowing this universe not only establishes an ontology
for the DTOR developments, but rather helps overcoming individual or collective
difficulties to structure the diverse and numerous elements required for DTOR processes.
It enables establishing individuals and organizations a terminological and conceptual
ground with pre-structured and possibly relevant knowledge items, and thus facilitates
migration effort in heterogeneous transformation settings.</p>
      <p>
        From an evaluation perspective the proposed Design Science approach fits to the
components and layering of criteria relevant for each design cycle, as having been
applied to Information Systems so far (cf. [
        <xref ref-type="bibr" rid="ref31">28</xref>
        ]). The dimensions of research identified for
methodology development refer to the evolution perspective, and need to be refined to
address the goal, environment, structure, and activities explicitly, as they are the
constitutive elements and their relations, fundamental for the upcoming steps in
methodology development. The model providing an abstraction of evaluation methods represents
items relevant for checking ontologies relevant for methods and their appropriation.
They need to be generic, including intelligibility for addressed stakeholders, to be
utilized in various contexts of the addressed DTOR methodology development.
      </p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          <volume>59</volume>
          ,
          <fpage>301</fpage>
          -
          <lpage>308</lpage>
          (
          <year>2017</year>
          ). https://doi.org/10.1007/s12599-017-0484-2.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          <string-name>
            <surname>Nan</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tanriverdi</surname>
          </string-name>
          , H.:
          <article-title>Unifying the Role of IT in Hyperturbulence and Competitive Advantage Via a Multilevel Perspective of IS Strategy</article-title>
          .
          <source>MIS Quarterly</source>
          .
          <volume>41</volume>
          ,
          <fpage>937</fpage>
          -
          <lpage>958</lpage>
          (
          <year>2017</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          <string-name>
            <surname>Nambisan</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Majchrzak</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Song</surname>
            ,
            <given-names>M.:</given-names>
          </string-name>
          <article-title>Digital Innovation Management: Reinventing Innovation Management Research in a Digital World</article-title>
          . MISQ.
          <volume>41</volume>
          ,
          <fpage>223</fpage>
          -
          <lpage>238</lpage>
          (
          <year>2017</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          https://doi.org/10.25300/MISQ/
          <year>2017</year>
          /41:1.
          <fpage>03</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          <string-name>
            <surname>O'Reilly</surname>
            ,
            <given-names>C.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tushman</surname>
            ,
            <given-names>M.L.</given-names>
          </string-name>
          :
          <article-title>Ambidexterity as a dynamic capability: Resolving the innovator's dilemma</article-title>
          . Research in Organizational Behavior.
          <volume>28</volume>
          ,
          <fpage>185</fpage>
          -
          <lpage>206</lpage>
          (
          <year>2008</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          https://doi.org/10.1016/j.riob.
          <year>2008</year>
          .
          <volume>06</volume>
          .002.
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          <string-name>
            <surname>Sambamurthy</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bharadwaj</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Grover</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          :
          <article-title>Shaping Agility through Digital Options: Reconceptualizing the Role of Information Technology in Contemporary Firms</article-title>
          .
          <source>MIS Quarterly</source>
          .
          <volume>27</volume>
          ,
          <fpage>237</fpage>
          -
          <lpage>263</lpage>
          (
          <year>2003</year>
          ). https://doi.org/10.2307/30036530.
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          <string-name>
            <surname>Kohli</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Melville</surname>
            ,
            <given-names>N.P.</given-names>
          </string-name>
          :
          <article-title>Digital innovation: A review and synthesis</article-title>
          .
          <source>Info Systems J. 29</source>
          ,
          <fpage>200</fpage>
          -
          <lpage>223</lpage>
          (
          <year>2018</year>
          ). https://doi.org/10.1111/isj.12193.
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          <string-name>
            <surname>Vial</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          :
          <article-title>Understanding digital transformation: A review and a research agenda</article-title>
          .
          <source>The Journal of Strategic Information Systems</source>
          .
          <volume>28</volume>
          ,
          <fpage>118</fpage>
          -
          <lpage>144</lpage>
          (
          <year>2019</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          https://doi.org/10.1016/j.jsis.
          <year>2019</year>
          .
          <volume>01</volume>
          .003.
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          8.
          <string-name>
            <surname>Urbach</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ahlemann</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Böhmann</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Drews</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Brenner</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Schaudel</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Schütte</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          :
          <article-title>The Impact of Digitalization on the IT Department</article-title>
          .
          <source>Business &amp; Information Systems Engineering</source>
          .
          <volume>61</volume>
          ,
          <fpage>123</fpage>
          -
          <lpage>131</lpage>
          (
          <year>2019</year>
          ). https://doi.org/10.1007/s12599-018-0570-0.
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          9.
          <string-name>
            <surname>Horlacher</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hess</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          :
          <article-title>What does a Chief Digital Officer do? Managerial tasks and roles of a new C-level position in the context of digital transformation</article-title>
          .
          <source>In: Proceedings of the 49th Hawaii International Conference on System Sciences</source>
          . pp.
          <fpage>5126</fpage>
          -
          <lpage>5135</lpage>
          . IEEE Computer Society, Waikoloa Village,
          <string-name>
            <surname>Hawaii</surname>
          </string-name>
          (
          <year>2016</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          10.
          <string-name>
            <surname>Bharadwaj</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>El Sawy</surname>
            ,
            <given-names>O.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Pavlou</surname>
            ,
            <given-names>P.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Venkatraman</surname>
          </string-name>
          , N.:
          <article-title>Digital Business Strategy: Toward a Next Generation of Insights</article-title>
          .
          <source>MIS Quarterly</source>
          .
          <volume>37</volume>
          ,
          <fpage>471</fpage>
          -
          <lpage>482</lpage>
          (
          <year>2013</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          11.
          <string-name>
            <surname>Muehlburger</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kannengiesser</surname>
            ,
            <given-names>U.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Krumay</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Stary</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>A Framework for Recognizing Digital Transformation Opportunities</article-title>
          .
          <source>In: ECIS 2020 Proceedings</source>
          . p.
          <volume>17</volume>
          (
          <year>2020</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          12.
          <string-name>
            <surname>Hevner</surname>
            ,
            <given-names>A.R.:</given-names>
          </string-name>
          <article-title>A three cycle view of design science research</article-title>
          .
          <source>Scandinavian Journal of Information Systems</source>
          .
          <volume>19</volume>
          ,
          <issue>4</issue>
          (
          <year>2007</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          13.
          <string-name>
            <surname>Hevner</surname>
            ,
            <given-names>A.R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>March</surname>
          </string-name>
          , S.T.,
          <string-name>
            <surname>Park</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ram</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <source>Design Science in Information Systems Research. MIS Quarterly</source>
          .
          <volume>28</volume>
          ,
          <fpage>75</fpage>
          -
          <lpage>105</lpage>
          (
          <year>2004</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          14.
          <string-name>
            <surname>Peffers</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tuunanen</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rothenberger</surname>
            ,
            <given-names>M.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chatterjee</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <source>A Design Science Research Methodology for Information Systems Research. Journal of Management Information Systems</source>
          .
          <volume>24</volume>
          ,
          <fpage>45</fpage>
          -
          <lpage>77</lpage>
          (
          <year>2007</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          15.
          <string-name>
            <surname>Drechsler</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hevner</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>A four-cycle model of IS design science research: capturing the dynamic nature of IS artifact design</article-title>
          . In:
          <article-title>Breakthroughs and Emerging Insights from Ongoing Design Science Projects: Research-in-progress papers and poster presentations from the 11th</article-title>
          <source>International Conference on Design Science Research in Information Systems and Technology (DESRIST)</source>
          <year>2016</year>
          . St. John, Canada,
          <fpage>23</fpage>
          -
          <lpage>25</lpage>
          May. pp.
          <fpage>1</fpage>
          -
          <lpage>8</lpage>
          .
          <source>DESRIST</source>
          <year>2016</year>
          (
          <year>2016</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          16.
          <string-name>
            <surname>Baskerville</surname>
          </string-name>
          , R.:
          <article-title>What design science is not</article-title>
          .
          <source>European Journal of Information Systems</source>
          .
          <volume>17</volume>
          ,
          <fpage>441</fpage>
          -
          <lpage>443</lpage>
          (
          <year>2008</year>
          ). https://doi.org/10.1057/ejis.
          <year>2008</year>
          .
          <volume>45</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          17.
          <string-name>
            <surname>Markus</surname>
            ,
            <given-names>M.L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Majchrzak</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gasser</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          :
          <article-title>A Design Theory for Systems That Support Emergent Knowledge Processes</article-title>
          .
          <source>MIS Quarterly</source>
          .
          <volume>26</volume>
          ,
          <fpage>179</fpage>
          -
          <lpage>212</lpage>
          (
          <year>2002</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          18.
          <string-name>
            <surname>Walls</surname>
            ,
            <given-names>J.G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Widmeyer</surname>
            ,
            <given-names>G.R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>El Sawy</surname>
            ,
            <given-names>O.A.</given-names>
          </string-name>
          :
          <article-title>Building an Information System Design Theory for Vigilant EIS</article-title>
          .
          <source>Information Systems Research</source>
          .
          <volume>3</volume>
          ,
          <fpage>36</fpage>
          -
          <lpage>59</lpage>
          (
          <year>1992</year>
          ). https://doi.org/10.1287/isre.3.1.36.
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          19.
          <string-name>
            <surname>Baskerville</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Baiyere</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gergor</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hevner</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rossi</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          : Design Science Research Contributions:
          <article-title>Finding a Balance between Artifact and Theory</article-title>
          .
          <source>JAIS</source>
          .
          <volume>19</volume>
          ,
          <fpage>358</fpage>
          -
          <lpage>376</lpage>
          (
          <year>2018</year>
          ). https://doi.org/10.17705/1jais.
          <fpage>00495</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          20.
          <string-name>
            <surname>Takeda</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Veerkamp</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tomiyama</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Yoshikawa</surname>
          </string-name>
          , H.:
          <article-title>Modeling Design Processes</article-title>
          .
          <source>AI Magazine</source>
          .
          <volume>11</volume>
          ,
          <fpage>37</fpage>
          -
          <lpage>48</lpage>
          (
          <year>1990</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>
          21.
          <string-name>
            <surname>Gregor</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hevner</surname>
            ,
            <given-names>A.R.</given-names>
          </string-name>
          :
          <article-title>Positioning and Presenting Design Science Research for Maximum Impact</article-title>
          .
          <source>MIS Quarterly</source>
          .
          <volume>37</volume>
          ,
          <fpage>337</fpage>
          -
          <lpage>A6</lpage>
          (
          <year>2013</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref25">
        <mixed-citation>
          22.
          <string-name>
            <surname>Turner</surname>
            ,
            <given-names>J.R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chen</surname>
            ,
            <given-names>Q.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Danks</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Team shared cognitive constructs: A meta‐analysis exploring the effects of shared cognitive constructs on team performance</article-title>
          .
          <source>Performance Improvement Quarterly</source>
          .
          <volume>27</volume>
          ,
          <fpage>83</fpage>
          -
          <lpage>117</lpage>
          (
          <year>2014</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref26">
        <mixed-citation>
          23.
          <string-name>
            <surname>Gero</surname>
            ,
            <given-names>J.S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kannengiesser</surname>
            ,
            <given-names>U.</given-names>
          </string-name>
          :
          <article-title>The Function-Behaviour-Structure Ontology of Design. In: An Anthology of Theories and Models of Design: Philosophy, Approaches and Empirical Explorations</article-title>
          . pp.
          <fpage>263</fpage>
          -
          <lpage>283</lpage>
          . Springer, London (
          <year>2014</year>
          ). https://doi.org/10.1007/978-1-
          <fpage>4471</fpage>
          - 6338-1_
          <fpage>13</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref27">
        <mixed-citation>
          24.
          <string-name>
            <surname>Gero</surname>
            ,
            <given-names>J.S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kannengiesser</surname>
            ,
            <given-names>U.</given-names>
          </string-name>
          :
          <article-title>The situated function-behaviour-structure framework</article-title>
          .
          <source>Design Studies</source>
          .
          <volume>25</volume>
          ,
          <fpage>373</fpage>
          -
          <lpage>391</lpage>
          (
          <year>2004</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref28">
        <mixed-citation>
          25.
          <string-name>
            <surname>Strauss</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Corbin</surname>
            ,
            <given-names>J.M.:</given-names>
          </string-name>
          <article-title>Grounded theory in practice</article-title>
          .
          <source>Sage</source>
          (
          <year>1997</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref29">
        <mixed-citation>
          26.
          <string-name>
            <surname>van Rijnsoever</surname>
            ,
            <given-names>F.J.</given-names>
          </string-name>
          :
          <article-title>(I can't get no) saturation: a simulation and guidelines for sample sizes in qualitative research</article-title>
          .
          <source>PloS one</source>
          .
          <volume>12</volume>
          ,
          <issue>e0181689</issue>
          (
          <year>2017</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref30">
        <mixed-citation>
          27.
          <string-name>
            <surname>Neuendorf</surname>
            ,
            <given-names>K.A.</given-names>
          </string-name>
          :
          <article-title>Content analysis and thematic analysis</article-title>
          .
          <source>In: Advanced Research Methods for Applied Psychology. Routledge</source>
          (
          <year>2018</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref31">
        <mixed-citation>
          28.
          <string-name>
            <surname>Prat</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Comyn-Wattiau</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Akoka</surname>
          </string-name>
          , J.:
          <source>Artifact Evaluation in Information Systems DesignScience Research-a Holistic View. PACIS</source>
          ,
          <volume>23</volume>
          ,
          <fpage>1</fpage>
          -
          <lpage>16</lpage>
          (
          <year>2014</year>
          ).
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>