The engineering-based development of techniques in business and information systems engineering (BISE) requires knowledge on the part of the system designer. The paper points out the importance of this design knowledge in the course of scientific design processes and provides a framework for systemizing design knowledge. The framework is used to explain scientific design knowledge about the modeling technique of event-driven process chains. Implications of design knowledge in the context of BISE conclude the contribution.

1 Introduction

1.1 Initial Situation

Design-orientation is generally regarded as the central feature of the German-speaking business and information systems engineering (BISE) research. According to this belief, BISE research should not only explore theories for explaining, predicting, and understanding BISE-related phenomena, but should particularly develop innovative techniques in terms of methods, models, software prototypes, and similar artifacts which are useful for the solution of practical issues (Becker 1995; Hevner et al. 2004). This argument can be traced back to the work of Simon (1994) on the sciences of the artificial which form a counterpoint to the natural sciences. The sciences of the artificial do not explore the “given” reality like the natural sciences do, but create new, innovative, i.e. “artificial” realities. Hence, Frank (2006) refers to the creation and exploration of “new worlds” in terms of innovative information systems as a central feature of BISE.

This paper assumes that design-oriented research has an extremely high relevance for BISE as a science. If this belief is accepted, then important questions arise for the designer of an information system in a specific situation:

  • Objective: What design goals can or should be achieved during system design?

  • Technique: What technique can be used for system design in a specific situation?

  • Effect: What contribution does the use of a particular system design technique involve in terms of the intended design goal?

  • Context: Is it possible that a certain system design technique can be applied independently of a specific context or is it necessary to consider possible situation-specific features during the application of this technique?

  • Side effect: Does the application of a particular technique cause other effects in addition to the intended contribution for achieving the design goal, which may even be undesirable in a particular design context?

  • Alternatives: What other techniques can be used to achieve the design goal? What kind of advantages and disadvantages are associated with alternative techniques?

In this article we argue that in a specific design situation different positions can be taken with regard to the questions above. Some of the positions taken will be better founded, others less well. During the acquisition and evaluation of possible beliefs, scientific standards are to be considered, so that the answers to the previous questions constitute scientific knowledge as a result of theoretical research.

In addition to theoretical relevance, the previous questions are of similar interest for the practice of BISE: Answering the questions raised allows for the structuring and explication of an information system’s design process. Thus, the design process becomes transparent and communicable, which in turn is a prerequisite for the justifiability and repeatability of the design process as well as for a possible division of labor. Moreover, the critical discussion of various answers can be linked to the promise that the design is more effective and efficient, i.e. successful in comparison to a design that dispenses with the critical discourse of responses to the previous questions (Frank 2006, S. 10 f). Consequently, we argue that the discussion of these issues is necessarily linked to a systematic, rational, and engineering-based behavior in the design of an information system.

1.2 Objective

This paper aims to identify the importance of design knowledge for design-oriented research and to set the foundations for conceptualizing scientific design knowledge. In detail, the contribution pursues the following sub-objectives:

  1. 1.

    Explanation why design knowledge is relevant for design-oriented research,

  2. 2.

    representation of the characteristics of design knowledge,

  3. 3.

    development of a proposal for a framework for describing design knowledge within design-oriented research,

  4. 4.

    exemplary presentation of scientific knowledge about techniques of system design based on a selected example, and

  5. 5.

    derivation of implications for future design-oriented research.

1.3 Structure of the Contribution

After the introduction in Sect. 1, Sect. 2 gives details about the research framework of the investigation. Section 3 describes the current state of discussion about design knowledge in the literature. Section 4 deals with the conceptual foundations for the structuring and documentation of scientific design knowledge. Starting from a model of system design, we illustrate the features and characteristics of design knowledge and justify the relevance of using design knowledge in design-oriented research. Furthermore, we introduce a framework for the description of design knowledge. We present an exemplary representation of design knowledge by means of a system design technique in Sect. 5. We discuss implications for future design-oriented research in Sect. 6. The paper concludes with a summary of results.

2 Practice, Theory and Philosophy of Science of BISE – A Framework

Issues concerning philosophy of science in general and of business and information systems engineering (BISE) in particular are controversial. Therefore, we consider it a mistake to join an “established” philosophy of science a priori. Instead, it is necessary to explicate the framework that is relevant for the present study.

In this contribution, philosophy of science is understood as a discipline which produces, evaluates, and uses scientific knowledge about the production, evaluation, and use of scientific knowledge (Schurz 2006, p. 11 f). While philosophy of science in general deals with issues that relate to scientific knowledge in all sciences, specific philosophies of science focus on the production, evaluation, and use of scientific knowledge of a particular science.

In the context of the present study we distinguish practice and theory of BISE, philosophy of science of BISE, and philosophy of science in general. For the delineation of these concepts, we formulate key questions as presented in Table  1 (Scherer 1999, p. 4; Wyssusek 2004, p. 87 f).

Table 1 Key questions of philosophy of science (of BISE), theory and practice of BISE (based on Scherer 1999, p. 4; Wyssusek 2004, p. 87 f)
Full size table

3 State of Research

The thesis followed in this contribution stating that design knowledge is of high relevance for system design is by no means fundamentally new. Hence, it is commonly acknowledged that knowledge improves the capacity of actors. This is one of the main reasons for a great amount of literature on knowledge management that deals with this relationship (Lehner 2009). Also, there are already several works which examine knowledge in terms of methods of system design. Rossi et al. (2004), for example, claim to take knowledge about methods of system development into account. However, the literature does not discuss knowledge that can fulfill scientific criteria. Instead, these works rather consider the importance of knowledge for action in practice. They do not consider that this knowledge should also be accessible to scientific verification. In other words, a distinction between everyday knowledge and scientific knowledge is not explicitly made.

Studies on scientific knowledge belong to the area of epistemology and philosophy of science respectively. As outlined in the previous Sect. 2, the production, evaluation and use of knowledge is of central importance to scientific theory, and thus is a matter of course from this perspective.

However, considering the works on philosophy of science in general we can detect a significant deficiency from the perspective of BISE: The importance of scientific knowledge in relevant theoretical positions (logical positivism, critical rationalism, methodological constructivism, critical theory) regularly implies scientific knowledge in natural or social sciences. The extent to which this understanding of scientific knowledge can be easily applied to BISE as a technique-oriented engineering discipline is doubtful and urgently requires a more thorough discussion (Frank 2006).

Lately, this research gap has been increasingly closed by contributions addressing aspects of a specific philosophy of science of BISE. After a closer analysis of these contributions, it is striking that these works address the significance of design knowledge in system design. For example, Hevner et al. (2004, p. 75 and 82) indicate that in the course of design-oriented research knowledge about the problem domain and possible solutions is important. Peffers et al. (2007, p. 75) describe that knowledge in the form of “how to knowledge”, “analysis knowledge”, and “disciplinary knowledge” occurs during the development of an IT artifact. Even Frank (2006) considers scientific knowledge within an approach for the configuration of research methods. However, so far the perspective is particularly emphasized that design-oriented research comprises the development, verification, and evaluation of innovative IT artifacts. In particular, the distinction between an IT artifact and the scientific knowledge about the IT artifact is not explicitly made. The specific nature of scientific knowledge about IT artifacts and its systematization are not examined in more detail.

The exclusive study of scientific knowledge on innovative IT artifacts is not excluded explicitly, but it is not seen as an independent contribution of a design-oriented research approach in particular. This leads to the fact that in recent work on philosophy of science of BISE design knowledge about IT artifacts takes no central role and is not analyzed intensively.

In other words, although there are contributions that address the importance of design knowledge within design-oriented BISE, there is a lack of explicit and systematic studies on the importance of design knowledge about IT artifacts for design-oriented BISE.

The previously described lack explicitly does not refer to the fact that design knowledge about IT artifacts is not produced within specific design-oriented research projects. In contrast, a high amount of design knowledge is achieved within design-oriented BISE. However, these works usually focus on the specific IT artifact and not on the general design knowledge about the IT artifact. Thus, there is a lack of explicit investigations and presentations of the design knowledge about IT artifacts, its systematization, and the comparison of design knowledge of different IT artifacts.

Consequently, the “research gap” as shown in Fig.  1 can be summarized as follows: Indeed, the literature emphasizes the importance of design knowledge in general and in the context of design-oriented research in particular. However, these works only insufficiently analyze the central role of design knowledge for design-oriented BISE. In particular, no systematic distinction between a technique of system design and the knowledge about a technique is made. This results in the fact that the existing design knowledge about techniques of system design and the importance of design knowledge for design-oriented BISE has only been explored insufficiently and therefore has to be analyzed in more detail.

Fig. 1
figure 1

Delineation of the present study and prior research

Full size image

4 Knowledge in the Design of Information Systems

4.1 Model of System Design

For design-oriented research, the design of an information system constitutes a central issue. In the following we introduce the model of system design as shown in Fig.  2 in order to define what is meant by the design of an information system:

  1. 1.

    Requirement of the design subject: In order to be able to talk about system design, at least one subject exists who carries out the design. In general, this is expected to be a human being. However, it is possible that in future isolated parts of system design are taken over by machines. Initial approaches exist, such as in the context of automatic programming.

  2. 2.

    Requirement of the design object: The system designer performs design activities to achieve changes in a design object. In BISE, typically human-task-technique-systems constitute the objects of system design (Heinrich et al. 2007). In a concrete design situation, however, also a part of an information system, such as the software system, may be considered as a design object.

  3. 3.

    Requirement of system evolution: An information system as a design object can be analyzed at different points in time. Figure  2 depicts an example of an information system at the points in time t 0 and t 1. The period of time between t 0 and t 1 can be understood as a process in which the information system undergoes various changes as a design object. System evolution is on hand if the information system IS goes through different states during the time interval t 0 to t 1. For example, new techniques can be applied or the tasks to be implemented are subject to change. Apart from small, continuous system changes system evolution also comprises serious, disruptive (“revolutionary”) changes of the information systems (“evolutionary leaps”).

    Fig. 2
    figure 2

    Model of system design

    Full size image
  4. 4.

    Requirement of the availability of techniques for designing an information system: A system design is based on the availability of a technique that can be used to change the information system. This technique can either be already available in the information system as part of the technology-component or can be part of the design object’s environment. The term “technique” is not only understood as a particular information and communication technology in the narrow sense, but also in broader terms: something is a technique just if it reliably functions as a means to achieve a goal (Sachsse 1992). Thus, our term of technique also encompasses tools.

    The notion of a technique implies that it is possible to repeat the use of the instrument to achieve a certain objective (Grunwald 2008, pp. 43–50). If such a repetition is in principle impossible, then we are dealing with a unique context of action in the case of which we cannot talk about a technique for system design. There is no question that the application of individual techniques in each specific case leads to varying results and in some cases is not even promising. However, it is expected that this is not the case in principle. Instead, it can be assumed that usually the application of a specific technique is associated with the achievement of certain situation-invariant effects and thus is also promising.

  5. 5.

    Requirement of intentionality as regards objectives: Not every system evolution and every application of a technique can be understood as system design. Instead, it is assumed that the system designer aligns his actions for system design to certain plans and that system design, in this sense, is based on the intentions of the system designer. System evolution is significantly influenced by the realization of the plans of one or more system designers. A system designer will regularly perform such acts of which he believes they contribute to the expected consequences of action to achieve the design objective.

The five above mentioned requirements define the model of system design introduced in this paper. If these conditions are met in relation to a particular action context, this is hereinafter referred to as system design.

Against the background of the proposed model it shows that a technique can take different roles during system design. First, a system designer can use a technique to achieve a design goal. In this case, a technique is used as a means to design the design object. For example, a system designer may use event-driven process chains for the documentation of business processes. Second, often the result or product of system design is itself seen as a technique, which then forms an integral part of the technology-component of an information system. For example, business process models are not formulated for their own sake, but may serve, e.g., to increase the effectiveness and efficiency of the introduction of a workflow management system. Third, a technique may not only be an outcome but also a starting point for system design: This is the case, for example, when an already-established workflow management system is to be shut down again at a later design stage (“technology disposal”).

Furthermore, we also must refer to the connection between an artifact and a technique:

  • On the one hand, an artifact in terms of an item created by a person is not necessarily a technique. In particular, this applies if no convincing goal-means-statements can be formulated for the use of the artifact.

  • On the other hand, a technique is not necessarily an artifact: Even the pebbles found at the shore can be used effectively as a murder weapon. Presumably, there are hardly any relevant techniques in BISE which do not constitute artifacts. However, the common saying “a task can be assigned to a human or a mechanical task bearer” highlights that persons, who undeniably have not been considered artifacts so far, are sometimes used like machines which are typical manifestations of artifacts, as a means for fulfilling a task, and thus are used in terms of a technique. Consequently, non-artifacts constitute relevant techniques in BISE in this case.

The previous considerations show that there is an important difference between an artifact and a technique: If an artifact is given the status of a technique, then it is already assumed that the application of this artifact produces certain effects, so that the artifact forms a means for achieving certain objectives.

4.2 Delimitation and Typification of Design Knowledge

Design knowledge is regarded as the knowledge which the design subject has for the design of a system and which affects the implementation of actions for system design. Hence, design knowledge includes the set of knowledge which is relevant to the action of system design. In the following, we first define the term “knowledge” in more detail. Then, typical aspects of design knowledge are characterized and typified as regards content.

The term “knowledge” has been controversial for over two millennia. A generally accepted explanation has been neither proposed in the philosophical nor in the expert discourse (Grundmann 2008, pp. 71 ff). Also in BISE and related disciplines of business administration and computer science, the concept has been discussed intensively without having achieved the status of a commonly used term (Lehner 2009, pp. 46–66). This debate cannot and should not be recapitulated here; instead, we present several details of the term’s use in this article.

In the following, the concept of knowledge is understood in the “classical” sense that distinguishes knowledge from “mere” belief. Knowledge is characterized, therefore, by the fact that a certain belief or opinion is expressed, but in contrast to “mere” opinions several conditions are assumed:

  • Justification: Some opinions are considered as knowledge if they are founded. Deductive justification is considered convincing (Zelewski 1999, pp. 36–38), but this justification standard cannot be achieved generally. Instead, in each case different justification standards may be acceptable (Føllesdal et al. 1988; Stegmüller 1983).

  • Claim of truth: The opinions expressed should not only be founded, but it is also claimed that these constitute correct and not false beliefs. For the discussion of various theories of truth we refer to the literature (Gloy 2004; Habermas 1973).

Four forms of knowledge can be distinguished (Grundmann 2008, p. 86; Detel 2007), with concrete examples from the context of system design already providing a first impression of the importance of design knowledge:

  • Know that (propositional knowledge): Knowing that something is the case. For example: The system designer knows that Chen developed the entity-relationship model. Or: The system designer knows that an entity-relationship model facilitates the communication between business users and database developers.

  • Knowledge by acquaintance: Form of knowledge related to persons, things, events, and other items. For example: The system designer knows the entity-relationship model.

  • Know as it is: Form of knowledge related to own phenomenal states. For example: The system designer knows how it is like to see a graphical representation of an entity-relationship model.

  • Know how: Knowing how something is done. For example: The system designer knows how to use the entity-relationship model.

In the literature it is controversial whether these forms of knowledge can be fully attributed to “know that” (Grundmann 2008, p. 86).

A priori, it is difficult to fully determine which knowledge actually constitutes design knowledge in a specific system design situation. Potentially, any knowledge appears to be more or less relevant to system design. However, based on the previously introduced model of system design we can conclude that a design subject must have a minimum amount of design knowledge in order to consider a given context of action as system design at all: The system designer must know about the available techniques and their possibilities. If the system designer does not have this knowledge, he cannot intentionally choose and use the available techniques. A system designer must not only know that a potential technique is an effective technique for system design. He must also choose an appropriate technique from the set of potential techniques in the event that several potential techniques for system design are available.

Consequently, in a particular design situation a system designer must evaluate the extent to which the existing techniques fulfill the requirements of system design as specified by the intended design goal. In this context, it is of no interest to determine the requirements for techniques in a specific system design situation, but it is important to identify general design requirements in any situation. The result of an investigation of the extent to which a potential technique meets these general requirements is represented by the design knowledge a system designer must at least have to carry out a system design task.

The resulting identified requirements are divided into two different groups:

  • Minimum requirements: These requirements must at least be fulfilled to be able to talk about a technique at all. They represent more or less analytic consequences of the concept of a technique.

  • Comparative requirements: These requirements allow a system designer to assess several techniques in relation to each other. Thus, knowledge about comparative requirements is relevant if several techniques are available.

The requirements listed in Table  2 are explained in more detail below:

  • Effect: By definition, the application of a technique leads to a specific effect. This effect can also be regarded as a design objective which is to be achieved by means of applying a technique. If the application of a technique does not lead to a certain effect, it is simply ineffective. As a consequence, it cannot be referred to as a technique in the sense of an instrument to achieve a determined goal as assumed here.

  • Repeatability: By definition, the multiple use of a technique regularly leads to the same effect. If the repeatability is not given, then the effect of the technique is not systematical but is due to chance or result of a miracle.

  • Impersonality: By definition, the application of a technique is impersonal. This does not mean that the application of a technique does not require specific individuals or that the technique has no effects on specific individuals. On the contrary, this requirement describes that the application of the technique is fundamentally independent of which person is applying the technique. This condition does not preclude that the application of the technique requires a certain education level or participation in specific training. It is also possible that certain skills and talents of the technique’s user affect its application. However, we must postulate that in principle the technique can be used by any person. In this way, the application of a technique can be distinguished from non-intersubjectively teachable sorcery and magic.

Table 2 Summary of requirements for a system design technique
Full size table

In addition to the minimum requirements different comparative requirements are of interest:

  • Relevance: If the effects of a technique are interpreted as design goals, it is possible to determine the practical relevance of a technique: The technique’s practical relevance is defined by the extent to which the intended effects of the technique correspond to the objectives pursued in practice.

  • Application domain: In principle, a technique by definition cannot be exclusively applied at one individual point in time only once. However, a technique regularly has just one specific domain in which it can be used in a meaningful way.

  • Side effects: The application of a technique regularly involves more or less intended side effects besides the desired main outcome. The side effects of a technique can sometimes be without complication, but may in other situations also be quite problematic and thus are of interest in the comparison of alternative techniques.

  • Degree of maturity: The maturity of a technique is determined according to which and how many actual applications reliably proved the repeatability of a technique.

  • Degree of routine of the application: In principle it is desirable that a technique can be applied impersonally and repeatably. This requires that an instruction for action is provided for the application of a technique. Ideally, the instruction is given algorithmically. This ideal case can, however, only be fulfilled by a small subset of available techniques.

  • Costs: The application of the technique regularly causes certain costs.

  • Efficiency: Efficiency relates the effect of a technique to its costs.

4.3 Relevance of Design Knowledge for Design-Oriented BISE

Analyses and studies about the extent to which a specific technique meets the previously described requirements result in design knowledge about this technique. This knowledge about the technique is conceptually independent of the technique itself. This important difference is obvious for material techniques, such as a loom, a steam engine, a telephone, a computer network or a computer mouse. The fact that knowledge is abstract and not material in the same sense as the previously mentioned techniques makes a confusion of technique and knowledge about the technique impossible.

However, there are also different techniques in system design which are not concrete in the above sense. Exemplarily, we may list specific techniques of programming, software engineering, information or business process management. Although the difference is less obvious due to the immateriality of these techniques, we have to conceptually distinguish a specific technique and the knowledge about the technique in terms of effect, repeatability, etc.

Knowledge about the techniques of system design is relevant to the theory of BISE as it aims at the production, evaluation, and use of knowledge about the practice of BISE by definition.

In addition, this knowledge is also relevant to the practice of BISE as the design knowledge has a significant relevance for a specific system design. The existing techniques must be used in a way that the largest possible contribution to the objective is achieved (maximization principle) or a given design objective is achieved with the minimal use of the technique (minimization principle). The availability of knowledge about techniques as regards effect, repeatability, etc. enables a system designer to act in accordance with the economic principle. If the system designer does not have such knowledge, he has to select the used techniques based on his intuition or coincidence. At this point, we do not argue that such approaches for the change of information systems are a priori less successful or even fail in principle. It should, however, be pointed out that this situation can be hardly referred to as an engineering approach to system design.

Figure  3 shows that a system designer has knowledge about techniques for system design in addition to specific techniques. Since this knowledge can be produced, evaluated, and used scientifically, we claim that technique-oriented research, as part of design-oriented research, should be expanded by a knowledge-oriented research. Technique-oriented research aims at the creation of innovative techniques, knowledge-oriented research aims at the creation of innovative knowledge about the techniques (Fig.  4 ).

Fig. 3
figure 3

Technique- and knowledge-oriented perspective on design-oriented research from a structural perspective

Full size image
Fig. 4
figure 4

Technique- and knowledge-oriented perspective on design-oriented research from a dynamic perspective

Full size image

4.4 Framework for the Documentation of Design Knowledge

Table  3 shows the framework for the documentation of design knowledge. The first section includes the context and a brief description of a technique as well as the superior design goal of the technique. The second section provides a detailed characterization of the technique. This particularly explains how a technique fulfills the minimum and comparative requirements as described in Sect. 4.2. In addition, the framework comprises a third section including alternative variants of the technique and alternative techniques.

Table 3 Framework for the documentation of design knowledge
Full size table

Basically, we can assume that design knowledge is awarded different degrees of credibility. Ideally, a design knowledge statement can have a maximum of evidence: The statement is proven true and has to be accepted in all circumstances. At the other extreme, the truth value of the statement is unknown, but the statement has a certain plausibility. For a further differentiation we propose to start with using the number of times specific statements are mentioned. Based on this measure, the acceptance and relevance of certain statements can be roughly estimated. However, it is undisputed that the frequent reference to an obviously false allegation does not make the content of the assertion more evident. Therefore, we propose to additionally distinguish five levels of evidence that differ as regards content:

  • Level I: Plausible statement without further justification. The statement is not visibly false and neither conceptually nor empirically supported. Example: “Technique T is easy to use.”

  • Level II: Plausible statement which is proven by merely conceptual consideration without empirical evidence. Example: “Technique T is easy to use since during its design the key success factor of a clear user interface was taken into consideration.”

  • Level III: Statement that is backed up by exemplary experience. Example: “Technique T is easy to use. This was illustrated by three case studies in which T was exemplarily used.”

  • Level IV: Statement that has held good in a variety of applications. Example: “A field experiment with a representative group showed that the technique T is easy to use for a significantly higher proportion of users (90%). Conflicting observations were made for some few participants.”

  • Level V: Statement which applies without exception or which can be deductively derived from acknowledged statements. Example: “Accepted assumption: Process modeling languages support communication about business processes. Fact: Technique T is a process modeling language. Conclusion: T supports communications on business processes.”

5 Design Knowledge in System Design Using the Example of Event-Driven Process Chains (EPC)

5.1 Presentation

With respect to the previous discussion we claim that “all” knowledge about the technique of system design has to be explored. This programmatic claim cannot and should not be realized at this point; instead the following investigation focuses on the technique of “event-driven process chains” (EPC) which is known since the early 1990s.

As a result of its broad response, there is a plethora of literature on EPC which is hard to manage and which has been systematically investigated for this study. In order to acquire topical design knowledge about EPC we only considered articles of the last 10 years. The amount of papers was determined by a systematic search according to Fettke (2006) in one German-language (WisoNet) and one internationally-oriented database (EBSCOhost). The identified works were complemented by sources taken out of the EPC bibliography of the GI group on “Business Process Management with Event-Driven Process Chains” (WI-EPK). In this way, we identified a total of 72 articles that address design knowledge about EPC.

The design knowledge about EPC documented in these articles was extracted in the form of individual statements. In accordance with the proposed framework we then systemized and consolidated these statements and annotated the number of sources to support this statement as well as the respective level of evidence for each statement. Table  4 summarizes the results of this work.

Table 4 Design knowledge about event-driven process chains. The table shown here visualizes an excerpt of the identified knowledge about the EPC. A complete overview of the results obtained, including the specific references, can be found in the supplement to this paper (see note on the first page)
Full size table

5.2 Discussion

The documentation of the context, the overall objective, and in particular the comprehensive representation of the central characteristics of the EPC technique make it possible to assess its suitability for achieving a practical design goal. The system designer learns, among other things, that EPC constitutes an established, intuitively and easily useable technique with a high acceptance rate. This allows drawing conclusions about its quality and potential to achieve the originally defined goals as well as further objectives which the conception does not focus on, such as the automation of process models.

However, in the description of some characteristics the mentioned scope remains unclear. The interpretation of the individual descriptions is often left to the system designer. Mertens et al. (1982), for example, provide a structuring of the effective range of computer-related techniques by means of their four-level model, which includes the individual, business, economics, and world level. The assignment of the effects is not always clearly elucidated. Thus, it is clear that the easy comprehensibility of the EPC mainly refers to the individual level. However, exact estimates of what effects result for the other levels, such as the business or economics level, are not documented within the examined literature.

Knowledge about the minimum requirements for a technique are described in detail in the literature on EPC, and certain statements are supported by many different sources with different degrees of evidence.

Regarding the comparative requirements for a technique, the system designer is provided with a comprehensive knowledge base for the EPC for assessing the relevance of the technique in the described context, the potential application domains, and possible side effects. As the syntax and semantics of the EPC were not clearly defined in a formal way at its introduction, EPC models may be ambiguous and can be misunderstood. At this point it becomes clear that there may also be potentially contradictory findings within the portfolio of design knowledge about EPC which the system designer must take into account for his decision, such as the statement “EPC are easy to understand” and “EPC can be misunderstood”. The system designer can base his personal assessment on the number of supporting sources and the highest level of evidence. These provide an impression of the acceptance, consistency, and justification of the described knowledge. The potential ambiguity or misunderstanding of EPC models is opposed to the relatively large freedom of expression and the ease of use. On the basis of this knowledge the system designer can decide to what extent the described technique is suited for the desired design goal. It becomes clear that EPC is a simple and effectively usable technique for process documentation. However, if one intends to use it for the automation of business processes, further efforts concerning the formalization of the models is required.

The described knowledge about the degree of maturity and the potential degree of routine of the technique’s application allows the system designer to accurately determine whether it meets his individual or the organization-wide requirements for the maturity of a technique. Exactly documented knowledge on the costs or on the efficiency of EPC use does not yet exist within the analyzed literature, so that the system designer’s decision must be based on generally established thoughts on licensing and training costs, etc.

The overview of the technique’s various variants allows the assessment of the technique as regards its ability for more specific and more narrowly defined objectives, such as the integration of Web services in EPC models or the use of imprecisely formulated business rules. By means of the overview the system designer may also learn about other, previously unknown options for action provided by the extensions of the technique.

The knowledge about alternative techniques highlights further options for the solution of a problem. If also well-established knowledge about the respective alternative techniques exists, broad comparisons and consequently well-informed deployment decisions of the systems designer are possible.

6 Implications for Design-Oriented BISE

Table  5 provides an overview of the implications discussed below.

Table 5 Implications for design-oriented BISE
Full size table

6.1 Implications for the Theory of BISE

For the theory of BISE it is particularly important to identify design objectives that are actually relevant in practice and to analyze the relationships between these objectives (conflicting, complementary, or neutral) in order to particularly guide the activities of technique-oriented research towards this direction. In this way, the theory of BISE can make a relevant contribution to the practice. In addition to an a priori analysis of design objectives it is also necessary to ask ex post to what extent the intended goals are achieved in the design of an information system. This enables the control of the system design’s success. To determine the actual achievement it is necessary to substantiate the design goal and to use instruments for measuring the success.

Furthermore, there is the question of which techniques are actually used in practice. More detailed analyses of the use for certain user groups, industries, etc. may promote the discovery of interesting usage patterns. In addition to descriptive questions it is of interest with regard to theory building to theoretically explain emerging patterns of use of techniques and thereby explore the acceptance, diffusion, adaptation, and configuration of techniques. Therefore, it is necessary to identify factors that may be considered as the cause for the use of certain techniques.

Similarly, the discovery and explanation of empirical regularities concerning the effects and side effects of techniques of system design are of high relevance to the theory of BISE.

6.2 Implications for the Philosophy of science of BISE

For the philosophy of science of BISE, which deals with the production, evaluation, and use of design knowledge developed in the theory of BISE, the investigation of some properties of design knowledge is relevant for the further research process:

  • Acceptance of design knowledge in the scientific community,

  • confirmation of design knowledge through independent studies,

  • consistency or inconsistency of design knowledge,

  • justification of design knowledge (adequate justification standards),

  • truth of design knowledge (adequate theory of truth), and

  • gaps in design knowledge.

The knowledge about the effectiveness of certain techniques is empirical. Due to the complexity, dynamics, and intentionality of information it remains unclear to what extent empirical regularities can be identified and justified unambiguously and convincingly. On the other hand, the central feature of a technique is that the application of a technique leads to situation-invariant and regularly occurring effects (Grunwald 2008, p. 43 f).

So far, the theory concept in BISE has been investigated with little intensity. It is sometimes argued that the linguistic representation of a technique, such as in the form of a reference model (Fettke and Loos 2004) or a method (Greiffenberg 2003), can be understood as a theory. This theoretical understanding is however not congruent with the understanding of the philosophy of science in general, according to which a theory represents a relationship of statements including at least one law-like statement (Bunge 1998; Zelewski 1999, p. 30). Consequently, we claim that future work must discuss the theory concept of BISE more explicitly and more intensely.

For some time, researchers have kept discussing “rigor” and “relevance” of the theory of BISE (Applegate and King 1999). It seems interesting to relate the discussion of both criteria in separate ways to technique- and knowledge-oriented research. A standard assessment of technique-oriented research is hardly possible since not every technique-oriented research is of high relevance. This becomes clear when additionally considering the knowledge-oriented perspective: If certain design objectives are not pursued in practice, it is debatable whether techniques to achieve these design goals should be explored at all. On the other hand, it is scientifically attractive to develop proposals for “innovative worlds” which offer alternative proposals for the prevailing practice (Frank 2006). In Sect. 4 we argued that knowledge-oriented research is relevant to system design. Subsequent works should intensify the discussion of “rigor” and “relevance” of the theory of BISE in relation to the introduced technique- and knowledge-oriented perspective on design-oriented research.

Within BISE, numerous fads and a lack of long-time research are deplored (Mertens 1995). The complaint can be substantiated in the sense that within design-oriented research new techniques are often understood as being innovative, regardless of whether there are similarities to existing techniques. If similarities are not recognized, a cumulative study of the knowledge about techniques for system design is significantly complicated. To support a cumulative research on techniques it is necessary to work out similarities and differences of various techniques. If this succeeds, we can apply design knowledge about a technique to “related” techniques. In this way, BISE research helps to further increase the maturity of the terminology of BISE.

The exchange between theory and practice of BISE increases its significance as a result of the importance of design knowledge, as shown in Fig.  4 . In order to further intensify this exchange, models of closer cooperation between theory and practice seem interesting in order to support an unobstructed diffusion of techniques and knowledge about techniques. In medicine, for example, it is common to integrate medical research and practice in university hospitals in terms of space and personnel. In BISE, cooperation of scientists with the practice is often equated with consultancy services that do not meet any scientific standard. Against this background, it is necessary to search for scientifically acceptable and fruitful cooperation models between theory and practice, such as in the form of consortium research.

With the distinction between knowledge- and technique-oriented design-oriented research it is possible to describe the degree of innovation of a design-oriented research paper in a more differentiated way. Thus, innovation can exist in the form of a new technique or in the form of new knowledge about an existing technique. The distinction between state of knowledge and state of technique also has consequences for the creation of state-of-the-art contributions. Hence, we have to distinguish whether a state-of-the-art contribution reflects the state of technique or the state of knowledge about a technique. It seems appropriate to differentiate between the state of knowledge and state of technique in practice and theory of BISE. For example, for the acquisition of the state of knowledge within the theory of BISE, an analysis of scientific literature may be used. An analysis of scientific literature with regard to the state of knowledge or of technique in BISE practice may, however, at best produce only secondary information as usually no direct analysis of the practice of BISE is carried out (e.g., in the form of an observation).

6.3 Implications for the Practice of BISE

Against the background of the argumentation from Sect. 4, design knowledge has considerable relevance to the practice of BISE and the design of information systems. It is of interest to adequately integrate the experience and knowledge of the practice into the theory of BISE. However, this generally favorable development also leads to the fact that design knowledge is discussed scientifically and thus in public. Therefore, the available scientific design knowledge cannot be used as a strategic competitive advantage for a company. It seems interesting to discuss how the requirement of design-oriented BISE of exploring knowledge and techniques that promise strategically relevant competitive advantages for a company can be maintained.

6.4 Implications for the Teaching of BISE

The explication of design knowledge allows teaching knowledge about techniques. In this way, knowledge about the use of techniques can be conveyed and passed on. At the same time, academic teaching requires that design knowledge is not only explained but also generally accepted.

For the teaching of BISE it is important that it does not merely focus on techniques, meticulously conveying “all” details about “all” techniques. Instead, it is also necessary to teach knowledge about the effect of techniques. In this context, we must clarify what level of acceptance the experience and knowledge about techniques of system design must have in order to allow teaching it: It seems hardly reasonable to immediately teach every new assumption about a technique’s effect. On the other hand, innovative knowledge about innovative techniques of system design should be conveyed to students at an early stage to ensure their ability to act.

7 Summary

In this contribution we argued that knowledge is of high relevance in the design of information systems. Therefore, we argued in favor of explicitly considering knowledge-oriented research to a greater extent within design-oriented BISE. Besides the general reasons for the importance of knowledge in system design, we illustrated the role of scientific knowledge by means of an example. Here, we used a framework that covers the essential aspects of design knowledge.

If the knowledge-oriented perspective on BISE is neglected, the risk emerges that design knowledge about innovative IT artifacts is not explored systematically. The neglect of knowledge in design-oriented research leads to various problems (Frank 2006):

  • Issue of lacking originality: Originality requires innovative techniques to set themselves apart from established techniques. Here, originality of a technique should not refer to the characteristics of the IT artifact alone, but should also take knowledge about the effect of the use of the IT artifact into account. What good is a highly innovative artifact the effect of which does not exceed effects of established techniques during its application?

  • Issue of lacking abstraction: Design-oriented research requires to comprehensively document innovative techniques. Otherwise, it is impossible for third parties to obtain knowledge about the techniques. However, the observations must not be limited to the detailed description of a specific IT artifact and its use. Instead, it must be clear what kind of similarities and differences exist compared to existing IT artifacts.

  • Issue of lacking justification: Design-oriented research requires that the needs of a specific design context are met. However, it is also necessary to prove that general minimum and comparative requirements for a technique as mentioned above are met.