Echeloned DSR according to Tuuanen et al
Introduction
Given the complexity of DSR projects, Tuunanen et. al. (2024) [1] propose a rethinking of DSR based on the theory of hierarchical, multi-level systems. This involves decomposing a complex DSR project into specifically defined, self-contained intermediate units - which we refer to as "echelons", following the theory of hierarchical systems (Mesarovic et al., 1970). In an echelon-oriented approach, we decompose a (larger) problem into a hierarchy of logical sub-problems. We create solutions to such subproblems, which serve as intermediate results that can be developed, validated and communicated independently. In combination, such intermediate results contribute to the overall solution.
Echelons are essentially organizational units that the DSR researcher is free to choose according to his or her understanding and choice of how to decompose a problem. To further conceptualize the echeloned DSR (eDSR) methodology, we distinguish five types of design echelons. One form of type formation is to differentiate design echelons as they combine specific analysis/design and validation activities related to a specific intermediate state of the artifact:
- Problem analysis—contributing the problem statement
- Objectives and requirements definition—contributing design requirements
- Design and development—contributing a projectable solution design
- Demonstration—contributing an illustrative instance of the artifact (in an artificial or natural context)
- Evaluation—contributing the contextualized artifact in use.
Problem analysis
Description
The overarching problem addressed by the research is the limited ability of large, decentralised organizations to achieve enterprise-wide, long-term 'global' benefits (e.g., leveraging synergies through shared software solutions, limiting the complexity of the IT application landscape) because local decision-makers instead focus on project-, unit- or function-specific, short-term 'local' benefits. One symptom of this overarching problem is that enterprise-wide coordination approaches, such as enterprise architecture management, appear to have reached impact limits due to a lack of institutionalisation by most local decision-makers. The limited impact of coordination interventions can be explained by local decision-makers perceived social legitimacy, efficiency, organizational grounding, and trust in the interventions. Thus, an effective design solution would include design principles for coordination interventions that effectively improve local decision-makers perceptions of the legitimacy, efficiency, organizational grounding, and/or perceived trustworthiness of the interventions.
Examples
Research objective: Identify effective guidance for enterprise-wide IS coordination in settings with high complexity and high local autonomy Common methods:
- Literature review
- Review practitioner initiatives
- Expert interview
- Focus group
- Surveys
Further Readings
Tuuanen T., Winter. R., vom Brocke J. (2023), Dealing with Complexity in Design Science Research: Using Design Echelons to Support Planning, Conducting, and Communicating Design Knowledge Contributions, in: Management Information Systems Quarterly (MISQ), 47
Objectives and requirements definition
Description
As the empirically based design goals are quite different, in the research we use as an example, it was found that solution design should first focus on a specific goal, such as better demonstrating the effectiveness of the intervention or improving the social legitimacy of enterprise-wide coordination. By testing the effectiveness of different novel interventions, it should be possible to generalize effective intervention design to design principles (linking generalized design requirements to generalized design features).
Examples
Increase effectivity of coordination interventions
Generalize artifacts to generic coordination guidance.
Common methods:
- Logical reasoning
- Benchmarking
- Expert interview
- Focus group
Further Readings
Tuuanen T., Winter. R., vom Brocke J. (2023), Dealing with Complexity in Design Science Research: Using Design Echelons to Support Planning, Conducting, and Communicating Design Knowledge Contributions, in: Management Information Systems Quarterly (MISQ), 47
Design and development
Description
For each proposed set of design requirements, the analysis of existing research and the state of practice would lead to different sets of solution components, which would then be integrated and tailored to the problem at hand. For example, to demonstrate the efficiency of coordination ("what's in it for me?"), either the costing and charging of technical debt to non-compliant change projects or the provision of cost-reducing project support (e.g. by supporting architects or reducing the cost of shared software solutions) could be used as foundations. A possible basis for improving the social legitimacy of enterprise-wide coordination ("Why should I comply?") could be communication measures (e.g., showcasing successful solution sharing) or engineered social pressure (e.g., by making non-compliant projects transparent across the organization). At a later stage, the generalization of effective design features and design requirements allows the formulation of design principles.
Examples
Intervention type 1: Charge projects for technical debt (internalization of effects)
Intervention type 2: Use a label to create transparency about incompliant decision-making
Intervention type 3: Use other social clues to create transparency
Consolidate design requirements and design features to design principles
Further Readings
Tuuanen T., Winter. R., vom Brocke J. (2023), Dealing with Complexity in Design Science Research: Using Design Echelons to Support Planning, Conducting, and Communicating Design Knowledge Contributions, in: Management Information Systems Quarterly (MISQ), 47
Demonstration
Description
All of the above solution strategies need to be contextualized to demonstrate their potential to solve the design problem. For example, to demonstrate the ability of social interventions to effectively increase the compliance of decentralized decisions in change projects, labels must be developed together with the case organization to ensure understanding and acceptance. Such labels make transparent which projects (or business units) are more or less compliant and thus create or reduce technical debt for the entire organization (Schilling et al., 2019). An alternative PoC for this projectable design is to create "relationship manager guilds" where know-your-customer data quality issues can be discussed and a common sense of compliance can be institutionalized.
Examples
Re-calculate historical projects Compliance label prototype
Show that successful coordination artifacts instantiate design principles
Further Readings
Tuuanen T., Winter. R., vom Brocke J. (2023), Dealing with Complexity in Design Science Research: Using Design Echelons to Support Planning, Conducting, and Communicating Design Knowledge Contributions, in: Management Information Systems Quarterly (MISQ), 47
Evaluation
Description
Promising concepts need to be applied with real people who have a real stake in the outcome. In the project used as an example, two companies were involved in field tests (indifferent business units) and a pilot study, respectively.
Examples
Case study: Resistance and escalation prevents sustained effectiveness of intervention
Field test: Compliance label rollout in Business Unit
A Pilot study in company: Digital KYC data quality nudges
Focus group: Design principles development
Further Readings
Tuuanen T., Winter. R., vom Brocke J. (2023), Dealing with Complexity in Design Science Research: Using Design Echelons to Support Planning, Conducting, and Communicating Design Knowledge Contributions, in: Management Information Systems Quarterly (MISQ), 47
References
- ↑ Tuuanen T., Winter. R., vom Brocke J. (2023), Dealing with Complexity in Design Science Research: Using Design Echelons to Support Planning, Conducting, and Communicating Design Knowledge Contributions, in: Management Information Systems Quarterly (MISQ), 47