Design Science Research

Design Science Research (DSR) is a methodology used in IS research that involves the design of innovative artefacts and the evaluation of the performance of the artefact towards solving intended problems (Kuechler & Vaishnavi, 2008). Design Science (DS) represents a design knowledge that is analytical, formalise-able, empirical, and a teachable doctrine (Gregor & Jones, 2007). In other words, DS is a body of knowledge that deals with the design of human- made objects and phenomenon designed to achieve some set goals (Vaishnavi & Kuechler, 2012).

DSR is aimed at understanding and improving human performance (Van Aken, 2005) by creating an innovative artefact that extends the boundaries of existing human knowledge and organisational capabilities to solve a known organisation problem. Making optimal and efficient IT decisions is a persistent organisational bottleneck in SEs. Hevner et al. (2004) described the characteristics of problems that warrant the use of DSR:

i. Problems that are unstable with ill-defined requirements and constraints due to environmental context. In this study, the criteria and constraints for making IT decisions in SEs vary by enterprise type, category, and location.

ii. Problems with complex interactions between the subcomponents of an organisational problem and known-solutions. For every IT choice, SE owner-managers are concerned by one or more consequence of action, making IT choice a complex process (especially in the context of this study where SEs do not have any internal IT skills).

iii. Organisational problems that depend on human cognitive abilities to make optimal choices. SE owner-managers are cognitive and autonomous thinkers that make all organisation decisions based on their intuition (Dimants, 2012; Gibcus & Van Hoesel, 2004).

It is important to clarify that design, design science, and design science research are three distinct but related concepts. In literal terms, design means to bring into existence a product. Vaishnavi & Kuechler (2012) distinguished between design science and DSR. The former is the knowledge of creating constructs, techniques, methods, and models that satisfy predefined functional requirements and the latter is a research process that creates the former through design, analysis, reflection, and abstraction. It is also worth noting the distinction between routine design and design science research. The routine design is the creation of an artefact

based on existing knowledge (Vaishnavi & Kuechler, 2012) through the application of pre- existing models to develop software for a firm. The major difference between routine design and DSR depends on the nature of the problems and solutions.

DSR innovatively addresses a unique and unsolved problem or applies effectiveness and efficiency in solving an existing problem (Hevner et al., 2004). However, the application of existing knowledge to figure out the knowledge gap in a new area of design can also be referred to as a DSR (Vaishnavi & Kuechler, 2012). Design science research process involves some level of intellectual risk and uncertainties at the proposed design stage. The aim of this study and the time horizon inform the choice of DSR as a research method (Hevner & Chatterjee, 2010). The DSR involves a rigorous research method in the creation of new knowledge. The knowledge produced must relate to the pre-existing knowledge for justification purposes, and the result must be communicated to the community (Johannesson & Perjons, 2014). However, a notable fundamental similarity between the design, DS, and DSR is the production of an artefact as an output.

4.3.1 Information Technology (IT) Artefacts

An artefact is a human creation (object) that emanates as a result of scientific investigation or experimentation to address a specific problem. People in practice react to practical problems by producing an artefact that will help them overcome their obstacle (Johannesson & Perjons, 2014). ? IT Decision Artefact IT investment Decision Person Practice

Figure 4-2: IT artefact in practice (adapted from Johannesson & Perjons, 20114)

Figure 4-2 illustrates the relationship between practice, people, problem, and artefact as illustrated in (Johannesson & Perjons, 2014). SE owner-managers in practice face business problems which they attempt to overcome with IT. The process of making IT tends to be

challenging to decision-makers because they lack sufficient IT skills to make the optimal choices to fulfil their aspirations. The nature of the artefact produced in this study intends to solve organisational problems to extend the intellectual and computational ability of decision- makers (Hevner et al., 2004).

IT artefacts can be categorised as material and abstract artefacts. The classification of an IT artefact depends on the type of knowledge contribution and the functional impact of the artefact (Johannesson & Perjons, 2014). IT artefacts are broadly classified as constructs, models, methods, and instantiation (Hevner et al., 2004; Johannesson & Perjons, 2014; Peffers, Tuunanen, Rothenberger, & Chatterjee, 2007).

General Classification

- output Description Contribution Knowledge

Model This study presented a conceptual IT decision-making framework to guide IT investments in SEs. The framework is namely: Enterprise Architecture-driven Framework (EADF). The EADF is an innovative framework that is abstracted from existing frameworks of business – IT alignment.

Prescriptive

Methods The application of the EADF in three (3) iterations and the presentation of algorithms to design a decision assisted tool for IT decision-making using the EADF as illustrated in Chapter Seven (7) offered a methodological contribution.

Descriptive

Instantiation Instantiation is a working system. This study produced an online decision-assistive tool for SEs’ owner-managers. The online assistive decision tool helped in solving practical problems. The documentation and evaluation of the artefact has been detailed in Chapter Seven (7) and Eight (8)

Prescriptive

Table 4-2: IT Artefact Output

Vaishnavi & Kuechler (2012) presented a broader classification of IT artefacts to include constructs, models, methods, instantiation, frameworks, architectures, design principles, and design theories. However, they presented a very abstract description of the additional classification (Vaishnavi & Kuechler, 2004). Table 4-2 highlights the IT artefacts output in this study.

4.3.2 Design Science Research Methodologies

Design science research has become a widely accepted methodology in Information Systems disciplines (Peffers, Tuunanen, Rothenberger, & Chatterjee, 2007; Vaishnavi & Kuechler, 2012) with a recent increase in DS research in IS publications (McKay & Marshall, 2005). However, there is still lack of consensus on the methodology, epistemology, and ontology of DSR (Fischer

a comprehensive and detailed clarity (Alturki, Gable, & Bandara, 2011; McKay & Marshall, 2005). The publication of (Baskerville, 2008) dismisses different assumptions about design science. However, there is unanimity on the demonstration of design innovativeness, rigour, and problem centric-ness of DSR practice. Table 4-3 summarises some DSR methodologies as presented in (Alturki et al., 2011). This study adopted the Vaishnavi & Kuechler (2012) Design Science Research Process Model.

Author/Year # Design Science Methodologies (Steps/Activities/Tasks) (Nunamaker, Chen,

& Purdin, 1990) 5 Construct framework a conceptual Develop a system architecture Analyse and design the system Build the (prototype) system Observe and evaluate the system (Walls, Widmeyer,

& El Sawy, 1992)

Design Product Design Science

7 Meta- requirements

Meta- design

Kernel theories Testable design product hypotheses Design method Kernel theories

Testable design process hypotheses

(S. T. March & Smith, 1995)

2 Build Evaluate

(Rossi & Sein, 2003) 5 Identify a need Build Evaluate Learn Theorise

(Hevner et al., 2004)

7 Design as an Artefact

Problem Relevance Design Evaluation

Research Contributions Research Rigour Design as a Search Process Communication of Research

(Vaishnavi &

Kuechler, 2012) 5 Awareness of a problem Suggestion Development Evaluation Conclusion

(Van Aken, 2004) 4 Choosing a case Planning and implementing interventions Reflecting on the results Developing design knowledge to be tested and refined in subsequent cases (Cole, Purao, Rossi,

& Sein, 2005)

4 Problem Definition Intervention Evaluation Reflection and Learning

(Venable, 2006) 4 Solution technology invention Theory building Artificial evaluation Naturalistic evaluation

(Peffers et al., 2007) 6 Problem identification and motivation Define the objectives for a solution Design and development

Demonstration Evaluation Communication

(Gregor & Jones, 2007)

Compulsory Optional

8 The purpose and scope

Constructs Principles of form and function Artefact mutability Testable propositions Justificatory knowledge Principles of implementation Expository instantiation (S. March & Storey,

2008)

6 Identification and clear description of a relevant organisational IT problem

Demonstration that no adequate solutions exist in the extant knowledge-base

Development and presentation of a novel IT an artefact that addresses the problem

Rigorous evaluation of the IT artefact enabling the assessment of its utility

Articulation of the value added to the knowledge-base and to practice Explanation of the implications for IT management and practice (Pries-Heje, Baskerville, & Venable, 2008a)

4 Risk identification Risk analysing Risk treatment Risk monitoring

(Pries-Heje, Baskerville, & Venable, 2008b)

Ex Ante Evaluation Activity Ex Post Evaluation Activity

8 Naturalistic Design process Naturalistic Design product Artificial Design process Artificial Design product Naturalistic Design process Naturalistic Design product Artificial Design process Artificial Design product (R. Baskerville, Pries-Heje, & Venable, 2009) 7 A specific problem is identified and delineated Problem must then be expressed as a a specific set of requirements

The specific problems are systemically abstracted and translated into a general problem General solution design (a class of solutions) for the general problem General design requirements are compared with the specific problem

A declarative search is made for the specific components that will provide a workable instance of a solution to the general requirements.

An instance of the specific solution is constructed and deployed into the social

system