=Paper=
{{Paper
|id=Vol-2991/paper04
|storemode=property
|title=Enterprise Engineering for Business Opportunity Recognition - A Design Science Approach
|pdfUrl=https://ceur-ws.org/Vol-2991/paper04.pdf
|volume=Vol-2991
|authors=Manuel Mühlburger,Barbara Krumay,Christian Stary
|dblpUrl=https://dblp.org/rec/conf/bir/MuhlburgerKS21
}}
==Enterprise Engineering for Business Opportunity Recognition - A Design Science Approach==
https://ceur-ws.org/Vol-2991/paper04.pdf
Enterprise Engineering for Business Opportunity
Recognition - A Design Science Approach
Manuel Mühlburger1[0000-0002-6784-0579], Barbara Krumay1[0000-0001-5313-3833], and Christian
Stary1[0000-0001-9764-5021]
1
Johannes Kepler Universität, 4040 Linz, Austria
christian.stary@jku.at
Abstract: 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 multifac-
eted 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 when-
ever stakeholders adopt novel organizational practices and technologies to
achieve business objectives according to recognized opportunities. Conse-
quently, 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 de-
sign science approach for methodology development. The initial development
step has its focus on relevant knowledge items and relations guiding organiza-
tional actors when elaborating on digital transformation processes. Streamlining
technology, technical and organizational issues when recognizing transformation
potential facilitates the exploration of corresponding business practices.
Keywords: Digital Transformation, Opportunity Recognition, Framework, De-
sign Science Research
1 Introduction
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 ca-
pabilities focused on enabling this reconfiguration have been of increasing interest for
researchers and practitioners. A focus on specific capability constructs like agility, am-
bidexterity 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
Copyright © 2021 for this paper by its authors. Use permitted under Creative Commons License
Attribution 4.0 International (CC BY 4.0)
41
show differences in their conceptualization, they strongly indicate the necessity for or-
ganizations to obtain capabilities enabling them to react to changed circumstances to
sustainably navigate the turbulent environments they find themselves in.
The application of technology, information technology (IT) in particular, to gain
competitive advantage can be considered as one of the most volatile and complex as-
pects of organizational environments. A variety of research fields investigate the inter-
section of traditional aspects of organizational change with digital technologies and
testify to the increasing importance and complexity of integrating technology into mod-
ern 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].
Within organizations the pressure resulting from the complexity of adapting to shift-
ing 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 [8], roles dedicated towards
the identification and adaption of potentials induced by technologies are introduced [9],
and strategic concepts are altered to focus on the integration of such potentials at the
highest level of organizational planning [10]. Whilst such organizational processes in-
tended 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].
Such processes require the integration of diverse technical and organizational
knowledge elements carried by individuals distributed within and outside the organiza-
tion and therefore reflect a complex enterprise engineering problem. In a previous study
a description framework for micro processes and knowledge elements involved in dig-
ital transformation opportunity recognition (DTOR) has been developed to reduce prob-
lem complexity [11]. 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.
The structure of the paper is as follows: section two presents and motivates the ap-
plication of design science research for digital transformation opportunity recognition;
section three further elaborates on our approach for designing and evaluating our meth-
odology for its capability to feature completeness with respect to content and its inte-
grative capacity of the presented complex setting through the provision of sharing cog-
nitive structures; section four concludes the paper reflecting on the presented approach
and presenting an outlook on future research.
42
2 DTOR Methodology Development as DSR Approach
For developing the DTOR methodology, we rely on a design science research (DSR)
approach to integrate relevance and rigor [12, 13], but also develop an artefact itera-
tively [14]. In their seminal work, Hevner et al. [13] 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” [13]. It has been stated that differentiating routine design from
design science research is important [13, 16]. The latter aims at solving existing prob-
lems that occur in reality (e.g., in companies) focusing on people, organizations and
technology [13]. The solution, hence, contributes to the knowledge in the field [13].
Focusing on existing, real-world problems is a precondition to fulfill the relevance re-
quirement of research [12, 13]. To meet the requirement of rigor, DSR projects have to
be based on an existing knowledge base, in particular existing foundations and meth-
odologies [12, 13]. 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” [13]. Furthermore, it has been often stated, that creating
artefacts directly depends on underlying kernel theories [13, 14, 17, 18] as part of the
existing knowledge but also as way to test the artefact [19]. To apply DSR, methods
and processes are at hand, be there high level design processes [19, 20] or more opera-
tional frameworks [14]. Peffers et al. [14] provide a method and process of six activi-
ties, defining possible research entry points for DSR as well as likely process iterations.
The six activities include (1) problem identification and motivation, (2) define objec-
tives of a solution, (3) design and development, (4) demonstration, (5) evaluation, and
(6) communication [14]. Depending on the initiation or intended solution, the research
entry points relate to activities 1 to 4 [14]. Consequently, DSR projects based on this
framework do not necessarily cover all activities.
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 [13, 16, 21]. Adopting
a problem-centered approach, the DTOR methodology development starts with the first
activity as defined by Peffers et al. [14]. We rely on the existing body of knowledge for
safeguarding rigor but also to clarify the contribution of the DTOR methodology [12,
13]. Identifying dynamic capabilities as a kernel theory for strengthening theoretical
integration [14, 19], our research design foresees iterations on different stages to learn
from demonstration and evaluation for developing a stable artefact [14, 21]. Moreover,
each artefact design is challenged by various problem dimensions on different levels as
enabled by DSR [14, 19], as the improvement of the problem context evolves along
each design cycle (cf. https://wwwhome.ewi.utwente.nl/~roelw/DSM90minutes.pdf).
43
2.1 DTOR Methodology Development
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, meth-
ods and instantiations [13]. Due to the complexity of the underlying research problem,
the DTOR methodology integrates a model, consisting of abstractions and representa-
tions, a method referring to algorithms and practices, and instantiations implemented
in or related to the organizations context, i.e. an organization [13]. Therefore, in the
current state of this research, we identified three problem dimensions on different lev-
els. For each dimension, in line with Peffers et al. [14], we distinguished objectives,
artefact design, demonstration and evaluation.
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 re-
lies on a case-based approach in a workshop setting conveying semantics and appear-
ance 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).
The next dimension refers to procedural deficiencies of the DTOR process. Combin-
ing 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 com-
pany 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 under-
standing of that goal. Second, we focus on the mapping of settings towards DTOR pro-
cess scenarios. Therefore, collaboration features in this context need to part of the de-
sign. For demonstration, we plan developing a process case for a more detailed proce-
dure. 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.
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 con-
texts. Hence, we aim at providing some guidance for identification and adoption of
instances of constitutive elements of the DTOR process in an integrative and organiza-
tion-specific way. In the artifact design, we focus on a set of principles for instantiating
44
the DTOR process based on specific organizational context in given scenarios. Conse-
quently, demonstration relies on a scenario case demonstrating the instantiation, involv-
ing 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.
Table 1. Problem dimension and DSRM [14]
Problem identification Objectives Artefact de- Demonstra- Evalua-
sign tion tion
Non-integrative - Provision of a set of Semantic Case-based Analyz-
standalone ap- constitutive elements definition approach ing re-
proaches; constitutive and instances of these and visibility (workshop) sults of
elements and relations elements including workshop
of DTOR process not their structural rela- settings
identified tions
Procedural deficien- Provision of a pro- Ensuring Process case Analyz-
cies of DTOR process cess for DTOR common un- (experi- ing re-
derstanding mental set- sults of
of goal ting) experi-
mental
setting
DTOR application Guidance for identifi- Set of princi- Scenario Analyz-
hindrances cation and adoption ples for in- case (exper- ing re-
of instances of consti- stantiating imental set- sults of
tutive elements the DTOR ting) experi-
mental
setting
3 Completeness and Integration Capability
As previously mentioned, we have identified three distinct dimensions on the design
science research problem at hand. We intend to follow a procedural approach engaging
the identified research problem by initially focusing on the first of these problem di-
mensions. The following section therefore provides a more detailed description of the
first design cycle in this research project.
3.1 Problem Description and Objectives
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 ele-
ments and their relations. The individual and collaborative inability to structure the di-
verse 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 chal-
45
lenge “roams free” and reduces the individuals and thereby the organization’s capabil-
ity for sensing potential opportunities provided by digital technologies in their respec-
tive domains.
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 capabil-
ity 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 re-
flected by the necessity to provide a structure for facilitating shared understanding, sup-
porting the integration of instantiations of elements constituting and resulting from col-
laboratively executed DTOR processes.
3.2 Artefact Design
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.
Conceptual Completeness. At the center of our initial artefact design stands the DTOR
framework [11]. 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 [23] - a de-
scription language for design processes independent of the design domain - and the
situated (FBS) framework [24] – a model of a designer’s interaction with design ele-
ments in three worlds -, the DTOR framework provides a rich set of conceptual under-
pinnings 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.
46
Figure 1. DTOR Framework [11]
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 rep-
resentations of the existing organization through a certain TL or (3) through construc-
tive memory processes using current and previously interpreted ORs as a basis for pro-
ducing DTOs via push-pull processes.
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 [25] until theoretical saturation was reached [26]. In
47
the second step a team of independent researchers developed a categorization scheme
as well as a coding sheet [27] based the initial results of the first step. In the final (cur-
rently ongoing) stage the coding sheet is utilized by another researcher to identify tri-
plets 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.
Table 2. Content categories - examples
Title Correspond- Definition
ing Element
Business OR is defined as an organizational perspective focusing
Model on how the organization creates, delivers and cap-
tures value.
Composite TL refers to the representation of a composite technol-
Technology ogy, consisting of a combination of physical tech-
nology, software technology, and work techniques
as self-contained structure concept.
Insight Op- DTO refers to a potential support of organizational value
portunity creation activities resulting from alterations in infor-
mation supply.
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 provi-
sion of a complete set of patterns with respect to content for the constitutive elements
derived from the DTOR framework.
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 frame-
work 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 fo-
cused on ensuring the correct understanding of the presented artefact and providing us
48
with feedback for artefact design. Alternatively, we have considered following the ap-
proach of understanding the treatment as individual artefact within its own design cycle.
3.3 Demonstration and Evaluation
For demonstration of the artefact – which represents the subsequent activity in Peffers
et al.’s [14] 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 ad-
dition to unilateral and bidirectional communication instrument a researcher will be
present to guide group work. Following this approach, we expect to gain insights re-
garding the fitting of the current artefact with respect to the design objectives.
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 defi-
nition (e.g., rephrasing the constructs in the according context) and intelligibility spec-
ificity (respectively accuracy) of the constitutive elements and their relations.
4 Discussion and Outlook
The presented research in progress details the current design science approach for de-
veloping a methodology for a business opportunity recognition framework. The devel-
opment of the methodology aims to structure the process for organizational actors when
being challenged to identify opportunities for technology utilization within the organi-
zation. Timely recognition of such opportunities is of high strategic importance, albeit
its complexity which results from intertwining technology-related decision making
with business development.
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. [14]. 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 respec-
tive state of analysis and development.
49
Based on our analysis of the developed framework for digital transformation oppor-
tunity 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 dif-
ficulties 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.
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 ap-
plied to Information Systems so far (cf. [28]). 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 con-
stitutive elements and their relations, fundamental for the upcoming steps in methodol-
ogy 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 uti-
lized in various contexts of the addressed DTOR methodology development.
References
1. Legner, C., Eymann, T., Hess, T., Matt, C., Böhmann, T., Drews, P., Mädche, A., Urbach,
N., Ahlemann, F.: Digitalization: Opportunity and Challenge for the Business and Infor-
mation Systems Engineering Community. Business & Information Systems Engineering.
59, 301–308 (2017). https://doi.org/10.1007/s12599-017-0484-2.
2. Nan, N., Tanriverdi, H.: Unifying the Role of IT in Hyperturbulence and Competitive Ad-
vantage Via a Multilevel Perspective of IS Strategy. MIS Quarterly. 41, 937–958 (2017).
3. Nambisan, S., Majchrzak, A., Song, M.: Digital Innovation Management: Reinventing In-
novation Management Research in a Digital World. MISQ. 41, 223–238 (2017).
https://doi.org/10.25300/MISQ/2017/41:1.03.
4. O’Reilly, C.A., Tushman, M.L.: Ambidexterity as a dynamic capability: Resolving the in-
novator’s dilemma. Research in Organizational Behavior. 28, 185–206 (2008).
https://doi.org/10.1016/j.riob.2008.06.002.
5. Sambamurthy, V., Bharadwaj, A., Grover, V.: Shaping Agility through Digital Options:
Reconceptualizing the Role of Information Technology in Contemporary Firms. MIS Quar-
terly. 27, 237–263 (2003). https://doi.org/10.2307/30036530.
6. Kohli, R., Melville, N.P.: Digital innovation: A review and synthesis. Info Systems J. 29,
200–223 (2018). https://doi.org/10.1111/isj.12193.
7. Vial, G.: Understanding digital transformation: A review and a research agenda. The Jour-
nal of Strategic Information Systems. 28, 118–144 (2019).
https://doi.org/10.1016/j.jsis.2019.01.003.
50
8. Urbach, N., Ahlemann, F., Böhmann, T., Drews, P., Brenner, W., Schaudel, F., Schütte, R.:
The Impact of Digitalization on the IT Department. Business & Information Systems Engi-
neering. 61, 123–131 (2019). https://doi.org/10.1007/s12599-018-0570-0.
9. Horlacher, A., Hess, T.: What does a Chief Digital Officer do? Managerial tasks and roles
of a new C-level position in the context of digital transformation. In: Proceedings of the
49th Hawaii International Conference on System Sciences. pp. 5126–5135. IEEE Computer
Society, Waikoloa Village, Hawaii (2016).
10. Bharadwaj, A., El Sawy, O.A., Pavlou, P.A., Venkatraman, N.: Digital Business Strategy:
Toward a Next Generation of Insights. MIS Quarterly. 37, 471–482 (2013).
11. Muehlburger, M., Kannengiesser, U., Krumay, B., Stary, C.: A Framework for Recognizing
Digital Transformation Opportunities. In: ECIS 2020 Proceedings. p. 17 (2020).
12. Hevner, A.R.: A three cycle view of design science research. Scandinavian Journal of In-
formation Systems. 19, 4 (2007).
13. Hevner, A.R., March, S.T., Park, J., Ram, S.: Design Science in Information Systems Re-
search. MIS Quarterly. 28, 75–105 (2004).
14. Peffers, K., Tuunanen, T., Rothenberger, M.A., Chatterjee, S.: A Design Science Research
Methodology for Information Systems Research. Journal of Management Information Sys-
tems. 24, 45–77 (2007).
15. Drechsler, A., Hevner, A.: A four-cycle model of IS design science research: capturing the
dynamic nature of IS artifact design. In: Breakthroughs and Emerging Insights from Ongo-
ing Design Science Projects: Research-in-progress papers and poster presentations from the
11th International Conference on Design Science Research in Information Systems and
Technology (DESRIST) 2016. St. John, Canada, 23-25 May. pp. 1–8. DESRIST 2016
(2016).
16. Baskerville, R.: What design science is not. European Journal of Information Systems. 17,
441–443 (2008). https://doi.org/10.1057/ejis.2008.45.
17. Markus, M.L., Majchrzak, A., Gasser, L.: A Design Theory for Systems That Support Emer-
gent Knowledge Processes. MIS Quarterly. 26, 179–212 (2002).
18. Walls, J.G., Widmeyer, G.R., El Sawy, O.A.: Building an Information System Design The-
ory for Vigilant EIS. Information Systems Research. 3, 36–59 (1992).
https://doi.org/10.1287/isre.3.1.36.
19. Baskerville, R., Baiyere, A., Gergor, S., Hevner, A., Rossi, M.: Design Science Research
Contributions: Finding a Balance between Artifact and Theory. JAIS. 19, 358–376 (2018).
https://doi.org/10.17705/1jais.00495.
20. Takeda, H., Veerkamp, P., Tomiyama, T., Yoshikawa, H.: Modeling Design Processes. AI
Magazine. 11, 37–48 (1990).
21. Gregor, S., Hevner, A.R.: Positioning and Presenting Design Science Research for Maxi-
mum Impact. MIS Quarterly. 37, 337-A6 (2013).
22. Turner, J.R., Chen, Q., Danks, S.: Team shared cognitive constructs: A meta‐analysis ex-
ploring the effects of shared cognitive constructs on team performance. Performance Im-
provement Quarterly. 27, 83–117 (2014).
23. Gero, J.S., Kannengiesser, U.: The Function-Behaviour-Structure Ontology of Design. In:
An Anthology of Theories and Models of Design: Philosophy, Approaches and Empirical
Explorations. pp. 263–283. Springer, London (2014). https://doi.org/10.1007/978-1-4471-
6338-1_13.
51
24. Gero, J.S., Kannengiesser, U.: The situated function–behaviour–structure framework. De-
sign Studies. 25, 373–391 (2004).
25. Strauss, A., Corbin, J.M.: Grounded theory in practice. Sage (1997).
26. van Rijnsoever, F.J.: (I can’t get no) saturation: a simulation and guidelines for sample sizes
in qualitative research. PloS one. 12, e0181689 (2017).
27. Neuendorf, K.A.: Content analysis and thematic analysis. In: Advanced Research Methods
for Applied Psychology. Routledge (2018).
28. Prat, N., Comyn-Wattiau, I., Akoka, J.: Artifact Evaluation in Information Systems Design-
Science Research-a Holistic View. PACIS, 23, 1-16 (2014).
52