European Journal of Information Systems (2015) 24, 107–115
© 2015 Operational Research Society Ltd. All rights reserved 0960-085X/15
ISSUES AND OPINION
Distinguishing and contrasting two strategies
for design science research
Juhani Iivari
Department of Information Processing Science,
University of Oulu, Oulu Yliopisto, Finland
Correspondence: Juhani Iivari, Department of
Information Processing Science, University of
Oulu, PO Box 3000, Oulu yliopisto, 90014,
Finland.
Fax: +358 8 553 1890;
E-mail: juhani.iivari@oulu.fi
Received: 25 June 2013
Revised: 11 October 2013
Accepted: 25 November 2013
www.palgrave-journals.com/ejis/
Abstract
This paper distinguishes and contrasts two design science research strategies in
information systems. In the first strategy, a researcher constructs or builds an IT
meta-artefact as a general solution concept to address a class of problem. In the
second strategy, a researcher attempts to solve a client’s specific problem by build-
ing a concrete IT artefact in that specific context and distils from that experience
prescriptive knowledge to be packaged into a general solution concept to address a
class of problem. The two strategies are contrasted along 16 dimensions represent-
ing the context, outcomes, process and resource requirements.
European Journal of Information Systems (2015) 24(1), 107–115. doi:10.1057/ejis.2013.35;
published online 7 January 2014
Keywords: design science research; design research; design science research strategies
Introduction
There has been increasing interest in design science research (DSR) in the
information systems (IS) discipline (Nunamaker et al, 1990–1991; Walls et al,
1992; March & Smith, 1995; Hevner et al, 2004; Iivari 2007; Peffers et al,
2007–2008; Vaishnavi & Kuechler, 2008; Hevner & Chatterjee, 2010).
DSR attempts to provide new innovative artefacts that address hereto-
fore unsolved problems or address them more effectively/efficiently than
previous attempts (Hevner et al, 2004).
The scientific discourse on DSR has suffered from some confusion
(Baskerville, 2008; Kuechler & Vaishnavi, 2008; Winter, 2008). The purpose
of this paper is to clarify the discourse by distinguishing two DSR strategies.
In the first strategy, a researcher constructs an IT meta-artefact (Iivari, 2003)
as a general solution concept (van Aken, 2004) possibly to be instantiated
(March & Smith, 1995) into a specific solution concept (van Aken, 2004) or a
concrete IT artefact (application) to be adopted and used in a specific
context. An alternative strategy is that a researcher attempts to solve a
client’s specific problem by building a concrete IT artefact (application) in
that specific context and distils from it knowledge to be generalized into a
general solution concept. After introducing these strategies they will be
contrasted along 16 dimensions.
To the author’s knowledge the two DSR strategies have not been separated in
the prior IS literature, and still less contrasted with each other. The present
essay proposes that DSR covers both. At the same time it is important to be
aware that they differ considerably from each other in several respects.
Two strategies of DSR
Introduction
The scientific discourse on DSR is still in a state of conceptual confusion.
Kuechler & Vaishnavi (2008) note that we still lack ‘a common
108 Distinguishing and contrasting two strategies for DSR Juhani Iivari

understanding of the definition and scope of design
research (DR) in IS’ and question whether it is ‘research
with design as a topic of investigation or research with
design as a method of investigation’ (p. 8). They also
recommend that ‘design research’ should be allowed to
have the breadth it has achieved in other design fields,
rather than constraining it to the constructive view, as
advocated by Hevner et al (2004).
The confusion is exaggerated by the terminology. Labels
such as ‘design science research’ and ‘design research’
are used more or less interchangeably in the IS litera-
ture without any respect to the terminology used in the
50-year history of design studies (Cross 1993, 2001;
Bayazit, 2004). Iivari (2012) contrasts the two, interpreting
that DSR is research with design as a method of investi-
gation and DR is broader, with design as a method of
investigation and a topic of investigation.
The present paper is strictly limited to DSR in the above
meaning, which can be summarized in three interrelated
points:
1. DSR produces new innovative meta-artefacts as its
constitutive and distinctive research outputs.
2. Constructive research on building new innovative
meta-artefacts is the core research activity of DSR.
3. New innovative meta-artefacts follow the epistemo-
logy of utility rather than the epistemology of truth
(likeness).
These points imply that the view of DSR adopted in the
present paper is in line with the constructive view advo-
cated by, for example, Hevner et al (2004).
The early views of DSR seem to assume that one con-
structs the DSR contribution first and possibly instantiates it.
In the case of March & Smith (1995) and Hevner et al (2004),
the very word ‘instantiation’ simply implies this – there is
something (constructs, models, methods) to be instantiated.
Nunamaker et al (1990–1991) also assume this DSR strategy
when they advocate systems development as a research
method for IS research. In their view the developed system
serves as a proof of concept and provides an artefact
that becomes the focus of expanded, continuing research.
Similarly, Walls et al (1992) frame their design theories in
terms of meta-requirements and meta-design, pointing out
that meta-requirements do not address a single problem
but a class of problems, and meta-design describes a class of
systems rather than a single system. They also see the
implementation of a system (prototype) necessary only in
the testing of the design theory.
Markus et al (2002) and Sein et al (2011), on the
contrary, have applied a DSR strategy in which one
first builds an IT artefact in a specific client context and
based on that experience attempts to distil lessons into
a generalized DSR contribution. Yet, they do not explicitly
introduce their views as an alternative DSR strategy.
The rest of this section contrasts the two DSR strategies
using a simple context-process-outcome framework from
Denison et al (1996), which is supplemented to include
resources as a fourth aspect. Context describes differences
in the research settings of the DSR projects, covering
the client relationship, problems to be addressed and the
associated major uncertainties. The outcomes aspect
focuses on the major artefacts developed in the case of
the strategies and the nature of those artefacts. The process
aspect addresses the two strategies in terms of drivers of
DSR process, research methods used and the process of
generalizing the results. Finally, resources refer to some
practical differences between the strategies.
At a more detailed level, the contrasting takes place
along 16 dimensions, which are significant to understand-
ing the essential differences between the strategies and/or
are practically relevant to researchers attempting to make
a choice between them. As a consequence, many of the
dimensions are specific to the two strategies, reflecting
their essential differences.
The purpose of the following analysis is to provide a
detailed point-by-point comparison of the two strategies.
Since there are not many published examples of DSR
following Strategy 2, some points in the analysis are tenta-
tive generalizations. The two examples of DSR Strategy 2
(i.e., Markus et al, 2002 and Sein et al, 2011) are analysed in
detail in Iivari (2012) along the 16 dimensions included in
Tables 1–4.

Table 1 Contrasting the two strategies of DSR – context

Dimension Strategy 1 Strategy 2

1. Researcher–client relationship A client may be involved, but not necessarily Client involvement is inevitable

2. Major problems to be addressed 1. A general problem (a class of problem), more or 1. A specific problem encountered by a client (or a
less informed by specific problems in practice set of clients)
2. The general problem (the DSR problem) to be
figured out during the DSR project

3. Typical uncertainty of a DSR 1. Uncertainty about the new, innovative general 1. Uncertainty about the specific solution to the
project solution concept to the class of problem specific problem encountered by the client (or a
2. Uncertainty about the total complexity of specific set of clients)
problems and their solutions in practice 2. Uncertainty about the possible DSR contribution

European Journal of Information Systems

 Distinguishing and contrasting two strategies for DSR
Context
As Table 1 notes, DSR following Strategy 1 does not
necessarily have any identifiable client(s). A researcher just
has some understanding of the potential would-be clients
and their problems, or a more general demand for a new
solution. In the case of Strategy 2, a relationship with an
identifiable client (or set of clients) is inevitable, since the
whole DSR project commences with a practical problem
encountered by a client and an attempt to find a specific
solution.
DSR following Strategy 1 starts with a general problem
(a class of problem) to be addressed (e.g., Walls et al, 1992).
On the contrary, DSR following Strategy 2 starts with
a specific problem encountered in practice. The challenge
in the case of Strategy 2 is to identify the general problem
(the DSR problem). Therefore, the DSR problem in both
cases is a general problem (a class of problem).
Applying the distinction between an ‘empty head’ and
an ‘open mind’ (Dey, 1993), Strategy 2 does not imply that
a researcher enters a DSR project ‘empty headed’ without
an initial idea of what the DSR contribution might or will
be, although (s)he should maintain an open mind and be
sensitive to what the client’s real problem is, how to
address it and what is found when addressing it. Otherwise
(s)he can easily follow the aphorism, ‘If all you have is a
hammer, everything looks like a nail’.
The two examples of DSR Strategy 2 (Markus et al, 2002;
Sein et al, 2011) illustrate the need for an open mind, and
the usefulness of letting the experiences of addressing the
client’s specific problem guide the process. In both cases
the DSR contribution evolved considerably during the
process. This need is at least as important as in any
empirically grounded qualitative research that aims at
theory building (Díaz Andrade, 2009), and perhaps more
important since the hammer is not only used to make
sense of the world, but to change it.
These two strategies comprise different uncertain-
ties related DSR projects. Even though DSR following
Strategy 1 often faces the issue of what is the problem,
the key uncertainty concerns the general solution to
the class of problem selected for the DSR project
in question. This general solution concept should be
a new innovative meta-artefact in order to qualify as a
DSR contribution.
Although the general problem selected by a researcher
following Strategy 1 may be informed by specific problems
in practice, often (s)he faces uncertainty about the real
nature of the specific problems in practice, and about the
specific solutions to them. (S)he does not necessarily
understand the total complexity of specific problems –
complexity due to the specific problem encountered in a
specific context (e.g., organization), possibly with unique
characteristics – implied by the class, especially if (s)he
does not have a direct relationship with any specific client.
As a consequence, many times researchers following Strat-
egy 1 are not so much concerned with these specific
problems, but leave it to practitioners to interpret, adopt
and adapt the constructed meta-artefact.
Juhani Iivari 109
Researchers following Strategy 2, on the contrary, start
with a specific problem encountered by a client. As
a consequence they face the total complexity of the
specific problem right from the beginning. There is, of
course, uncertainty about the specific solution to this
specific problem, that is, how to address the client’s
specific problem effectively and efficiently.
As noted above, a researcher following Strategy 2 faces
considerable uncertainty about the potential DSR contri-
bution: what is the general problem to be addressed and
what might be a new innovative solution to it? This
generalization problem will be discussed later in the con-
text of Dimension 12. At this stage, a researcher can only
hope that the process of addressing the client’s specific
problem will help in that search.
Outcomes
Referring to Table 2, artefacts built in a DSR project
following Strategy 1 comprise two types of artefacts:
(1) conceptual IT meta-artefacts (e.g., constructs, models
and methods), and (2) their optional instantiation as ‘real
system implementations’. The adjective ‘conceptual’
emphasizes that meta-artefacts are conceptual rather
than physical like the hardware components used in
technical IS implementation. The instantiation may serve
as a proof of concept (Nunamaker et al, 1990–1991) and
may also be useful in the field evaluation of the conceptual
artefact. The implementation implied by the instantiation
may also inspire learning. Yet, instantiations are only
secondary DSR outcomes. The essential point is what the
design knowledge instantiations entail, that is, in the
underlying conceptual meta-artefact.
DSR Strategy 2 may comprise building three types
of artefacts: (1) real system implementations to address
the specific problems of clients, (2) conceptual IT meta-
artefacts as DSR contributions and (3) their instantiation.
The design and implementation of the real system as
a specific solution to the client’s specific problem mainly
serves as a source of inspiration for the DSR contribution,
but does not necessarily instantiate the latter. Therefore, a
separate instantiation may be needed as a proof of concept
or for evaluation reasons. Furthermore, taking an analogy
from theory building – theory testing, where it is not a
good practice to use the same dataset for theory building
and for theory testing, one can question if under Strategy 2
it is justified to test a DSR contribution in the same client
context where it was developed (constructed).
If we accept that DSR provides IT meta-artefacts that
support building concrete IT artefacts (applications) in
practice, it is obviously important to understand the
nature of these concrete IT artefacts. Table 2 distinguishes
a priori designable artefacts and emergent artefacts (Iivari,
2003), suggesting that Strategy 1 assumes the former and
Strategy 2 the latter.
Both examples of DSR Strategy 2 emphasize emergence
in their studies – emergent knowledge processes (EKP) in
the case of Markus et al (2002) and the emergent nature of
European Journal of Information Systems
110 Distinguishing and contrasting two strategies for DSR Juhani Iivari

Table 2 Contrasting the two strategies of DSR – outcomes

Dimension Strategy 1 Strategy 2

4. Artefacts built 1. Conceptual IT meta-artefact as a DSR
contribution
2. Possibly a real system implementation
(instantiation) of the conceptual IT
meta-artefact
1. A real system implementation as a specific solution
to a problem encountered in practice
2. Conceptual IT meta-artefact as a DSR contribution
3. Possibly a real system implementation
(instantiation) of the conceptual IT meta-artefact

5. Primary role of the real system
implementation
Instantiation as a proof of concept and
possibly used in the evaluation
The real system as a specific solution to a problem
encountered in practice implemented primarily as a
source of inspiration
Instantiation as a proof of concept and possibly used in
the evaluation

6. Nature of the target IT artefacts A priori designable system Emergent system

7. Typical nature of the IT meta-artefact A new, innovative concept for a software- New, innovative design principles
hardware system or a new innovative
systems development approach, method,
technique

8. Innovativeness Innovativeness of the IT meta-artefacts Mixed tendencies

as the DSR contribution varies greatly
+ if an interdisciplinary research team, it may foster
creativity
+ practical problems may challenge existing solutions,
knowledge and wisdoms
– easily focused on client’s current problems
– clients may be reluctant to experiment with cutting-
edge technology

9. Practical relevance Varies greatly A priori better equipped to address immediate practical
problems

IT artefacts in Sein et al (2011). According to Markus et al
(2002), ‘emergent processes are characterized by highly
unpredictable user types and work contexts. The unpre-
dictability extends to when and why the process is per-
formed and whether support tools will be used’ (p. 183).
Sein et al (2011) propose that their Action Design Resea-
rch (ADR) method is particularly suitable in the case
of ensemble artefacts (Orlikowski & Iacono, 2001) that
emerge from design, use and on-going refinement in
context. Although Orlikowski & Iacono (2001) introduce
the ensemble view as one view of IT artefacts rather than
as a class of IT artefacts, the positioning of their ADR
method in Sein et al (2011) seems intuitively reasonable. If
the idea of DSR is to provide IT meta-artefacts for emergent
IT artefacts, it seems difficult to understand the latter
without studying them as an emergent phenomenon.
Referring to Dimension 7 in Table 2, typically new inno-
vative IT meta-artefacts produced by DSR following
Strategy 1 are concepts for software-hardware systems or
systems development approaches, methods and techni-
ques. They tend to be relatively complex when compared
with the IT meta-artefacts suggested by Markus et al (2002)
and Sein et al (2011), which are fairly light design princi-
ples for emergent IT artefacts (applications).
Of course, the two examples of DSR Strategy 2 represent
a very limited sample to draw far-reaching conclusions.
Nevertheless, there are three possible explanations for the
difference in the complexity of the meta-artefacts con-
structed. First, researchers following Strategy 2 put consider-
able effort into solving the client’s specific problem (see
Dimension 2 in Table 1), usually by building a real system
implementation as a specific solution to that problem (see
Dimension 4 in Table 2). Therefore, inventing and con-
structing the IT meta-artefact as the DSR contribution is
only part of their research effort, even though it is consti-
tutive. Second, the DSR contribution inspired by the above
real system implementation may be figured out and con-
structed as an afterthought. This may affect the outcome.
Third, the IT meta-artefact produced under Strategy 2, even
if light, is ‘grounded’ in practice and therefore its practical
relevance may a priori be considered higher or more likely
(see Dimension 9 in Table 2). It may be that our research
community is ready to accept these lighter DSR contribu-
tions of Strategy 2 research more easily than in the case of
Strategy 1, where they are not equally ‘grounded’ and their
practical relevance is not equally obvious.
The innovativeness of the IT meta-artefact as a DSR
contribution may vary greatly in the case of Strategy 1. More

European Journal of Information Systems

 Distinguishing and contrasting two strategies for DSR
interestingly, Table 2 also suggests that Strategy 2 includes
aspects that both support innovativeness and limit it. As
will be pointed out below, a research team using Strategy 2
may be multidisciplinary or interdisciplinary. The different
worldviews and perspectives implied by such teams support
creativity (Hage, 1980). The practical problems encountered
may also challenge existing solutions, knowledge and wis-
dom (Markus et al, 2002; Sein et al, 2011).
On the other hand, DSR following Strategy 2 easily
focuses on a client’s current problems rather than their
future problems, the relevance of which may be difficult to
figure out. For example, major innovations in computing,
such as the relational model (Codd, 1970) and the object-
oriented features of the Simula 67 language (Dahl et al,
1968), would have been quite difficult to develop follow-
ing DSR Strategy 2, since there were very few, if any, clients
who understood the practical significance of those inno-
vative ideas when they were developed.
Existing technology may also limit the researcher–client
interaction. For instance, in the early 1970s, computers did
not have the capacity to demonstrate the relational model
in practical settings. Furthermore, since DSR by definition
attempts to construct new and innovative meta-artefacts,
it often operates at the edge of existing technology.
Such cutting-edge technology is not necessarily robust.
Petroski (1982) claims that failure is central to understand-
ing engineering, and that lessons learned from failures can
advance engineering knowledge more than successful
cases. Similarly, DSR may push a new technology to its
Table 3 Contrasting the two strategies of DSR – process
Dimension Strategy 1
10. Major process driver The constructed meta-artefact as a general solution
concept, if to be tested and evaluated on the field
11. Research methods Constructive (in building the meta-artefact)
Empirical (in the evaluation)
– laboratory experiment
-–field experiment
– field study
– case study
– action research
12. Generalization Included in the problem statement
Juhani Iivari 111
limit until it collapses. However, the client’s interest is
usually that the technology employed is proven and robust
and does not disturb the performance of their operation
and daily work. Having a technology that fails would be
unlikely to be appropriate or agreeable to the client.
Weedman (1998) describes such a conflict of interest in
the Sequoia 2000 project. It was essentially a combined
DSR and Action Research (AR) project, although she does
not refer to AR in her paper. The project was comprised of
computer scientists who acted as researchers and earth
scientists who acted as users. Weedman describes the con-
flict of interest when the technology was repeatedly pushed
to the limit until it broke, with consequent costs to the users
when the system crashed and the users’ work came to a halt.
Related to Dimension 9, Table 2 assumes that the
practical relevance of DSR following Strategy 1 varies
greatly. The relational data model (Codd, 1970) is a clear
example of extremely high relevance, although it was
proposed about 10 years before we had the technology
to instantiate the concept in practice. A priori DSR adop-
ting Strategy 2 is better equipped to address immediate
problems in practice, but as argued above, it has limi-
tations in promoting more radical and disruptive inno-
vativeness (see Dimension 8 in Table 2).
Process
The two DSR strategies differ with regard to the major
process drivers (see Table 3). As argued above, it is not
necessary or sometimes even possible to test and evaluate
Strategy 2
Experiences from the process of addressing the specific
solution to a problem encountered in practice
Action Research or Action Design Research (in the
intervention)
Constructive (when constructing the general solution
concept or IT meta-artefact)
Other empirical (if separate evaluation)
– field experiment
-–field study
-–case study
– action research
(1) Identify various problems encountered while
constructing a real system implementation as a specific
solution to a problem encountered by a client
(2) Generalize these specific problems into a general class
of problems
(3) Identify lessons from (a) the real system implementation
as a specific solution to the client’s problem and/or (b)
the process of developing that specific solution
(4) Generalize these lessons into an IT meta-artefact as a
general solution concept (e.g., design principles)
(5) Associate the general solution concept with the class of
problems identified
European Journal of Information Systems
112 Distinguishing and contrasting two strategies for DSR
the constructed IT meta-artefact on the field when follow-
ing DSR Strategy 1. However, if it is done, the process is
typically driven by the meta-artefact in question. This
process of testing and evaluation may be iterative, consist-
ing of several cycles, with the meta-artefact being revised
between cycles. Yet, the question is about Strategy 1, in
which the evolving meta-artefact drives the process.
DSR following Strategy 2, on the contrary, is driven by
the experiences of the process addressing the specific
problem in practice. However, once the DSR contribu-
tion is figured out, it starts more and more to drive the
process.
This difference between process drivers has some affinity
with the forcing and emergence debate in Grounded
Theory (Glaser, 1992; Boychuk Duchscher & Morgan,
2004). If Strategy 1 includes field testing and evaluation,
it represents ‘forcing’, where a researcher has the IT meta-
artefact to be tested and evaluated. Actually, this forcing
is stronger in the DSR context than in Grounded Theory,
since the meta-artefact to be tested and evaluated is
used in an intervention to change the world, whereas in
Grounded Theory forcing means forcing a preconceived
conceptual model on data. Strategy 2, on the other hand,
represents emergence rather than forcing, even though it
is in a weaker form. Since the purpose of DSR is not to
build a theory that is faithful to reality and the data about
it, it is not necessary that the DSR contribution is closely
connected to the experience of addressing the client’s
specific problem. The latter can just serve as an inspiration
for the DSR contribution.
Referring to research methods, the distinction between
the two strategies helps to understand their role in DSR.
When following Strategy 1, constructing the IT meta-
artefact as a general solution concept is a central activity.
Therefore, constructive research methods, such as those of
Nunamaker et al (1990–1991), dominate DSR following
Strategy 1. Empirical methods are mainly used in the
evaluation of the constructed IT meta-artefacts.
DSR adopting Strategy 2 relies more on AR (Markus et al,
2002) or ADR (Sein et al, 2011) in the intervention. This AR
or ADR intervention comprises constructing the real sys-
tem implementation as a specific solution to the client’s
problem encountered in practice. Constructive research in
the context of Strategy 2 is confined to the process of
building the IT meta-artefact as a general solution concept.
If the constructed meta-artefacts are fairly light, construc-
tive research may look like a minor activity, especially
resource-wise. However, it is the core activity in the case
of Strategy 2. The innovativeness of the DSR in question
lies in this activity of identifying and constructing new,
innovative IT meta-artefacts, however simple and light
they may be.
As far as generalization is concerned, in the case of
Strategy 1 the IT meta-artefacts as general solution con-
cepts are generally targeted to address a class of problem
right from the beginning (see Dimension 2 in Table 1).
Strategy 2, on the other hand, is a more complicated
situation. Sein et al (2011) discuss the generalization in
European Journal of Information Systems
Juhani Iivari
terms of three processes: (1) generalization of the specific
problem instance into a class of problems, (2) gene-
ralization of the specific solution instance into a general
class of solutions and (3) derivation of design principles
from the DSR outcomes. This process seems to assume
that the authors have generalizations in mind regarding
the specific problem of the client and the solution deve-
loped for it. Table 3 broadens this view by pointing out
that a researcher may identify various problems and distil
various solution ideas when developing a specific solution
to the client’s problem. These need not have a direct
connection with the client’s problem and the specific
solution to it, but may be any problems and solution
ideas (e.g., design principles) inspired by the developed
system and its development process. Once generalized,
the general problems look for general solution concepts
and the generalized solution concepts look for problems
(cf. March & Olsen, 1976). They should be connected in
some way.
To illustrate the difference, Sein et al (2011) suggest three
design principles as the DSR contributions of their Volvo
case. These design principles clearly correspond to the
design principles of the specific Volvo Information Portal
(VIP) prototype they ended up creating in the process.
Therefore, VIP can be considered as an instance imple-
mentation of the proposed design principles. On the
other hand, Markus et al (2002) report a slightly different
story. Their work was based on experiences designing and
deploying a specific Technology, Organization, and People
(TOP) system in practice. These experiences led them to
formulate characteristics of EKP that can be considered a
‘theory for analysing’ (Gregor, 2006), meta-requirements
for IT support of EKPs, and meta-design for EKP support
systems and development principles. The development
principles clearly include aspects that are solutions to
problems concerning developing EKP support systems
and not generalizations of the features of the TOP system.
Actually, Markus et al (2002) illustrate that a DSR project
as an empirical phenomenon may inspire the develop-
ment of ‘theories for analysing’, ‘theories for predicting’
and ‘theories for explaining and predicting’. Yet, according
to the interpretation of DSR in the second section, these
theories are not constitutive in the sense that they alone,
without an innovative meta-artefact, would make a project
a DSR one.
Resource requirements
Finally, Table 4 contrasts the resource requirements of the
two strategies. There is a great deal of variety in the case of
Strategy 1. A critical question is if one considers it neces-
sary to implement (instantiate) a system (see Dimension 5
in Table 2), since it essentially affects the expertise needed
in the project, the size of the research team, and the time
needed for and cost of the research effort.
DSR following Strategy 2 means intensive collabora-
tion with the client. Therefore, its resource requirements
can be expected to be very similar to intensive research
 Distinguishing and contrasting two strategies for DSR Juhani Iivari 113

Table 4 Contrasting the two strategies of DSR – resource requirements

Dimension Strategy 1 Strategy 2

13. Access to a client Not necessary Necessary, but may be challenging

14. Expertise needed Often disciplinary. A possible system Often multidisciplinary or interdisciplinary
implementation (instantiation) may require a
number of sub-specialists

15. Research team
Size may vary from a single individual to fairly large
teams. A possible system implementation
(instantiation) usually requires a larger research
team, but all members do not necessarily have a
research interest in the project
The core research team is usually 3–10 members.
The real system implementation to address the
client’s specific problem usually requires additional
members, but all these members do not necessarily
have a research interest in the project

16. Time and cost
Varies greatly depending on the ambition and
complexity of the IT meta-artefact and more under a
researcher’s control. A possible system
implementation (instantiation) is often time
consuming and expensive
Usually requires intensive involvement in the project
over a longer period of time. Overall, time-
consuming and expensive

methods such as AR. First, access to a client interested
in a collaborative research effort and committed to it may
be challenging, even though the contribution to the client
may be expressed in terms of a fairly concrete system
implementation. An attempt to address the multi-faceted
complexity of the client’s total problem often justifies a
research team that is multidisciplinary or interdisciplinary.
On the basis of published examples (Majchrzak & Gasser,
2000; Markus et al, 2002; Lindgren et al, 2004; Sein et al,
2011), the core research team itself, when following Stra-
tegy 2, is not necessarily very large, maybe 3–10 members.
In addition, there may be more peripherally involved
members in the implementation of the real system to
address the client’s problem, but they do not necessarily
have a research interest in the project. As an intensive
research approach, DSR following Strategy 2 is fairly time
consuming, with a realistic project requiring an interven-
tion of at least a few months and possibly lasting 1–2 years.
As a consequence it is also fairly expensive.
Conclusions
The main contribution of this essay is the explication
of the two DSR strategies. To my knowledge nobody has
introduced this earlier, although the review team raised
the question if the two strategies are somehow related to
the forms of reasoning in DSR (see Fischer & Gregor, 2011).
It would take too much space to discuss this in detail. One
problem is the concept of inductive reasoning. According
to Vickers (2009), the traditional interpretation of induc-
tive reasoning as a ‘process of inferring a general law or
principle from the observation of particular instances’ is
outdated. It corresponds to a form of enumerative induc-
tion in the modern view. Fischer & Gregor (2011) seem to
have this enumerative form of induction in mind when
speaking about inductive reasoning. One question in the
case of enumerative induction is if it can reasonably be
based on one particular instance. One can expect that this
is a typical situation in the case of DSR Strategy 2.
Putting this conceptual problem aside, it is my con-
tention that one cannot conclude that Strategy 1 relies on
deductive reasoning only and Strategy 2 on inductive
reasoning only. It is obvious that sources of ideas –
practical problems and opportunities, existing meta-arte-
facts, analogies and metaphors, and existing theories
(Iivari, 2007) – essentially affect the forms of reasoning
in the DSR process. Both DSR strategies may be inspired
by all these sources. For example, when following DSR
Strategy 2, a researcher may find that an existing theory –
the ‘theory for explaining and predicting’ or the ‘theory
for design and action’ (Gregor, 2006) – informs about
a potential solution to the client’s problem. Therefore, the
reasoning in that case may be highly deductive from
theory to the particular solution. Yet, it may be an inter-
esting research project to investigate the forms of reason-
ing at a more detailed level in the case of the two
strategies.
The two DSR strategies were contrasted along 16 dimen-
sions that represent the context, process, outcomes and
resource requirements of DSR. It is not my claim that this
set of dimensions is comprehensive. For example, one
can question if following Strategy 2 is more conducive to
theory building than Strategy 1 – a theory in the sense of a
‘theory for predicting’ or a ‘theory for explaining and
predicting’ (Gregor, 2006) – since DSR adopting Strategy 2
comprises real systems development in practice. One
should note, however, that DSR following Strategy 1 often
includes real systems development, too, although usually
in a university or research laboratory context. It is not clear
that this context is less important, less informative and less
conducive to theory building than the client context in
the case of Strategy 2.

European Journal of Information Systems

114 Distinguishing and contrasting two strategies for DSR
Implications to researchers interested in DSR in IS
The distinction between the two DSR strategies has a
number of benefits to researchers interested in DSR and/
or DSR in IS. First of all, it provides a more balanced view of
DSR in IS. The seminal work of Hevner et al (2004) has
been criticized for adopting a biased and narrow view of IS
and IS design (e.g., McKay et al, 2008). Although this may
be an extreme interpretation, the present essay is ready
to accept that Hevner et al (2004) are biased towards
DSR Strategy 1. Therefore, it is significant to understand
that DSR in IS also covers Strategy 2, which may be less
susceptible to similar criticism.
Second, the distinction implies two widely different
research strategies, the relative pros and cons of which are
still unclear because we do not have much practical expe-
rience with DSR Strategy 2. Therefore, it is desirable to
build a cumulative research tradition of Strategy 2 research
so that its viability can be better evaluated. This requires
that researchers conducting DSR are aware of the research
strategies.
Third, the distinction also helps to better understand
some controversies around DSR in IS. For example, it
helps to make sense of the relationship between AR and
DSR (e.g., Figueiredo & Cunha, 2007; Järvinen, 2007; Iivari
& Venable, 2009; Sein et al, 2011). The above analysis
suggests that AR is indeed a significant research method in
DSR adopting Strategy 2. But the role of AR is much more
distant in the case of Strategy 1. Yet, in both cases AR is just
a research method, while DSR is more a research
orientation.
At a more general level, the two DSR strategies have
some affinity with Modes 1 and 2 research as introduced
by Gibbons et al (1994) and Nowotny et al (2001), and as
discussed by Figueiredo & Cunha (2007) in the IS context.
Mode 1 research is largely governed by academic interests;
it happens predominantly in university environments, it is
discipline-based and quality control is maintained mainly
through peer reviewing (Figueiredo & Cunha, 2007). In
Mode 2, knowledge production is solution-focused. Know-
ledge is generated within a context of application, which
refers to the total environment in which scientific pro-
blems arise, methodologies are developed, outcomes are
disseminated and uses are defined (Nowotny et al, 2003).
Although there is some similarity, one should note that
the distinction between Modes 1 and 2 is much broader
and ambitious. Mode 2 is suggested as an alternative
model of knowledge production that will supersede Mode
1 research, characterized by the hegemony of theoretical
science, by an internally driven taxonomy of disciplines
and by the autonomy of scientists and their host institu-
tions (Nowotny et al, 2003). The ambition of the present
essay is more modest – to clarify DSR in the IS context.
About the Author
Juhani Iivari is an AIS fellow and professor emeritus at the
Department of Information Processing Science, University
of Oulu, Finland. Before his retirement, he also served as a
European Journal of Information Systems
Juhani Iivari
It is not my intention with the distinction between
the two DSR strategies to suggest implications as deep as
Gibbons et al (1994). Assuming that Mode 2 research gets
more footing, it will likely increase the popularity of
DSR Strategy 2 in IS. Yet, practicing Strategy 2 does not
mean that one adopts all canons of Mode 2 research. For
example, DSR following Strategy 2 may be discipline-based
in the sense that one attempts to contribute to the body of
knowledge of IS.
Implications to researchers conducting DSR
The intent of this essay is to make design science research-
ers aware of the two widely different DSR strategies and
their differences, and consequently make them more
reflective of the DSR strategy of their work. More concre-
tely, the two strategies and their differences in Tables 1–4
might help design science researchers choose an appro-
priate DSR strategy. At the risk of dissuading researchers
from Strategy 2, Tables 1–4 suggest that there are consi-
derable risks involved in that choice. First, if a researcher
has access to a client that is interested in research colla-
boration in a problem area of interest to a researcher,
a researcher may jump into the dark to solve the client’s
problem, hoping that it leads to a DSR problem. As a
consequence, (s)he will face considerable uncertainty
about the possible DSR contribution. DSR Strategy 2 also
means intensive involvement in the collaborative pro-
ject over a longer period of time. A researcher should
consider if (s)he can commit to such an involvement.
Overall, Strategy 2 research is time-consuming and expen-
sive, implying that finding funding for the research effort
is a big concern.
On the other hand, Strategy 2 research may be really
rewarding. It implies access to the problems faced in
practice, and it possibly leads to a DSR contribution that
is ‘rooted’ in practice and likely is relevant for practice.
Working in a multidisciplinary or interdisciplinary project
may be interesting and stimulating, even though there is
always the risk that the project focuses too much on the
client’s immediate problems and safe, routine solutions.
It is naturally up to each researcher to make up his or her
mind based on considerations like these. Yet, since we do
not have much evidence about the relative pros and cons
of the two strategies, especially in the case of Strategy 2, it
would be beneficial to have more carefully conducted
Strategy 2 research projects in the future. This requires
that researchers pay attention to the research strategy and
methodology adopted, and carefully follow and report
their experiences of the project. That is the way to build
a cumulative tradition of DSR following Strategy 2.
scientific head of INFWEST/INFORTE programmes for
10 years. These programmes are joint efforts of a number
of Finnish universities to support doctoral studies and
 Distinguishing and contrasting two strategies for DSR
advanced professional education in IT. Iivari has served in
various editorial positions in leading IS journals such as
European Journal of Information Systems, Information Sys-
tems, Journal of the AIS, and MIS Quarterly. His research has
broadly focused on theoretical foundations of information
systems, information systems development methods and
approaches, organizational analysis, implementation and
References
BASKERVILLE R (2008) What design science is not. European Journal of
Information Systems 17(5), 441–443.
BAYAZIT N (2004) Investigating design: a review of forty years of design
research. Design Issues 20(1), 16–29.
BOYCHUK DUCHSCHER JE and MORGAN D (2004) Grounded theory: reflec-
tions on the emergence vs. forcing debate. Journal of Advanced Nursing
48(6), 605–612.
CODD EF (1970) Relational model of data for large shared data banks.
Communications of the ACM 13(6), 377–387.
CROSS N (1993) Science and design methodology. A review. Research in
Engineering Design 5(2), 63–69.
CROSS N (2001) Designerly ways of knowing: design discipline versus
design science. Design Issues 17(3), 49–55.
DAHL O-J, MYHRHAUG B and NYGAARD K (1968) Some features of the Simula
67 language, Proceedings of the Second Conference on Applications of
Simulations, pp 29-31.
DENISON DR, HART SL and KAHN JL (1996) From chimneys to cross-
functional teams: developing and validating a diagnostic model.
Academy of Management Journal 39(4), 1005–1023.
DEY I (1993) Qualitative Data Analysis: A User-friendly Guide. Routledge,
London.
DÍAZ ANDRADE A (2009) Interpretive research aiming at theory building:
adopting and adapting the case study design. The Qualitative Report
14(1), 42–60.
FIGUEIREDO AD and CUNHA PR (2007) Action research and design in
information systems: two faces of a single coin. In Information Systems
Action Research: An Applied View of Emerging Concepts and Methods
(KOCK N, Ed), pp 61–96, Springer, New York, NY.
FISCHER C and GREGOR S (2011) Forms of reasoning in the design science
research process. In Service-Oriented Perspectives in Design Science
Research: 6th international Conference, DESRIST 2011, LNCS 6629
( JAIN H, SINHA AP and VITHARANA P, Eds), pp 17–31, Springer, Heidelberg.
GIBBONS M, LIMOGES C, NOWOTNY H, SCHWARTZMAN S, SCOTT P and TROW M
(1994) The New Production of Knowledge: The Dynamics of Science and
Research in Contemporary Societies. Sage, London.
GLASER BG (1992) Emergence vs Forcing: Basics of Grounded Theory Analysis.
Sociology Press, Mill Valley, CA.
GREGOR S (2006) The nature of theory in information systems. MIS
Quarterly 30(3), 611–642.
HAGE J (1980) Theories of Organizations: Form, Process, and Transformation.
John Wiley & Sons, New York.
HEVNER A and CHARTTERJEE S (2010) Design Research in Information Systems.
Springer, New York.
HEVNER AR, MARCH ST, PARK J and RAM S Design science in information
systems research (2004) MIS Quarterly 28(1), 75–105.
IIVARI J (2003) The IS core – VII: towards information systems as a science of
meta-artifacts. Communications of the Association for Information Systems
12: 568–581.
IIVARI J (2007) Paradigmatic analysis of information systems as a design
science. Scandinavian Journal of Information Systems 19(2), 39–63.
IIVARI J (2012) Two strategies for design science research. Working Paper,
2012 (https://www.researchgate.net/profile/Juhani_Iivari/contributions/
?ev=prf_act) (accessed 14 October 2013).
IIVARI J and VENABLE J (2009) Action research and design science research –
Seemingly similar but decisively dissimilar. In Proceedings of 17th
European Conference on Information Systems (ECIS). Verona, Italy.
Juhani Iivari 115
acceptance of information systems, and design science
research in IS. He has published in journals such as
Communications of the ACM, Data Base, Information &
Management, Information & Software Technology, Information
Systems, Information Systems Journal, Information Systems
Research, Journal of Management Information Systems, Journal
of AIS, MIS Quarterly, and Omega.
JÄRVINEN P (2007) Action research is similar to design science. Quality &
Quantity 41(1), 37–54.
KUECHLER W and VAISHNAVI V (2008) The emergence of design research in
information systems in North America. Journal of Design Research 7(1),
1–16.
LINDGREN R, HENFRIDSSON O and SCHULTZE U (2004) Design principles for
competence management systems: a synthesis of an action research
study. MIS Quarterly 28(3), 435–472.
MAJCHRZAK A and GASSER L (2000) Top modeler: supporting complex
strategic and operational decision making, information, knowledge.
Systems Management 2(1), 95–110.
MARCH JG and OLSEN JP (1976) Ambiguity and Choice in Organizations.
Universitesforlaget, Bergen, Norway.
MARCH ST and SMITH GF (1995) Design and natural science research on
information technology. Decision Support Systems 15(4), 251–266.
MARKUS ML, MAJCHRZAK A and GASSER L (2002) A design theory for
systems that support emergent knowledge processes. MIS Quarterly
26(3), 179–212.
MCKAY J, MARSHALL P and HEATH G (2008) An exploration of the concept of
design in Information Systems. In Information Systems Foundations:
Answering the unanswered questions about design research, The 4th ANU
Workshop on Information Systems Foundations, Australian National
University, Canberra, Australia.
NOWOTNY H, SCOTT P and GIBBONS M (2001) Re-thinking Science: Know-
ledge and the Public in an Age of Uncertainty. Polity Press, Cambridge.
NOWOTNY H, SCOTT P and GIBBONS M (2003) Introduction: mode 2
revisited: the new production of knowledge. Minerva 41(3), 179–194.
NUNAMAKER JF, CHEN M and PURDIN TDM (1990-1991) System develop-
ment in information systems research. Journal of Management Informa-
tion Systems 7(3), 99–106.
ORLIKOWSKI WJ and IACONO CS (2001) Research commentary: desperately
seeking the IT in IT research – a call theorizing the IT artifact. Information
Systems Research 12(2), 121–134.
PEFFERS K, TUUNANEN T, ROTHENBERGER MA and CHATTERJEE S (2007-2008)
A design science research methodology for information systems
research. Journal of Management Information Systems 24(3), 45–77.
PETROSKI H (1982) To Engineer Is Human: The Role of Failure in Successful
Design. Vintage Books, New York.
SEIN M, HENFRIDSSON O, PURAO S, ROSSI M and LINDGREN R (2011) Action
design research. MIS Quarterly 35(1), 37–56.
VAISHNAVI VK and KUECHLER Jr. W (2008) Design Science Research Methods
and Patterns. Auerbach Publications, Boca Raton, FL.
VAN AKEN JE (2004) Management research based on the paradigm of
design sciences: the quest for field-tested and grounded technological
rules. Journal of Management Studies 41(2), 219–246.
VICKERS J (2009) The problem of induction, Stanford Encyclopedia of Philo-
sophy, Spring 2009 edn (Zalta N, Ed) (http://plato.stanford.edu/archives/
spr2009/entries/induction-problem/) (accessed 25 October 2012).
WALLS J, WIDMEYER GR and EL SAWY OA (1992) Building an information
system design theory for vigilant EIS. Information Systems Research 3(1),
36–59.
WEEDMAN J (1998) The structure of incentive: design and client roles
in application-oriented research. Science, Technology, & Human Values
23(3), 315–345.
WINTER R (2008) Design science research in Europe. European Journal of
Information Systems 17(5), 470–475.
European Journal of Information Systems