Design Science Research (DSR) is a problem-solving paradigm that seeks to enhance human knowledge via the creation of innovative artifacts. Simply stated, DSR seeks to enhance technology and science knowledge bases via the creation of innovative artifacts that solve problems and improve the environment in which they are instantiated. The results of DSR include both the newly designed artifacts and design knowledge (DK) that provides a fuller understanding via design theories of why the artifacts enhance (or, disrupt) the relevant application contexts. The goal of this introduction chapter is to provide a brief survey of DSR concepts for better understanding of the following chapters that present DSR case studies.

Figures - uploaded by Jan vom Brocke

Author content

All figure content in this area was uploaded by Jan vom Brocke

Content may be subject to copyright.

ResearchGate Logo

Discover the world's research

  • 20+ million members
  • 135+ million publications
  • 700k+ research projects

Join for free

1

Introduction to Design Science Research

Jan vom Brocke, Alan Hevner, Alexander Maedche

Abstract

Design Science Research (DSR) is a problem-solving paradigm that seeks to enhance human

knowledge via the creation of innovative artifacts. Simply stated, DSR seeks to enhance

technology and science knowledge bases via the creation of innovative artifacts that solve

problems and improve the environment in which they are instantiated. The results of DSR include

both the newly designed artifacts and design knowledge (DK) that provides a fuller understanding

via design theories of why the artifacts enhance (or, disrupt) the relevant application contexts. The

goal of this introduction chapter is to provide a brief survey of DSR concepts for better

understanding of the following chapters that present DSR case studies.

Introduction to Design Science Research

The Design Science Research (DSR) paradigm has its roots in engineering and the sciences of the

artificial (Simon 1996). It is fundamentally a problem-solving paradigm. DSR seeks to enhance

human knowledge with the creation of innovative artifacts and the generation of design knowledge

(DK) via innovative solutions to real-world problems (Hevner, March, Park, & Ram 2004). As

such, this research paradigm has generated a surge of interest in the past twenty years , specifically

due to its potential to contribute to fostering the innovation capabilities of organizations as well as

This is the author version of the original article published by S pringerNature. Please cite the article as follows:

vom Brocke J., Hevner A., Maedche A. (2020) Introduction to Design Science Research. In: vom Brocke J., Hevner

A., Maedche A. (eds) Design Science Research. Cases, Cham. https://doi.org/10.1007/978-3-030-46781-4_1

2

contributing to the much needed sustainability transformation of society (Watson, Boudreau, &

Chen, 2010; vom Brocke, Watson, Dwyer, Elliot, & Melville, 2013; vom Brocke, Winter, Hevner,

& Maedche 2020).

The goal of a DSR research project is to extend the boundaries of human and organizational

capabilities by designing new and innovative artifacts represented by constructs, models, methods,

and instantiations (Hevner et al. 2004, Gregor & Hevner 2013). DSR aims to generate knowledge

of how things can and should be constructed or arranged (i.e., designed), usually by human agency,

to achieve a desired set of goals; referred to as design knowledge (DK). For example, DK in the

Information Systems (IS) discipline includes knowledge of how to structure and construct a

database system, how to model business processes, how to align IS with organizational strategy,

how to deliver data analytics for effective decision making (e.g. Becker et al. 2015), as well as

how to use information technology to support sustainable practices (Seidel et al. 2013, vom Brocke

& Seidel 2012). DSR results in IS have been shown to create significant economic and societal

impact (Gregor & Hevner 2013, vom Brocke et al. 2013). Beyond the IS field, DSR is a central

research paradigm in many other domains including engineering, architecture, business,

economics, and other information technology-related disciplines for the creation of novel solutions

to relevant design problems.

In the following, we introduce some essential frameworks and conceptualizations that we

deem important in order to provide foundations on how to conduct DSR to scholarly standards.

The cases presented in this book use such fundamentals in order to structure and document their

DSR projects.

3

The DSR Framework

Figure 1 presents a conceptual framework for understanding, executing, and evaluating design

science research (Hevner et al. 2004). The environment defines the problem space in which the

phenomena of interest reside. It is composed of people, organizations, and existing or planned

technologies. In it are the goals, tasks, problems, and opportunities that define needs as they are

perceived by stakeholders within the organization. Needs are assessed and evaluated within the

context of organizational strategies, structure, culture, and existing work processes. They are

positioned relative to existing technology infrastructure, applications, communication

architectures, and development capabilities. Together these define the "research problem" as

perceived by the researcher. Framing research activities to address real stakeholder needs assures

research relevance. The knowledge base provides the raw materials from and through which DSR

is accomplished. The knowledge base is composed of Foundations and Methodologies. Prior

research and results from reference disciplines provide foundational theories, frameworks,

instruments, constructs, models, methods, and instantiations used in the build phase of a research

study. Methodologies provide guidelines used in the evaluate phase. Rigor is achieved by

appropriately applying existing foundations and methodologies.

4

Additions to the Knowledge Bas e

Roles

Capabilities

Characteristics

Strategies

Structure & C ulture

Processes

Infrastructure

Applications

Communications

Architecture

Developm ent

Capabilities

Theories

Frameworks

Instruments

Constructs

Models

Methods

Instantiations

Experimentation

Data Analysis

Techniques

Formalisms

Measures

Validation Criteria

Optimization

Theories

Analytical

Case Study

Experimental

Field Study

Knowledge

Application in the Appropri ate

Environment

Figure 1: Design Science Research Framework (Adapted from (Hevner et al. 2004))

5

DSR studies relevant problems in the real-world environment with various application domains.

Research links to a "need" for solutions to be empirically investigated with people in

organizations using specific technology. Often, the analysis of the business environment and

the derivation of specific needs to be solved build the starting point of a DSR project. However,

also situations exist in which needs have already been studied and can be taken from extant

research. DSR analyses the (academic) knowledge base in that it studies to which extent design

knowledge is already available to solve a problem of interest. Such knowledge can take the

form of theories, frameworks, instruments or design artifacts, such as constructs, models,

methods or instantiations. In case knowledge is already available to solve a problem identified,

this knowledge can be applied following "routine design", which does not constitute DSR. Else,

DSR sets out to create an innovative solution to the problem, which, in most cases, builds on

existing parts of a solution and combines, revises, and extends extant design knowledge. The

design activities comprise of "build" and "evaluate" activities, typically following multiple

iterations. In course of a DSR study, diverse research methods are applied, including those well

established in social science research, such as interviews, surveys, literature reviews, or focus

groups.

DSR Process

The performance of DSR projects has been based on several process models, such as

Nunamaker, Chen, & Purdin (1991), Walls, Widmeyer, & El Sawy (1992), Hevner (2007), and

Kuchler & Vaishnavi (2008). The mostly widely referenced model is one proposed by Peffers ,

Tuuanen, Rothenberger, & Chatterjee (2008). The design science research methodology

(DSRM) process model is shown in Figure 2. This DSR process includes six steps: problem

identification and motivation, definition of the objectives for a solution, design and

development, demonstration, evaluation, and communication; and four possible entry points:

6

problem-centered initiation, objective-centered solution, design and development-centered

initiation, and client/context initiation. A brief description of each DSR activity follows.

Figure 2: DSR Methodology Process Model (Adapted from Peffers et al. (2008))

Activity 1. Problem identification and motivation. This activity defines the specific

research problem and justifies the value of a solution. Justifying the value of a solution

accomplishes two things: it motivates the researcher and the audience of the research to

pursue the solution and it helps the audience to appreciate the researcher's

understanding of the problem. Resources required for this activity include knowledge

of the state of the problem and the importance of its solution.

Activity 2. Define the objectives for a solution. The objectives of a solution can be

inferred from the problem definition and knowledge of what is possible and feasible.

The objectives can be quantitative, e.g., terms in which a desirable solution would be

better than current ones, or qualitative, e.g., a description of how a new artifact is

expected to support solutions to problems not hitherto addressed. The objectives should

be inferred rationally from the problem specification.

7

Activity 3. Design and development. An artifact is created. Conceptually, a DSR artifact

can be any designed object in which a research contribution is embedded in the design.

This activity includes determining the artifact's desired functionality and its architecture

and then creating the actual artifact.

Activity 4. Demonstration. This activity demonstrates the use of the artifact to solve one

or more instances of the problem. This could involve its use in experimentation,

simulation, case study, proof, or other appropriate activity.

Activity 5. Evaluation. The evaluation measures how well the artifact supports a solution

to the problem. This activity involves comparing the objectives of a solution to actual

observed results from use of the artifact in context. Depending on the nature of the

problem venue and the artifact, evaluation could take many forms. At the end of this

activity the researchers can decide whether to iterate back to step three to try to improve

the effectiveness of the artifact or to continue on to communication and leave further

improvement to subsequent projects.

Activity 6. Communication. Here all aspects of the problem and the designed artifact are

communicated to the relevant stakeholders. Appropriate forms of communication are

employed depending upon the research goals and the audience, such as practicing

professionals.

DSR Evaluation

The process of conducting DSR has been further developed in many ways, specifically paying

attention to the evaluation activities and allowing for a more concurrent and fine-grained

evaluation of intermediate steps in the design process. While it is well-understood that also the

8

Peffers et al. (2008) process should and would be conducted iteratively, evaluation only takes

place after design, development and demonstration activities; missing out on the opportunity to

inform the design in an early stage of the research process.

Sonnenberg and vom Brocke (2012) conceptualize concurrent evaluation according to

different aspects of design as shown in Figure 3. They build on prior work describing DSR

activities within the overall DSR process, arguing that each of these activities progresses toward

the intended artefacts differently and thus offer potential for concurrent (or formative)

evaluation. Such evaluation can mitigate risk (Venable, vom Brocke, & Winter 2019), as early

feedback on the minute steps leading to the eventual artefact can be incorporated into the design

process. The authors also assert that this type of evaluation can be more specific and better

directed if the evaluation focuses on the different aspects of design when relevant decisions are

being made during the design process.

Figure 3: Evaluation Activities within the DSR Process (Adapted from Sonnenberg and vom

Brocke (2012))

9

To demonstrate, Sonnenberg and vom Brocke (2012) identify four evaluation types (Eval 1 to

Eval 4) derived from typical DSR activities. Figure 3 shows a cyclic high-level DSR process

that includes the activities of problem identification, design, construction, and use. In addition,

Figure 3 suggests that each DSR activity is followed by an evaluation activity, as follows:

Eval 1: Evaluating the problem identification; criteria include importance, novelty, and

feasibility

Eval 2: Evaluating the solution design; criteria include simplicity, clarity, and

consistency

Eval 3: Evaluating the solution instantiation; criteria include ease of use, fidelity with

real-world phenomena, and robustness

Eval 4: Evaluating the solution in use; criteria include effectiveness, efficiency, and

external consistency.

Depending on when an evaluation occurs, ex ante and ex post evaluations are distinguished. Ex

ante evaluations are conducted before the instantiation of any artefacts, while ex post

evaluations occur after the instantiation of any artefact (Venable, Pries-Heje, & Baskerville

2016). The DSR process in Figure 3 indicates that there are feedback loops from each evaluation

activity to the preceding design activity. Overall, these feedback loops together form a feedback

cycle that runs in the opposite direction to the DSR cycle.

Design Knowledge Framework

The design knowledge (DK) produced in a DSR project can be richly multifaceted. DK will

include information about the important problem, the designed solution, and the evaluation

evidence. Specifically it includes measures of timely progress on how well the problem solution

satisfies the key stakeholders of a problem.

10

We consider these three components to constitute DK: the problem space, the solution space,

and the evaluation. While we understand that both problem space knowledge and solution space

knowledge exists independently, it is only through putting them in relation to one another that

we refer to the respective knowledge as DK. Figure 4 provides a simple model conceptualizing

important components of DK.

Figure 4: Components of Design Knowledge for a Specific DSR Project

Information systems research consumes and produces two basic types of knowledge: 1)

behavioral science-oriented research activities primarily grow propositional knowledge or W-

knowledge (comprising descriptive and explanatory knowledge), and, 2) DSR-oriented

research activities primarily grow applicable (or prescriptive) knowledge or l-knowledge

(Gregor & Hevner 2013). Contributions to the l knowledge base typically comprise knowledge

about technological (i.e. digital) innovations that directly affect individuals, organizations, or

society while also enabling the development of future innovations (Winter & Albani 2013).

Contributions to the W knowledge base enhance our understanding of the world and the

Solution Space Problem Space

P

r

o

b

l

e

m

Context

Domain

Stakeholder

Time

Space

Goodness Criteria

Techn o l o g y

Information

Interaction

Society

S

o

l

u

t

i

o

n

Representation

Constructs

Models

Methods

Instantiations

Design Theories

Process

Search Criteria

Foundations

Build Activities

Evaluation

Design Knowledge

11

phenomena our technologies harness (or cause). Research projects may combine both

paradigms of inquiry and contribute to both knowledge bases.

Figure 5: DSR Projects and Modes of Producing and Consuming Design Knowledge (Adapted from

Drechsler & Hevner (2018))

The relationships of design knowledge produced and consumed in DSR projects and the

(design) knowledge bases are shown in Figure 1. This figure is adapted and simplified from

(Drechsler & Hevner 2018) and clearly illustrates paired modes of consuming and producing

knowledge between the DSR project and the W and l knowledge bases. The l-knowledge is

further divided into two sub-categories. The Solution Design Entities collect the prescriptive

knowledge as represented in the tangible artifacts, systems, and processes designed and applied

in the problem solution space. The growth of design theories around these solutions is captured

in the Solution Design Theories knowledge base (Gregor & Hevner 2013). Knowledge can be

projected from the specific application solutions into nascent theories around solution

technologies, actions, systems, and design processes based on the new and interesting

knowledge produced in a DSR project. Thus, we can describe the interactions of a specific DSR

project with the extant knowledge bases in the following consuming and producing modes:

12

Descriptive ( W) Knowledge: W-knowledge (or kernel knowledge) informs the

understanding of a problem, its context, and the underlying design of a solution entity

(Arrow 1). As results of the research project, the design and real-world application of

solution entities or design knowledge enhances our descriptive understanding of how the

world works via the testing and building of new W-knowledge (Arrow 2).

Prescriptive ( l) Solution Design Entities: Existing solution entities, design processes, or

design systems are re-used to inform novel designs of new entities, processes, or systems

(Arrow 5) (vom Brocke & Buddendick 2006). Within a DSR project, effective solution

entities, design processes, or design systems are produced and contributed to new l-

knowledge (Arrow 6).

Prescriptive (l) Solution Design Theories: Solution design knowledge, in the form of

growing design theories, informs the design of a solution entity, a design process or a design

system (Arrow 3). Within a DSR project, effective principles, features, actions, or effects

of a solution entity or a design process or system are generalized and codified in solution

design knowledge (e.g. design theories or technological rules) (Arrow 4).

Three Types of Design Science Projects

In simple terms, a DSR project can make two types of contributions—it can contribute to design

entities or to design theory—and conducting design processes in search of solutions to prob-

lems and theorizing about such processes are what lead to these contributions (vom Brocke,

Maedche 2019). The two type of contributions and related activities are illustrated in Figure 6.

13

Figure 6: DSR Projects' Contributions to Design Knowledge

Early contributions to DSR focused on contributions to design entities (e.g., Hevner et al. 2004

and Peffers et al. 2007). Gregor and Jones (2007) introduce the idea of DSR projects' producing

design theory and conceptualize the anatomy of a design theory by means of six core

components: purpose and scope, constructs, principle of form and function, artifact mutability,

testable propositions, and justificatory knowledge. Gregor and Hevner (2013) outline how both

types of contributions relate to each another and how a DSR project can go beyond the design

of design entities to contribute to design theory by theorizing about the design science process

and the evaluation result achieved.

More recently, Chandra-Kruse, Seidel, & vom Brocke (2019) suggest a third type of

DSR project that builds on design processes that are not conducted as part of the DSR project

itself but at another place and time. Such research opens DSR projects up to theorize about

design that is not motivated by research but by something that happened in, for example,

industry or society. Drawing from archeology research, researchers have described methods for

investigating design processes and artifacts empirically to generate DK. In short, three types of

DSR projects can be differentiated regarding the contribution they intend to make to DK: (1)

projects that contribute to design entities, (2) projects that contribute to both design entities and

design theory, and (3) projects that contribute to design theory without developing a design

entity as part of the same project.

Design Entities

Design Theory

Knowledge

1

3

Projects

2

Design Processing

Design Theorizing

Activity

14

Given the complexity of DSR projects and the various ways a DSR project might

contribute to DK, how comprehensively and effectively a DSR project is planned and

communicated can affect its likelihood of success. Such planning and communication enables

researchers to reflect on and receive feedback about their DSR project in its early stages and to

question and update their scope as they progress in the project.

The Design Science Research Grid

The DSR Grid (vom Brocke & Maedche 2019) enables researchers to effectively plan,

coordinate and communicate their DSR projects. The DSR grid intends to put an entire DSR

project on one page, highlighting its essential components in order to reflect and communicate

its scope. Such representation of a DSR project helps to better plan and communicate a DSR

project as well as to receive feedback from different stakeholders in an early stage and to

question and update the scope as the project progresses. As shown in Figure 7, the DSR Grid

consists of the six most important dimensions of a DSR project.

Problem Description: What is the problem for which a DSR project must identify possible

solution? Problems should be formulated by means of problem statements and characterized by

positioning the problem in a problem space. Research has identified the context, described by

the domain, the stakeholder, time and place, and goodness criteria, the last of which tells when

a problem should be considered solved, as necessary to capture the problem appropriately (vom

Brocke et al. 2020).

Input Knowledge: What prior knowledge will be used in the DSR project? As introduced

above one can distinguish W-knowledge and l-knowledge, the first being descriptive,

explanatory, or predictive, and the second being prescriptive (Gregor & Hevner 2013). Three

15

types input — kernel theories, design theories, and design entities — can be differentiated for

high-level communication about DSR projects.

Figure 7: DSR Grid Comprised of the Six Core Dimensions of a DSR Project

Research Process: What are the essential activities planned (or conducted) to make the

intended contribution? When the intended contribution is design entities, the process includes

build and evaluate activities (Hevner et al. 2004). In particular, these activities also include

grounding the design (vom Brocke et al. 2020) by, for example, conducting literature reviews

(Webster & Watson 2002, vom Brocke et al. 2015), and meta-analysis (Denyer, Tranfield &

Van Aken, 2008). In order to support concurrent design and evaluation, it is suggested to plan

and document the build and evaluation activities in one. DSR tools have been developed (vom

Brocke et al. 2017, Morana et al. 2018) to keep logs of the research process; such logs can

complement a high-level list of research activities used to scope the DSR project in the process

dimension. The process documented here may also include activities for theorizing about the

design. While activities for processing the design can draw from DSR process models like the

DSR Project

Problem Research Process Solution

Concepts Input Knowledge Output Knowledge

16

Peffers et al. (2007) model, activities for theorizing can draw from various research methods

and strategies of inquiry, such as qualitative and quantitative empirical research.

Key concepts: What are the most important concepts used in the research performed in the

DSR project? The words used to describe the research, such as the problem and solution space

that the DSR project focuses on, as well as the concepts used to describe the process and input

and output knowledge must be defined clearly. A clear definition of the key concepts is

particularly important to ensure a rigorous execution of the evaluation activities.

Solution Description: What is the solution to the problem being investigated by a DSR project?

The solution description clearly states the essential mechanisms of the solution (vom Brocke et

al. 2020) and how the solution is positioned in solution space by characterizing its

representation as a construct, a model, a method, an instantiation, or a design theory.

Output Knowledge: What knowledge is produced in the DSR project? Naturally, DSR projects

produce DK, classified as l -knowledge (Gregor & Hevner 2013), but in contrast to the solution

description, the DK generated through the project puts the problem and solution spaces in

relation to each other (vom Brocke et al. 2020). If a DSR project does not intend to generate

design theory but to generate design entities, the description of such entities does not constitute

DK, as it is only the results of the design entity's evaluation in context that constitute DK. These

results are then documented as output knowledge when the project is described.

Factors like the phase of the project (e.g., early planning or documenting completed

research) and the stakeholder group (e.g., industry partners or editors) determine the

perspectives from which and the detail with which the six dimensions may be described.

Multiple versions of the dimensions will usually be created in iterations as a project progresses,

but referring to the dimensions helps researchers to consider the core aspects of a DSR project

17

from the outset and to discuss these aspects with stakeholder groups to shape the project`s

profile further as it goes along.

Conclusion

In this chapter, some important DSR concepts and models have been presented to provide a

foundation for the planning, performing, and disseminating DK from specific DSR projects. In

the following chapters, cases of DSR projects are presented as conducted by experienced

researchers in the field. These cases serve as examples from which to learn in order to inform

one's DSR projects. These case studies provide invaluable experiential knowledge of how

fellow researchers have conducted DSR over the past decades. This case collection is intended

to "live" in that we are always very happy to include new cases of diverse application

environments. The richer the collection, the more useful for the community. Apart from

enjoying to read the cases in the book, authors are cordially invited to get in touch and discuss

how to add their own case to this collection.

References

Becker, J., vom Brocke, J., Heddier, M., Seidel, S. (2015), In Search of Information Systems (Grand)

Challenges: A Community of Inquirers Perspective. Business & Information Systems

Engineering (BISE), 6(1), 39-43.

Chandra-Kruse, L., Seidel, S., & vom Brocke, J. (2019). Design Archaeology: Generating Design

Knowledge from Real-World Artifact Design. Paper presented at the 14th International

Conference on Design Science Research in Information Systems and Technology, Worcester,

MA.

Denyer, D., Tranfield, D., & van Aken, J. E. (2008). Developing design propositions through research

synthesis. Organization Studies, 29(3), 393–413.

Drechsler, A., & Hevner, A. R. (2018). Utilizing, producing, and contributing design knowledge in

DSR projects. In S. Chatterjee, K. Dutta, & R. Sundarraj (Eds.), Lecture Notes in Computer

Science: Vol. 10844. Designing for a Digital and Globalized World (pp. 82–97). Cham,

Switzerland: Springer.

Gregor S. and Jones D. (2007) The Anatomy of a Design Theory. Journal of the Association For

Information Systems, 8(5), 312-335.

Gregor, S., & Hevner, A.R. (2013). Positioning and Presenting Design Science Research for

Maximum Impact. MIS Quarterly, 37(2), 337-355.

Hevner, A. R. 2007. "A three cycle view of design science research," Scandinavian journal of

information systems (19:2), pp. 87–92.

18

Hevner, A.R., March, S.T., Park, J., & Ram, S. (2004). Design Science in Information Systems. MIS

Quarterly, 28(1), 75-105.

Kuechler, B., and Vaishnavi, V. 2008. "The Emergence of Design Research in Information Systems in

North America," Journal of Design Research (7:1), pp. 1–16.

Morana, S., Scheid, M., Gau, M., Benke, I., vom Brocke, J., Fettke, P., Maedche, A. (2018), Research

Prototype: The Design Canvas in MyDesignProcess.com, in: DESRIST 2018 Conference

Proceedings.

Nunamaker, J. F., Chen, M., and Purdin, T. D. 1991. "Systems Development in Information Systems

Research," Journal of Management Information Systems (7:3), pp. 89–106.

Peffers, K., Tuunanen, T., Rothenberger, M.A., & Chatterjee, S. (2007). A Design Science Research

Methodology for Information Systems Research. Journal of Management Information Systems,

24 (3), 45-77.

Seidel, S., Recker, J., vom Brocke, J. (2013), Sensemaking and Sustainable Practicing: Functional

Affordances of Information Systems in Green Transformations. Management Information

Systems Quarterly (MISQ), 37(4), 1275-1299.

Sonnenberg, C., and vom Brocke, J. 2012. "Evaluations in the Science of the Artificial: Reconsidering

the Build-evaluate Pattern in Design Science Research," in Design Science Research in

Information Systems and Technology 2012, Advances in Theory and Practice (Lecture Notes in

Computer Science), Peffers K., Rothenberger M. and Kuechler B. (eds.), Las Vegas, NV, USA,

Springer, Berlin, Heidelberg, pp. 381–397.

Venable, J. R., Pries-Heje, J., & Baskerville, R. L. (2016). FEDS: A framework for evaluation in

design science research. European Journal Information Systems, 25(1), 77–89.

Venable, J., vom Brocke, J., Winter, R. (2019), Designing TRiDS: Treatments for Risks in Design

Science, in: Australasian Journal of Information Systems (AJIS), June 2019.

vom Brocke J., Seidel S. (2012) Environmental Sustainability in Design Science Research: Direct and

Indirect Effects of Design Artifacts. In: Peffers K., Rothenberger M., Kuechler B. (eds) Design

Science Research in Information Systems. Advances in Theory and Practice. DESRIST 2012.

Lecture Notes in Computer Science, vol 7286. Springer, Berlin, Heidelberg

vom Brocke, J., & Seidel, S. (2012). Environmental Sustainability in Design Science Research: Direct

and Indirect Effects of Design Artifacts.. Paper presented at the 7th international conference on

Design Science Research in Information Systems, Las Vegas, USA.

vom Brocke, J., Fettke, P., Gau, M., Houy, C., Maedche, A., Morana, S., Seidel, S. (2017) Tool-

Support for Design Science Research: Design Principles and Instantiation (May 23, 2017).

Available at SSRN: https://ssrn.com/abstract=2972803 or

http://dx.doi.org/10.2139/ssrn.2972803

vom Brocke, J., Maedche, A. (2019), The DSR Grid: Six Core Dimensions for Effectively Planning

and Communicating Design Science Research Projects, in: Electronic Markets, Volume 29,

Issue 3, pp 379–385.

vom Brocke, J., Simons, A., Riemer, K., Niehaves, B., Plattfaut, R., & Cleven, A. (2015). Standing on

the Shoulders of Giants: Challenges and Recommendations of Literature Search in Information

Systems Research. Communications of the Association for Information Systems, 37(1), Article

9, 205-224.

vom Brocke, J., Watson, R., Dwyer, C., Elliot, S., & Melville, N. (2013). Green Information Systems:

Directives for the IS Discipline. Communications of the Association for Information Systems

(CAIS), 33(30), 509-520.

19

vom Brocke, J., Watson, R., Dwyer, C., Elliot, S., & Melville, N. (2013). Green Information Systems:

Directives for the IS Discipline. Communications of the Association for Information Systems

(CAIS), 33(30), 509-520.

vom Brocke, J., Winter, R., Hevner, A., Maedche, A. (2019), Accumulation and Evolution of Design

Knowledge in Design Science Research – A Journey Through Time and Space, in: Journal of

the Association for Information Systems (JAIS), forthcoming.

Walls, J. G., Widmeyer, G. R., and El Sawy, O. A. 1992. "Building an Information System Design

Theory for Vigilant EIS," Information Systems Research (3:1), pp. 36–59.

Watson, R. T., Boudreau, M.-C., & Chen, A. J. W. (2010). Information Systems and environ-mentally

sustainable development: Energy Informatics and new directions for the IS com-munity. MIS

Quarterly, 34(1), 23-38.

Webster J. and Watson R.T. (2002). "Analyzing the past to prepare for the future: Writing a literature

review", MIS Quarterly, vol. 26, no. 2, xiii –xxiii.

Winter, R., & Albani, A. (2013). Restructuring the design science research knowledge base: A

onecycle view of design science research and its consequences for understanding organizational

design problems. In R. Winter, & A. Albani (Eds.), Lecture Notes in Information Systems and

Organisation: Vol. 1. Designing Organizational Systems: An Interdisciplinary Discourse (pp.

381– 397). Heidelberg, Germany: Springer.

... To restructure and expand the existing know-how in dynamic orchestration, the principle of Design Science Research (DSR) was used. As it is fundamentally a problem-solving paradigm, DSR 'seeks to enhance existing human knowledge with the creation of innovative artefacts and the generation of design knowledge via innovative solutions to real-world problems' [15]. Therefore, the DSR methodology is considered to be a well-suited methodology for exploring the practical usefulness of generically designed technological artefacts to answer the research questions within the field of information systems [16,17]. ...

... 2021, 11, 7956 4 of 25 could be used as demonstrators of the usability of the designed architecture, an artefact of Step III. The best-fitting use-cases would be those that involve experimentation, simulation, case-study or proof-of-concept [15]. The Demonstration is covered in Section 4 of the paper, where an industrial case-study is discussed. ...

... For the fourth research step, we found adequate use-cases that could be used as demonstrators of the usability of the designed architecture, an artefact of Step III. The best-fitting use-cases would be those that involve experimentation, simulation, case-study or proof-of-concept [15]. The Demonstration is covered in Section 4 of the paper, where an industrial case-study is discussed. ...

Amid the current industrial revolution, a total disruption of the existing production lines may seem to be the easiest approach, as the potential possibilities seem limitless when starting from the ground up. On the business side, an adaptation of existing production lines is always a preferred option. In support of adaptation as opposed to disruption, this paper presents a new approach of using production process orchestration in a smart factory, discussed in an industrial case-study example. A proposed smart factory has the Orchestrator component in its core, responsible for complete semantical orchestration of production processes on one hand, and various factory resources on the other hand, in order to produce the desired product. The Orchestrator is a complex, modular, highly scalable, and pluggable software product responsible for automatised planning, scheduling, and execution of the complete production process. According to their offered capabilities, non-smart and smart resources-machines, robots, humans-are simultaneously and dynamically assigned to execute their dedicated production steps.

Enterprise software packages are increasingly designed as extendable software platforms. These platforms are characterised by modular architecture that allows third parties to innovate and create value through the development of complementary applications. The development process of complementary applications from scratch is resource-intensive. One way of optimising the development process is by using the component-based software engineering (CBSE) approach that focuses on software reuse and suggests building applications with reusable components. There is a considerable amount of literature on CBSE; however, there has been little discussion on how component-based software engineering can strengthen third-party application development in the context of an enterprise software platform ecosystem. Specifically, it is unclear how the challenge of component trustworthiness can be addressed in this context. To explore this, we conducted a design science research (DSR) study to answer the following question: What are design principles pertaining to component trustworthiness for implementing a component repository that facilitates component reuse in an enterprise software platform ecosystem? In our study, we have explored the potential for component reuse in the ecosystem of the global health software platform DHIS2 by designing and developing a prototype component repository. During the design and development process, two design principles were identified: Principle of component trustworthiness and Principle of balanced certification. These principles are to guide researchers and practitioners on how a component repository can be implemented in the context of an enterprise software platform ecosystem.

Purpose Knowledge- and communication-intensive domains still long for a better support of creativity that considers legal requirements, compliance rules and administrative tasks as well, because current systems focus either on knowledge representation or business process management. The purpose of this paper is to discuss our model of integrated knowledge and business process representation and its presentation to users. Design/methodology/approach The authors follow a design science approach in the environment of patent prosecution, which is characterized by a highly standardized, legally prescribed process and individual knowledge study. Thus, the research is based on knowledge study, BPM, graph-based knowledge representation and user interface design. The authors iteratively designed and built a model and a prototype. To evaluate the approach, the authors used analytical proof of concept, real-world test scenarios and case studies in real-world settings, where the authors conducted observations and open interviews. Findings The authors designed a model and implemented a prototype for evolving and storing static and dynamic aspects of knowledge. The proposed solution leverages the flexibility of a graph-based model to enable open and not only continuously developing user-centered processes but also pre-defined ones. The authors further propose a user interface concept which supports users to benefit from the richness of the model but provides sufficient guidance. Originality/value The balanced integration of the data and task perspectives distinguishes the model significantly from other approaches such as BPM or knowledge graphs. The authors further provide a sophisticated user interface design, which allows the users to effectively and efficiently use the graph-based knowledge representation in their daily study.

  • Anastasia Bengtsson Anastasia Bengtsson

There is an increase in the development of generic software systems built to serve multiple organizations and used for different purposes. DHIS2, a generic web-based health management information system platform, is an example of such systems and the focus of my thesis. The extensible core of DHIS2 allows the development of complementary web applications by outside parties as a way of contributing to the DHIS2 platform. The challenge here is that developing these web applications from scratch can be time-consuming and resource-inefficient when similar applications are developed. One way of addressing this challenge is by using the component-based software engineering (CBSE) approach. The main idea behind CBSE is the development of applications by reusing configurable software components. However, previous research identified several challenges that pertain to component reuse, including cataloging and distribution of reusable software components, their trustworthiness, and discoverability. My Master's project's practical aim was to design, develop, and evaluate a component repository, DHIS2 Shared Component Platform, that facilitates component reuse within the DHIS2 platform ecosystem. This project involved close collaboration with developers in HISP East Africa and the DHIS2 core team at the University of Oslo. The component repository consists of a website (built using React) that aggregates reusable components and two other modules that support the process of component certification: a command-line interface (built using TypeScript) to provide functionality for pre-certification, and a GitHub repository with an automated certification workflow using GitHub Actions workflow. This study used the Design Science Research (DSR) methodology within a pragmatic research paradigm to contribute to the body of knowledge by developing a set of theoretically and empirically grounded design principles. These principles contribute to the body of knowledge on how component repositories can be designed and developed in a context of a software platform ecosystem. The established set of design principles addresses software reuse challenges identified through empirical data analysis and challenges discussed in the literature on CBSE. These principles address component trustworthiness, component discoverability, the role of a certifier, component repository adoption, its complexity, and maintainability.

Sir Isaac Newton famously said, "If I have seen further it is by standing on the shoulders of giants." Research is a collaborative, evolutionary endeavor-and it is no different with design science research (DSR) which builds upon existing design knowledge and creates new design knowledge to pass on to future projects. However, despite the vast, growing body of DSR contributions, scant evidence of the accumulation and evolution of design knowledge is found in an organized DSR body of knowledge. Most contributions rather stand on their own feet than on the shoulders of giants, and this is limiting how far we can see; or in other words, the extent of the broader impacts we can make through DSR. In this editorial, we aim at providing guidance on how to position design knowledge contributions in wider problem and solution spaces. We propose (1) a model conceptualizing design knowledge as a resilient relationship between problem and solution spaces, (2) a model that demonstrates how individual DSR projects consume and produce design knowledge, (3) a map to position a design knowledge contribution in problem and solution spaces, and (4) principles on how to use this map in a DSR project. We show how fellow researchers, readers, editors, and reviewers, as well as the IS community as a whole, can make use of these proposals, while also illustrating future research opportunities.

Design Science Research (DSR) has many risks. Researchers inexperienced in DSR, especially early career researchers (ECRs) and research students (e.g. PhD students) risk inefficient projects (with delays, rework, etc.) at best and research project failure at worst if they do not manage and treat DSR risks in a proactive manner. The DSR literature, such as the Risk Management Framework for Design Science Research (RMF4DSR), provides advice for identifying risks, but provides few suggestions for specific treatments for the kinds of risks that potentially plague DSR. This paper describes the development of a new purposeful artefact (TRiDS: Treatments for Risks in Design Science) to address this lack of suggestions for treatment of DSR risks. The paper describes how the purposeful artefact was developed (following a DSR methodology), what literature it draws upon to inspire its various components, the functional requirements identified for TRiDS, and how TRiDS is structured and why. The paper also documents the TRiDS purposeful artefact in detail, including four main components: (1) an extended set of risk checklists (extended from RMF4DSR), (2) a set of 47 specific suggestions for treating known risks in DSR, (3) a classification of the treatments identified into 14 different categories, and (4) a look-up table for identifying candidate treatments based on a risk in the extended risk checklists. The treatment suggestions and guidance in TRiDS serve as a supplement to RMF4DSR by helping DSR researchers to identify treatments appropriate for a 1 Venable, J., vom Brocke,

When formulating prescriptive design knowledge in design science research (DSR), we usually reflect on our vision of created artifacts, relevant design decisions, and what we have learned throughout the design process. Seldom do we attempt to extract prescriptive knowledge from existing and widely acknowledged artifacts in the manner of ex-post facto or in situ. But what can we learn from decades of designing digital artifacts that have fundamentally revamped work processes across industries, allowed for the emergence of new business models, and even spurred entirely new industries? This essay is inspired by the way archaeologists make sense of the past and represent the resulting knowledge. We propose a novel approach to the analysis of digital artifacts based on the archaeological approaches to context reconstruction and artifact analysis. We explain how a design archaeologist can shift among the perspectives of designers, users, and the generated artifact to make inferences about the artifact (i.e., design artifact), how it has been designed (i.e., design process), the context in which it has been designed (i.e., the design context), and the situations in which it has been used (i.e., the use contexts).

Like all research projects, researchers should carefully plan and manage design projects to ensure valid and meaningful research outcomes. In this paper, we present the Design Canvas concept implemented in the MyDesignProcess. com platform. The Design Canvas captures the most important dimensions of a design project and displays them at a glance. In this paper, we describe the Design Canvas implementation in MyDesignProcess.com and illustrate with two exemplary design science research projects documented retrospectively its usage. Thereby, we illustrate how the Design Canvas can improve the structuring and communication of design projects.

Design Science Research (DSR) is now an accepted research paradigm in the Information Systems (IS) field, aiming at developing purposeful IT artifacts and knowledge about the design of IT artifacts. A rich body of knowledge on approaches, methods, and frameworks supports researchers in conducting DSR projects. While methodological guidance is abundant, there is little support and guidance for documenting and effectively managing DSR processes. In this article, we present a set of design principles for tool support for DSR processes along with a prototypical implementation (MyDesignProcess.com). We argue that tool support for DSR should enable researchers and teams of researchers to structure, document, maintain, and present DSR, including the resulting design knowledge and artifacts. Such tool support can increase traceability, collaboration, and quality in DSR. We illustrate the use of our prototypical implementation by applying it to published cases, and we suggest guidelines for using tools to effectively manage design-oriented research.

The paper motivates, presents, demonstrates in use, and evaluates a methodology for conducting design science (DS) research in information systems (IS). DS is of importance in a discipline oriented to the creation of successful artifacts. Several researchers have pioneered DS research in IS, yet over the past 15 years, little DS research has been done within the discipline. The lack of a methodology to serve as a commonly accepted framework for DS research and of a template for its presentation may have contributed to its slow adoption. The design science research methodology (DSRM) presented here incorporates principles, practices, and procedures required to carry out such research and meets three objectives: it is consistent with prior literature, it provides a nominal process model for doing DS research, and it provides a mental model for presenting and evaluating DS research in IS. The DS process includes six steps: problem identification and motivation, definition of the objectives for a solution, design and development, demonstration, evaluation, and communication. We demonstrate and evaluate the methodology by presenting four case studies in terms of the DSRM, including cases that present the design of a database to support health assessment methods, a software reuse measure, an Internet video telephony application, and an IS planning method. The designed methodology effectively satisfies the three objectives and has the potential to help aid the acceptance of DS research in the IS discipline.

The paper reports on the results of a Delphi study with 143 information systems (IS) academics that was designed to explore what IS academics perceive to be the grand challenges of the IS discipline. The results provide evidence that the scholarly IS discipline is still much concerned with itself, for instance, in terms of its identity, relevance, foundational theory, or methodological pluralism – suggesting that the old debate on IS identity is not yet overcome. It thus cannot be claimed that the study identifies the grand challenges of the discipline – still it becomes noticeable that the academic community sees potentials for the IS discipline to have societal impact. A total of 21 challenges are identified, of which six challenges are categorized as ''meta challenges for further developing the IS discipline'' and the remaining 15 challenges are categorized as ''IS research challenges'' pertaining to socio-technical systems, IS infrastructures, society and ecology, as well as social well-being and affectivity. We provide a ranking of all challenges according to their relevance, potential impact, and possible time frame of realization. The results have some important implications for IS as a discipline as well as its prospective future societal role. It is hoped that through our study we can contribute to the important debate on the challenges of the academic IS discipline.

When formulating prescriptive design knowledge in design science research (DSR), we usually reflect on our vision of created artifacts, relevant design decisions, and what we have learned throughout the design process. Seldom do we attempt to extract prescriptive knowledge from existing and widely acknowledged artifacts in the manner of ex-post facto or in situ. But what can we learn from decades of designing digital artifacts that have fundamentally revamped work processes across industries, allowed for the emergence of new business models, and even spurred entirely new industries? This essay is inspired by the way archaeologists make sense of the past and represent the resulting knowledge. We propose a novel approach to the analysis of digital artifacts based on the archaeological approaches to context reconstruction and artifact analysis. We explain how a design archaeologist can shift among the perspectives of designers, users, and the generated artifact to make inferences about the artifact (i.e., design artifact), how it has been designed (i.e., design process), the context in which it has been designed (i.e., the design context), and the situations in which it has been used (i.e., the use contexts).

We distinguish several design knowledge types in IS research and examine different modes of utilizing and contributing design knowledge that can take place during design science research (DSR) projects. DSR projects produce project design knowledge, which is project-specific, possibly untested, conjectural, and temporary; thus, distinct from the more stable contributions to the propositional and prescriptive human knowledge bases. We also identify solution design knowledge as distinct from solution design entities in the prescriptive knowledge base. Each of the six modes of utilizing or contributing knowledge (i.e. design theorizing modes) we examine draws on different knowledge types in a different way to inform the production of project design knowledge (including artifact design) in a DSR project or to grow the human knowledge bases in return. Design science researchers can draw on our design theorizing modes and design knowledge perspectives to utilize the different extant knowledge types more consciously and explicitly to inform their build and evaluation activities, and to better identify and explicate their research's contribution potential to the human knowledge bases.