Peffers et al. Mastering the Design Science Research Methodology (DSRM)

Navigating Design Science Research: A Comprehensive Guide to Methodologies and Entry Points

Based on Peffers et al. (2007), “A Design Science Research Methodology for Information Systems Research”

Design Science Research (DSR) is a paradigm dedicated to the creation and evaluation of IT artifacts intended to solve identified organizational problems. Unlike natural or social sciences, which aim primarily to understand reality, design science aims to create things that serve human purposes. For years, Information Systems (IS) researchers lacked a commonly accepted framework for conducting this type of research, often relying on ad hoc arguments to justify their work

The Design Science Research Methodology (DSRM), introduced by Peffers et al. (2007), fills this gap. It provides a rigorous road map for creating valid constructs, models, methods, and instantiations. Crucially, the authors emphasize that this process is not a rigid, linear lockstep. Instead, it is a nominal process with multiple “entry points,” allowing researchers to adapt the methodology to their specific starting contexts.

This article details the various approaches, entry points, and validation methods available to researchers under the DSRM framework.

1. The Four Research “Entry Points”

Perhaps the most distinct feature of the DSRM is its flexibility regarding where a research project begins. While the methodology outlines a six-step process, researchers are not required to start at step one. The paper identifies four specific entry points based on the “trigger” of the research effort.

Problem-Centered Initiation (Starts at Activity 1)

This is the classic, nominal approach to research. It begins with the identification of a specific problem and the motivation for finding a solution.

• The Approach: The researcher observes a problem or identifies a gap in existing literature and proceeds sequentially through the process.
• When to Use It: This is ideal when the research is driven by a desire to solve a clear difficulty or inefficiency in the current environment, or when future research suggestions in prior papers highlight a specific unsolved issue.
• Case Example: The CATCH Data Warehouse project. Researchers identified that the manual data gathering required for community health assessments was labor-intensive and cost-prohibitive. This specific problem triggered the research, leading them to design an automated data warehouse solution.

Objective-Centered Initiation (Starts at Activity 2)

Sometimes, the trigger is not a specific “problem,” but a broader industry or research need that demands a new artifact.

• The Approach: Research begins by defining the objectives of a solution—what a new artifact would need to accomplish to be valuable—rather than dissecting a specific problem instance.
• When to Use It: Use this entry point when a general need is understood (e.g., “we need to measure X”) even if the specific problematic context hasn’t been fully articulated.
• Case Example: The Software Reuse Measure project. Researchers needed to conduct a case study on software reuse but realized existing metrics were insufficient for their specific enterprise environment. The project was initiated by the objective to develop a valid reuse metric, which was then used to facilitate the study.

Design & Development-Centered Initiation (Starts at Activity 3)

In this scenario, the artifact itself is the genesis of the research.

• The Approach: The researcher starts with an artifact that has already been created, or an idea borrowed from another domain, that has not yet been formally applied to the problem space.
• When to Use It: This approach is common when extending existing technology to new domains or testing “analogical ideas”. The research works outward from the design phase to define the problem it solves and evaluate its utility.
• Case Example: The SIP-Based Video-over-IP project. The Session Initiation Protocol (SIP) already existed as a standard for voice communication (the existing artifact). Researchers initiated the project to extend and design this standard to support video functionalities for the Internet environment.

Client/Context-Initiated (Starts at Activity 4)

This entry point often bridges the gap between consulting and academia.

• The Approach: The research starts with the observation of a solution that works in practice. The researcher effectively works backward to apply rigor to the process and frame the practical solution as a research contribution.
• When to Use It: This is useful for “retroactive” research, where a solution was developed for a specific client or organizational context, and the researcher realizes the solution has broader academic value.
• Case Example: The Digia Critical Success Chains project. A client (Digia) explicitly asked researchers to help generate a portfolio of mobile financial service ideas. The researchers used this client request to demonstrate and validate a new IS planning method.

2. The Nominal Process (The Standard Method)

Regardless of the entry point, the DSRM provides a structured mental model consisting of six activities. Researchers may iterate between these steps as needed.+1

1. Problem Identification and Motivation: Define the specific research problem and justify the value of a solution. This motivates the audience to accept the results.
2. Define Objectives for a Solution: Infer the objectives from the problem definition. These can be quantitative (e.g., “reduce time by 50%”) or qualitative (e.g., “support a new type of interaction”).
3. Design and Development: Create the artifact itself. This includes defining the artifact’s functionality and architecture and then building it. Artifacts can be constructs, models, methods, or instantiations.
4. Demonstration: Prove that the artifact works by using it to solve one or more instances of the problem.
5. Evaluation: Observe and measure how well the artifact supports a solution. This involves comparing the results from the demonstration to the objectives defined in step 2.
6. Communication: Communicate the problem, the artifact, its utility, and its rigor to relevant research and professional audiences.

3. Methods for Demonstration and Evaluation

A critical component of DSR is validating that the design actually works. The Peffers et al. paper specifies several methodologies researchers can employ during the Demonstration (Activity 4) and Evaluation (Activity 5) phases.

• Experimentation: Conducting controlled experiments to test the artifact’s efficacy.+1
• Simulation: Using computer models to simulate the artifact’s performance in various scenarios.
• Case Study: Applying the artifact in a real-world organizational setting and observing the results (as seen in the Digia and CATCH examples).
• Proof: Using logical or mathematical proof to demonstrate the validity of the design.+1
• Client Feedback / Satisfaction Surveys: Gathering subjective data from users or clients regarding the utility of the solution.
• Quantitative Performance Measures: Using objective metrics such as system response time, budget adherence, or availability to evaluate success.

4. Beyond the Standard: Alternative & Speculative Variations

While the DSRM is intended to be a consensus framework, the authors acknowledge it is not the only way to conduct Design Science. In their discussion, they speculate on at least five other potential methodological variations that researchers might develop:

1. Curiosity-Motivated DSR: Research driven purely by curiosity without explicit initial outcome objectives, similar to basic research in natural sciences.
2. Context-Specific DSR: Methodologies tailored to specific research streams, such as requirements analysis, which might require unique steps like organizational data gathering or specific modeling forms.
3. Action Research: Using Action Research as a paradigm to design artifacts. While DSR focuses on the artifact, Action Research focuses on the organizational context; however, they share significant overlaps and Action Research can be a valid vehicle for design.+1
4. Subsidiary Processes: Researchers may enhance the DSRM by developing detailed sub-processes for specific activities within the larger framework.
5. Ad Hoc Processes: In some cases, context-specific constraints may force researchers to develop ad hoc processes that do not fit the DSRM but are nonetheless rigorous and justified for that specific project.