Keywords

1 Introduction

Organizational Design and Engineering (ODE) (sometimes also addressed as Enterprise Engineering) is a discipline that studies organizations from an engineering perspective [1]. This means that organizations are considered to be purposefully designed and implemented systems. Such systems can be re-designed and re-implemented if there is a need for change. The problems that need to be solved in such a context while addressing the organization in a holistic way are of complex nature and multifaceted. Since most organizational solutions will include not only task and people components, but also information technology (IT) components like software systems and IT infrastructure components, ODE and information systems (IS) design and engineering have a different focus, but many commonalities. IS solutions, i.e., IT solutions embedded in a task and people context, need to be adaptable to changing conditions and goals, so that IS design and engineering needs to put special emphasis not only on ensuring the alignment of business structures and supporting software systems, but also on supporting the adaptability of IS. The solutions of such complex organizational problems need to be constructed in a systematic way.

Since ODE considers organizations as designed and engineered complex systems, and because there are many similarities with IS design and engineering, the Design Science Research (DSR) approach for IS can also provide a basis to solve organizational design problems. Several DSR approaches are available and have been applied in practice to aid ODE. Examples of such approaches, among many others, are the Business Engineering Approach [2], Design and Engineering Methodology for Organizations (DEMO) [3], Zachman framework [4], ArchiMate method [The Open 5], Business Process (Re)Engineering Approach [6, 7], or ARIS framework [8]. Such approaches successfully address certain aspects of organizational problems, e.g., identifying essential business transactions in order to decide about splitting or allying of organizations (by applying the DEMO method), identifying business processes (by applying the Business Process (Re)Engineering Approach), or integrating business aspects as well as IT aspects (by applying the Business Engineering Approach). They aim at building and testing various kinds of designed artifacts (e.g., software systems, procedures/project plans, but also reference models or reusable methods) as solutions to certain ODE design problems or even better to classes of similar ODE design problems. Due to the complex and holistic nature of organizational design and engineering problems often one approach alone does not give full support to reach a desired end. Real-world ODE often requires several approaches to be combined because multiple aspects have to be covered and/or the problem combines characteristics of several domains; E.g., applying both the DEMO and Business Engineering approaches in order to provide an inter-organizational business-to-IT solution for the essential transactions that are outsourced by an organization. In order to be able to select and combine these approaches, (1) the existing and successful applied DSR approaches need to be recognized regarding their core contribution to the field, and (2) the problem with its goals and contexts need to be under-stood in order to be able to define possible solutions to the given problem. A DSR framework would provide guidance in solving such complex ODE problems in a systematic way. However, to our knowledge no such framework exists so far. We therefore aim at the development of a DSR framework that

  1. 1.

    allows for a systematic classification and retrieval of DSR artifacts and

  2. 2.

    relates solution artifacts to problem characteristics.

The Knowledge Base (KB) in DSR as introduced by Hevner [9] provides a simple structure of applicable DSR approaches. Hevner differentiates practical knowledge and research knowledge. He explains that DSR problem solving processes follow three cycles in order to derive at rigorous solutions to relevant, important design problems. First we find a differentiation of the KB into problem knowledge and solution knowledge more adequate in order to better understand the relationship between the right means to achieve the desired end. Second, in the process of deriving at the desired ends, we do not see DSR as a three-cycle approach, but rather as a one-cycle approach. In Sect. 2 we therefore propose to restructure the DSR KB and to redefine the DSR process. In Sects. 3 and 4 we then detail the new structure of the DSR KB regarding solution components and solution requirements, respectively. In Sect. 5 we illustrate the applicability of our proposal by using the ODE domain “organizational change” as an exemplar. Section 6 concludes the chapter and outlines future work.

2 Challenges of the One-Cycle View of Design Science Research

Since different DSR proposals often widely vary with regard to foundations, goals, and processes, Hevner [9] has introduced a generic DSR framework comprising three cycles—relevance, design and rigor cycles—, which should be present and clearly identifiable in every piece of DSR. This ‘three-cycle view of DSR’ is illustrated in Fig. 1.

Fig. 1
figure 1

Three-cycle view of DSR [9]

Full size image

In the relevance cycle the requirements of the application domain are defined and introduced into the design process. Additionally, the resulting research artifacts are established in the environment (e.g. by field-testing) in order to demonstrate their problem solving utility. In the rigor cycle domain experience and expertise as well as existing generic design products and processes are introduced into the design process in addition to scientific theories and methods. Additionally, new generalizable knowledge derived from the design process is added to the knowledge base (KB) for reuse. The design cycle, which is essentially a solution search procedure, iterates between the core activities of building and evaluating design artifacts. “[…] multiple iterations of the design cycle […] [are necessary] before contributions are output into the relevance cycle and the rigor cycle.” [9].

Since Hevner’s framework is generally applicable for any constructional problem and result type in DSR, it might be a starting point to frame specific DSR proposals. However, it has some drawbacks. First, it does not fully support the recognition that “[…] artifacts emerge in interaction with the organizational elements.” [10]. This conclusion results from Hevner’s proposal of having three cycles in DSR, where the design cycle has dependencies on the relevance and the rigor cycles but at the same time is independent during the actual execution of the research [9]. Second, it does not give guidance neither for organizing the knowledge base in order to be able to find the right means (e.g., existing solution components or methods) to reach the desired ends, nor for organizing the understanding of the design problem in order to define the desired ends.

Regarding the first drawback a DSR method has been proposed recently, called Action Design Research (ADR) that “[…] conceptualizes the research process as containing the inseparable and interwoven activities of building the IT artifact, intervening in the organization, and evaluating it concurrently” [10]. The aim of ADR is to provide a method that has build-in relevance and rigor cycles providing explicit guidance for designing innovative IT artifacts in combining building, intervention and evaluation activities. It combines Action Research (AR) (see e.g., [11]) with DSR where AR has organizational intervention at its very heart.

In line with the guiding ideas of ADR and inspired by the Spiral Model in software development [12] we revisit Hevner’s three cycle view and argue that the design cycle of Hevner has rigor related and/or relevance related characteristics within each single iteration. We therefore propose a one-cycle view of DSR, which is comprised of alternating core activities design and evaluation within one and the same cycle. Every iteration of the cycle allows revisiting the DSR KB (shown in the right cylinder of Fig. 2) in order to improve the problem solution, and developing a better understanding of the environment and the problem to be solved (shown in the left cylinder of Fig. 2). The cycle iterates until a sufficiently useful solution has been developed. When the iteration exits, a problem solving means has been developed and novel artifact components together with their related problem characteristics are added to the DSR KB. Our one-cycle view of DSR is illustrated in Fig. 2.

Fig. 2
figure 2

One-cycle view of DSR (adapted from [13])

Full size image

Regarding the second drawback mentioned above, we go even further and propose to restructure the DSR KB in order to better support design artifact reuse. As introduced by Hevner [9], the DSR KB differentiates practical knowledge and research knowledge and explains that this knowledge is applied in the rigor cycle in order to derive at the desired solution. We find a structure of the DSR KB in problem knowledge (Problem cylinder left in Fig. 2) and solution knowledge (Knowledge base cylinder right in Fig. 2) more adequate in order to better understand the relationship between the right means to achieve the desired ends.

The idea of a one cycle view on a problem solving process is not new and has been successfully applied e.g., in the Spiral Model of software development and enhancement [12]. We have been inspired by this model in several aspects; First, the determination of objectives, alternatives and constraints have had an impact on the structuring of the problem knowledge by means of understanding the different solution alternatives based on different design goals and contexts (explained later in this section). Second, having the development and verification of the artifact not as a separate cycle in the Spiral Model underlined our conviction that the design, relevance and rigor cycles belong together and should not be separated. Further, having different types of artifacts that may be designed and evaluated in different cycles (in the spiral model these are the different portions of the product and the different levels of abstraction) satisfied our need to restructure the DSR KB in order to better find the right means for each artifact type to derive at the desired ends.

The main research questions however, which need to be answered in order to support the application of the proposed one-cycle problem solving process to reach organizational improvements concern are:

  1. 1.

    How to structure the DSR KB, in order to better understand which solution components and foundational guidelines have been successfully applied for which kinds of organizational problems

  2. 2.

    How to structure the problem base in order to systematically manage solution requirements, design goals, and the organizational context.

An overview of the proposed approach on how to structure the problem base as well as the DSR KB and how the two bases are related one to another is shown in Fig. 3.

Fig. 3
figure 3

Overview of the problem and KB structure

Full size image

Based on specified solution requirements the corresponding solution components need to be found by means of an adequate search strategy. The solution requirements result from comparing the as-is situation to the to-be situation, which implies a transition path. Each to-be situation however is related to defined design goals, and both the to-be situation and the as-is situation are related to a design problem context [14]. Once the solution requirements have been specified, an adequate search strategy is required to identify artifacts that contribute to the problem solution, i.e. that constitute components of the to-be solution and/or that support the transformation. This search strategy is strongly dependent on the organization and the structure of the DSR KB. For the structuring of the DSR KB we propose two two-dimensional maps. One map concerns the application scope; the other one concerns the artifact character. The search for applicable existing design artifacts can be organized efficiently if these artifacts are organized with regard to their type, their generality, their application domain and their coverage.

In the following sections we will propose a structuring approach for both the DSR KB and the problem specification. We will then show how the proposed structure enables an effective search for solution components based on specified solution requirements.

3 Structuring the DSR Knowledge Base for Reuse

We propose to differentiate application scope and artifact character. Both can be specified using two-dimensional maps.

The application scope map is based on Winter’s [15, 16] approach to identify design factors and represent as-is design solutions in DSR. The approach starts with an as-is analysis step in order to explore domain specific contingencies. For that purpose, it needs to be tested, (a) which potential contingencies (that have been identified by literature analysis) in fact have influence on the observed design solutions and (b) which relevant contingencies load on the same design factor, i.e. which influences are closely related. For that purpose, a large number of observed practices in the regarded domain need to be specified by as many as potential (dependent) items, and the status of every potential contingency for every case needs to be specified as potential (independent) item. Then a principal component analysis is carried out to explore which independent items load how much on which component that explains the variance of the dependent items. The components can be understood as design factors, i.e. as aggregate levers that explain a large portion of the variance of the observed design solutions. The design dimensions define a multi-dimensional space in which every observed solution can be interpreted as a point. In order to reduce the variety of the observed design solutions, an agglomerative cluster analysis is carried out. This second as-is analysis step yields a manageable number of clusters whose cluster centers can be interpreted as ‘representative’ as-is solutions. The observed cases and their ultrametric distances can be visualized using a dendrogram-like tree diagram (see Fig. 4).

Fig. 4
figure 4

Visualization of ultrametric distances between design solutions within a design problem class [15]

Full size image

The (dis)similarity of two observed design solutions corresponds to the generality level of their link. If two solutions are very similar, their link is represented on a low level of generality—and vice versa. Based on the solution (dis)similarities visualized by the tree diagram, a reasonable clustering level needs to be determined. The broader the design problem class C is defined, the more design solutions can be covered in the tree diagram.

We base one component of our design artifact ‘mapping’ approach on such tree diagrams. In the application scope map, one dimension represents the level of generality of the design artifact, while the other is used to differentiate application domains and sub-domains. Design artifacts on higher levels of generality are applicable to a broader scope of design problems, while artifacts with lower generality are better suited to be useful for more specific design problems.

The search strategy in order to find the right level of design artifact abstraction is as follows: The search starts on the highest level of generality by identifying the most generic artifacts. By moving down the tree following the path to the final node where the domain of the problem to be solved is defined (see Fig. 4), more specific design artifacts are added to the existing set of generic design artifacts. This continues until the final node in the tree has been reached. If the found design artifacts along the path do not sufficiently cover the requirements, they need further to be developed.

The artifact character map is based on Albani and Winter’s conceptual framework for design and engineering in information systems [17] as shown in Fig. 5.

Fig. 5
figure 5

Conceptual framework for design and engineering in information systems [17]

Full size image

The necessity for the conceptual framework arose from the fact that several classifications of DSR artifacts exist, but the relationship between the existing artifacts is missing. Each artifact type contributes to understand specific aspects of the approaches, but without the defined relationships a complete understanding of the means-end relationships is not possible. The contribution of the work of Albani and Winter [17] is that they put the existing artifacts in relationship. The result of their work is the conceptual framework as introduced in Fig. 5, which allows for a systematic analysis and comparison and eased combination of approaches. Since existing approaches need not only to be of practical relevance, but also theoretically sound, the framework provides the necessary artifacts to examine also the theoretical grounding of the approaches.

We base the second component of our KB structuring proposal, the artifact character map, on the constructional framework of Albani and Winter [17] and define the following two dimensions: One dimension results from the constructional framework introduced in Fig. 5 and differentiates the following artifact types: (a) underlying concepts and constructs, (b) foundational explanatory and/or predictive theories, (c) general components provided, (d) conditions or capabilities needed or possessed, (e) applied methods and resulting models, and (f) concrete design solutions. The other dimension denotes the problem coverage of the artifact, i.e. it specifies to what extent a design problem is addressed through artifacts of the respective type.

For a DSR approach, the artifact character map then represents which proposed artifact types address a design problem to what extent. E.g., does the approach provide clearly defined methods, constructs and concepts, which need to be used to design the solution, or does an existing approach already provide some concrete design solutions, which may be used directly as solutions to the identified problem. In Fig. 6 two exemplary artifact character maps are illustrated:

Fig. 6
figure 6

Exemplary artifact character maps (adapted from [17])

Full size image

  • The upper artifact character map represents an approach, which is strongly based on theory and clearly defines concepts/constructs to be used in order to derive at the required solution for a given problem. However, the map also indicates that this approach does not provide a large array of concrete design solutions, which could be used directly as a result for certain design problems. An example for this type of DSR approach is the Design and Engineering Methodology for Organizations (DEMO) [3].

  • The lower artifact character map differs clearly from the upper in the sense that concepts and constructs are provided and have been used to design already a wide range of concrete solutions. However, the represented DSR approach has no clearly defined theoretical base. Nevertheless the approach provides a collection of concrete design solutions, which can be used directly to meet a particular need. An example for this type of DSR approach is ARIS [8].

In [17] the usefulness of the artifact character map is demonstrated by characterizing two very different ODE approaches: enterprise engineering and situational process-oriented information logistics. While both approaches aim at contributing to the same problem class, namely supporting the management of organizational change by means of generic artifacts, they are quite different regarding artifact types and design problem coverage.

The artifact character map helps to understand how approaches differ, and to identify an appropriate approach for certain artifact type and problem coverage. The search strategy for identifying the suitable solution for a design problem is implied by the structure of the artifact character map. By knowing in which application domain the problem is situated and therefore having identified the possible artifact types through searching the application scope map, the artifact character map further helps to identify the approach, or a combination of different approaches, to solve the given problem. The search in the artifact character map starts from the very specific solutions, namely the fit of a concrete design solution to the defined problem (see Fig. 5). If no concrete design solution is found one dives deeper in the artifact character map trying to instantiate reference models or methods in order to be able to adapt them for solving the given design problem. If this is not applicable the need for using design theories or finding explanations for relevant aspects in the identified problem domain is given. If none of those steps supports the problem solving there is a need to look for, or to define appropriate concepts and constructs. These concepts and constructs then build the basis to define the other artifact types in the artifact character map in order to develop the appropriate approach for solving the very specific design problem.

While the application scope maps allows to understand re-use potentials of existing design solutions with regard to their generality and domain, the artifact character map allows to understand which type of contribution an existing design approach can make. If existing DSR solutions are represented in both maps, a wide array of their relevant properties is made available for search so that the DSR process can locate potentially applicable solution artifacts for a given design problem efficiently.

4 Solution Requirements, Goals, and Context

The left part of Fig. 3 illustrates the main components of the problem specification: The as-is situation, to-be situation, as well as the design goals and the design problem context need to be understood in order to define the solution requirements. The solution requirements result from comparing the as-is situation to possible to-be situations. Such a comparison implies the definition of a path that transforms the as-is situation into the desired to-be situation.

While the as-is analysis aims at understanding the existing solution and therefore is based on observed data, to-be design might be more innovative and creative [16]. Depending on how much certainty exists about the ‘right’ solution approach, there are different ways to specify the to-be situation. If e.g., success factors for the respective domain have been researched that explain solution performance in sufficient detail and generality, to-be solutions might be derived in a very straightforward way. If ‘best’ (or at least successful) practices and their relation to relevant contingencies are commonly accepted in the respective domain, to-be solutions might also be specified directly. The more immature a domain is, however, the less well defined is the step of designing to-be solutions. Winter [16] presents three alternatives that use different performance valuations and are applicable in different stages of maturity:

  • Goal-oriented transition assumes that as-is solution clusters (as shown in Fig. 4) can be generally valuated with regard to a certain goal vector. Using its individual goal vector, a company can evaluate whether the as-is solution is good enough or which other solution cluster (that has been realized by other companies) it wants to realize. Since all solution clusters are defined with regard to the same set of design factors, all possible transitions can be completely specified.

  • To-be solution survey assumes that there is sufficient empirical knowledge available on to-be solutions in the respective domain. To-be solution clusters then can be specified in exactly the same way as as-is solution clusters have been discovered, i.e., by researching potential contingencies, collecting field study data and applying principal component analysis and agglomerative cluster analysis. If as-is and to-be data are collected within the same survey, transitions within the respective domain can be directly observed for every case. Neither a goal vector needs then to be defined, nor have situations to be evaluated using that goal vector. As-is and to be solution clusters might however reference different design factors so that the specifications of observed transitions is not as straightforward as for goal-oriented transition.

  • If available for the respective domain, other applicable techniques for to-be solution design include maturity models or application of design theories. Basically every design/creativity technique is applicable. The more the applied technique deviates from the design factors and as-is solution specifications, however, the more difficult it gets to systematically specify transitions.

Transitions to to-be solutions define solution requirements which constitute the main input source for the searching of the appropriate solution components as introduced in Sect. 3.

5 Demonstration

We illustrate the applicability of the suggested approach by using the domain of “organizational change” as an exemplar. Even if there are many approaches around for organizational change, it still remains a major challenge for companies. Baumöl [18, 19] elaborated on this topic and tried to answer one major question, namely: “[…] how can the uniqueness of each change project be taken into consideration and yet a procedure of method construction be used which allows for making use of best practices, experiences and existing methods or, at least, parts of methods” [19]. While Baumöl’s focus was on the creation of situational methods to support the change processes in organizations, we use some of her outputs to show how to search for adequate solution artifacts, which support organizational change, having the DSR KB structured as proposed in our approach. Baumöl conducted an analysis on 89 cases consisting of interviews, published cases studies and methodologies, covering the major topics to be addressed in the change process, namely strategy, leadership, sustainability, performance measurement and IT. In addition she applied cluster analysis to gain knowledge about reference contexts of change, which resulted in the following five clearly distinguishable clusters [19]:

  1. 1.

    Change projects having a focus on comprehensive strategy adaptation.

  2. 2.

    Change projects having a focus on redesigning the communication and interaction with customers and the business network.

  3. 3.

    Change projects dealing with growth strategies and cultural aspects placed in a technological context.

  4. 4.

    Change projects having a focus on process engineering or process redesign.

  5. 5.

    Change projects dealing with the improvement of agility of the organization.

A subset of these clusters is shown in Fig. 7. The observed and analyzed actual company solutions are represented as numbers (1-52). We adapted these results by adding a selection of exemplary design artifacts on different levels of generality.

Fig. 7
figure 7

Application scope map for organizational change (adapted from [19])

Full size image

While the reusable design artifacts on higher level of generality (e.g., the DEMO method [3], the Zachman framework [4] or the ArchiMate method [5]) are applicable to a wide range of organizational change projects, those on lower levels (e.g., Situational Management Method for Process Oriented Information Logistics (SMM for POIL) [20, 21]) deal with a concrete type of organizational change in a more specific way.

As explained in Sect. 3, the search strategy for identifying artifacts that can help to solve the required organizational problem, starts on the highest level of abstraction. While diving deeper in the tree, additional design artifacts are added as possible means to contribute to the desired ends.

As an example, we look at the case of redesigning the information logistics processes. In traversing the tree from the top to the bottom (to a specific solution, which is the closest solution to the problem that needs to be solved) the following design artifacts are added to the set of possible means: DEMO method [3], Zachman framework [4], ArchiMate method [5], Unified Modelling Language (UML) [22], ARIS framework [8], Business Process Modeling Notation (BPMN) [23], Reference Modeling [24], and SMM for POIL method [20, 21]). After quite a diverse set of potentially useful design artifacts has been identified by the search procedure, the next step is to better understand the specifics of the approaches in order to select the most relevant ones. Building on related DSR work, Albani and Winter [17] suggest an IS design and engineering approach for that purpose. The application of the conceptual framework to the different approaches allows for a better classification of approaches contributing to a better selection of an appropriate approach and, if necessary, a suitable and feasible composition of different approaches in order to reach the desired end. For the DEMO and the SMM for POIL approaches, Albani and Winter [17] demonstrate a concrete amalgamation whose results are shown in Figs. 8, 9.

Fig. 8
figure 8

Application of the conceptual framework to DEMO [17]

Full size image
Fig. 9
figure 9

Application of the conceptual framework to SMM for POIL [17]

Full size image

DEMO is based on different kernel theories (explanatory and/or predictive theories) with clearly defined concepts and constructs. The basic concepts of DEMO, summarized by Dietz in the Performance in Social Interaction (PSI) theory [3 pp 81-125], constitute the explanatory design theory. The models and the modeling method together constitute the design practice theory of the conceptual framework (see Fig. 8). The design practice theory and the explanatory design theory together compose the explanatory and constructive design theory, which is the DEMO methodology.

Regarding SMM for POIL, 21 reusable method fragments can be considered as general design solution components, which can be composed in order to derive at a situated POIL method. To derive at a concrete solution, which is described by means of instantiations of process models, information models and role models, the following sequential design steps need to be performed: design problem analysis, classification of design problem (project type), situated method configuration, and situated method adaptation. Being sufficiently generic for the addressed problem class, the method steps together with the resulting models constitute a design practice theory. The whole approach is based on an explanatory/predictive theory, namely contingency theory, which explains why the performance of certain POIL solutions depends on design project goals and the design problem context.

The resulting artifact character map e.g., for DEMO is shown on top of Fig. 6. It visualizes the results of the analysis in applying the conceptual framework in a graphical manner. For each of the artifact types, as introduced in Fig. 7, such an analysis is recommended in order to gather a complete understanding of the approaches available for supporting the change process in organizations. A summary of the main contributions of the analysis of all approaches introduced in in Fig. 7 is illustrated in Fig. 10.

Fig. 10
figure 10

Artifact character map for organizational change

Full size image

In such a highly aggregated map, as visualized in Fig. 10, only the main focus (strengths) of reusable design artifacts can be visualized. For a detailed representation, the use of an artifact character map for each single approach is recommended (as shown in Fig. 6).

Using solution requirements and the two two-dimensional maps—the domain scope and the artifact character map—it is possible to identify solution components in a systematic way. As already mentioned above, real-world design problems often require several solution components (i.e. reusable design artifacts) to be combined because multiple aspects have to be covered and/or the problem combines characteristics of several domains.

Taking the example of redesigning the information logistics processes as shown above, Albani and Winter [17] demonstrate how a combination of DEMO and SMM for POIL leads to improved solution designs. The fact that both approaches aim at contributing to the same problem class, namely the support of management of organizational change by means of artifacts, which can be implemented or adapted to specific situations at hand, results from searching the application scope map (shown in Fig. 7). By consulting the artifact character map, which is based on the analysis of the two approaches by means of the conceptual framework for IS design and engineering, it becomes apparent that the result types of the two approaches differ completely. While DEMO focuses on designing the essence of an organization, SMM for POIL aims at the development of generic IS management methods that are adaptable to various design problem contexts and design goals.

The analysis and comparison of the two approaches enables the creation of a composed approach, i.e. one that combines situational solution support with modeling the essence of an organization, in order to construct more complete and improved solutions.

6 Conclusions and Future Work

Design problems in organizations require a systematic solution process that needs to be supported by efficiently organizing reusable solution knowledge. In our opinion, the differentiation of three cycles in DSR is artificial, and therefore the differentiation of a rigor related, a relevance related and a problem-solving related KB as a consequence should be avoided. We rather understand that every design cycle has rigor related as well as relevance related activities. Every design iteration involves learning more about the design problem and identifying additional elements of the KB components that might contribute to the solution. As a consequence, the KB of reusable design artifacts and the problem specification base should be organized in a way that supports this one-cycle DSR view.

We propose to annotate every potentially reusable design solution by information on artifact type, artifact generality, application domain and problem coverage. These four reference dimensions can be used to differentiate two two-dimensional maps that support a structured access and systematic identification of potentially relevant design artifacts: application scope map and artifact character map.

Building on a concrete design artifact amalgamation exemplar from the IS design and engineering field, we extended the demonstration example to the domain of organizational change. If we do not only know the design artifact type and its generality, but can also relate it to an application domain and define its problem coverage, then a systematic search can be defined that identifies potentially relevant reusable solution artifacts in an efficient way, thereby supporting the solution search process significantly.

The example of Baumöl [18, 19] is just one possible example for showing the applicability of our approach. However, it is a very good example since it already provides a first structuring of the knowledge base for organizational change problems. Baumöl [18, 19] has not only identified and validated problem domains and sub-domains of organizational change, but also used a large empirical base to identify successful patterns of instrument usage in organizational change projects. This knowledge will provide further opportunities to specify and validate application scope maps and artifact character maps that are not focused as much on IS design and engineering, as the example used in this paper was (DEMO and SMM for POIL). Due to the tight mutual links between organizational designs and IS designs, we are convinced that our design search procedure and design knowledge organization approach is not restricted to complex, situational IS design problems, but is useful for all kinds of organizational design and engineering where solutions need to amalgamate different reusable design artifacts and the understanding of the design problem is enhanced (and new potentially reusable existing solution components become apparent) in every cycle.