Towards Applying Normalized Systems Theory ... - CIAO! Network

Towards Applying Normalized Systems Theory Implications to Enterprise Process Reference Models Peter De Bruyn, Dieter Van Nuffel, Jan Verelst, and Herwig Mannaert Normalized Systems Institute Department of Management Information Systems Faculty of Applied Economics University of Antwerp Antwerp, Belgium {peter.debruyn,dieter.vannuffel,jan.verelst,herwig.mannaert}@ua.ac.be

Abstract. The analysis phase in the overall development life cycle of information systems has frequently proved to be a difficult assignment as the quality of the work heavily depends on the skills, experience and domain knowledge of the analyst. As a consequence, analysis patterns and reference models have been introduced in the past as a means to consolidate best-practices in conceptual modeling (often incorporating specific domain knowledge) and guiding analysts in their modeling efforts. However, the actual evaluation of reference models or analysis patterns available remains a challenging issue. Here, the evolvability or flexibility of the considered frameworks seems to be a legitimate evaluation criterion. Hence, in this paper, the well-known SAP Reference Model framework is analyzed with regard to its adherence to Normalized Systems (NS) theory design principles as this theory specifically focuses on the evolvability of modular structures such as information systems and business processes. It is concluded that it is feasible to employ the NS theory to evaluate such reference models from an evolvability point of view and distinguish both aspects and indications towards conformance with NS theory, as well as indications of possible violations regarding its principles. Key words: Normalized Systems; Reference Models; Analysis Patterns; Evolvability; SAP Reference Model

1 Introduction Traditionally, the activities to be undertaken during information systems development are categorized into (successively) analysis, design, programming, testing, implementation and maintenance phases [1]. The analysis phase in this overall process has frequently proved to be a difficult assignment as the resulting quality of the work may vary significantly from project to project and heavily depends on the skills, experience and domain knowledge of the analyst [2]. Moreover, the results of this phase may have long-lasting and far-reaching

2

P. De Bruyn et al.

consequences which are difficult (if not impossible) to remediate later on during more advanced stages in the development cycle [3]. While some authors have claimed that this analysis (and more specifically the identification of elements in the conceptual models such as classes or objects) is as a rather straightforward activity suggesting even a high degree of determinism (see e.g., [4]), this view has frequently been criticized by authors stating that performing a systems analysis is far from trivial, most available guidelines are too simplistic or irrelevant and thus significant expertise-based and creative contributions of the analysts themselves are required [5]. In order to facilitate and ameliorate this difficult as well as time-consuming phase in the development process, analysis patterns or reference models were proposed in the past with the aim of guiding analysts during their efforts of drafting conceptual models and increase the quality of the overall work. More specifically, they can serve as a kind of blueprint for the information system to be developed in the future. While most research attention to the topic of reference model and analysis patterns is situated in Germany, the topic is believed to increase in popularity [6]. However, no clear consensus on a set of generally accepted reference models or analysis patterns is available and their evaluation remains a challenging issue. While some interesting evaluation criteria and frameworks are available, it is equally noted that it is necessary to actually also apply these evaluation criteria and approaches to specific reference models and analysis patterns [7, 6]: prior to the decision of an organization of adopting a certain reference model, the concerned organization obviously wants to be fully sure that the employed reference model indeed exhibits a superior (or at least good) quality. One such viable criterion to evaluate and analyze the quality and usefulness of reference models seems to be their evolvability or flexibility. First, as the main goal of reference models is to support various organizations in their modeling and design efforts, the abstracted representation should be adapted towards the specificities of the organization at hand, for instance by means of configuration. Second, the evolvability of organizations (“agility”) is increasingly becoming an essential and desireable characteristic for enterprises in order remain competitive in environments characterized by increasing change and increasing complexity. As their environment changes, organizations (and thus their supporting information systems, business processes, etcetera) have to adapt themselves accordingly. Reference models enabling this agility might thus incorporate a significant competitive advantage for the adopting organizations compared to those who decide not use them. Regarding the evolvability and flexibility of information systems, Normalized Systems (NS) theory has recently been proposed [8, 9, 10]. While its application initially focused on the evolvability and maintenance of software architectures, the theory can actually be interpreted in terms of and applied to modular structures in general [11, 12]. More specifically, the feasibility of applying the NS theory at the business level in terms of business processes and enterprise architectures has been proven by Van Nuffel [13] and Huysmans [14] respectively.

Applying NS theory implications to Enterprise Process Reference Models

3

As a consequence, the theory should be able to be leveraged to investigate the extent to which the processes included in so-called process repositories, exhibit the evolvability characteristics as proposed by NS theory and its application at the organizational level. Hence, the primary aim of this paper will be to prove this feasibility by analyzing the evolvability of some processes described in one such enterprise process reference model: the well-known SAP Reference Model (as described by Keller and Teufel [15] and Curran et al. [16]). This will be done by applying the implications of Normalized Systems theory to excerpts of the processes in [15]. The remainder of this paper will be structured as follows. In Section 2, some related work on the concept of reference models and analysis patterns will be presented. Here, some specific attention to the evaluation of these frameworks in extant literature will be given. Next, in Section 3, the essence of Normalized Systems theory will be briefly highlighted, emphasizing the implications of its application at the organizational level. Afterwards, a partial analysis of the processes embedded in the SAP Reference Model will be proposed, by focusing on some exemplifying excerpts illustrating adherence or possible violations with respect to Normalized Systems principles in Section 4. Finally, this paper will be ended by presenting some final conclusions, limitations and suggestions for future research (Section 5).

2 Related Work In this section, some related work on reference models and analysis patterns will be briefly discussed. First, an overview of the concept will be provided, together with its defining characteristics. Next, some specific attention will be given to the evaluation of reference models. 2.1 Reference models and analysis patterns The use and “culture” of patterns originated at the software level around 1993 based on the common belief that the object oriented software community was not able to come up with its expectations of reuse, simplification and productivity [17]. With the aim of valuing the expertise coming from domain-specific experience, the most well-known work in this field is probably the seminal work of Gamma et al. [18]. Later on, the concept of patterns was leveraged to the analysis phase of the development life cycle for information systems. The overall goal remained the same: consolidating (tacit) expert knowledge and best-practices for frequently recurring problems. Typically suggested advantages of this approach include the improvement of the overall quality of work delivered by less skilled or experienced analysts and an increased pace of the overall systems development. Well-known and frequently cited analysis patterns or frameworks include the work of [19, 20, 21, 22]. To a certain extent, also the REA framework [23] or the DEMO methodology [24] could be considered as making use of general patterns

4

P. De Bruyn et al.

in analyzing business functions. While the term “analysis pattern” and “reference model” seem to be frequently employed interchangeable, Kodaganallur and Shim [25] propose to position both concepts in relation to each other as reference models being a specific kind of analysis patterns having a low abstraction and high degree granularity. 2.2 The evaluation of reference models In the past, a few attempts were made to propose approaches for evaluating reference models. Indeed, before adopting a specific reference model, it might be useful for an organization to verify whether the framework exhibits a sufficient quality and incorporates the required (possibly company specific) features. For example, Fettke and Loos [26] propose several viewpoints for evaluating the quality of reference models such as feature-based evaluation, ontology-based evaluation or cognitive psychology-based evaluation. Another interesting approach for evaluating specific frameworks was introduced by Frank [7], employing multiple perspectives: – – – –

Economic perspective (costs, benefits, knowledge management, etcetera); Deployment perspective (understandability, appropriateness and attitude); Engineering perspective (e.g., language features, model features); Epistemological perspective (such as general principles of scientific research and theories).

In the first category, adaptation of the model and the degree of organizational re-design are mentioned as legitimate criteria. Similarly, the flexibility and evolvability of the models in such frameworks seems to be one legitimate aspect for their evaluation, next to the other relevant aspects mentioned above. However, it is equally noted that—despite the presence of such (elaborate) evaluation frameworks—few work has been done on the actual evaluation of specific frameworks using the evaluation approaches [7, 6].

3 Normalized Systems theory In this section, the essence of Normalized Systems will be outlined. First, the theoretical base will be summarized. Next, we refer to earlier attempts of applying NS at the organizational level. 3.1 Theoretical background Inspired by the need for organizations to be more “agile” as they are forced to deal with increasing levels of both change and complexity, Normalized Systems theory has recently been proposed in order to introduce evolvable modularity in organizations. Starting at the level of software architectures, the theory first

Applying NS theory implications to Enterprise Process Reference Models

5

proposes to regard the transformation of functional requirements R into a set of (constructional) software primitives S [8, 9, 10]: {S} = I{R} Next, the property of systems theoretic stability is imposed onto this transformation. This means that a bounded input function (i.e., limited set of requirement changes) should always result in bounded output values (i.e., bounded effort) even in the case where an unlimited systems evolution is considered. Changes that do generate an impact related to the overall size of the system are called combinatorial effects. These are manifestations of instability as their impact will increase over time and should thus be avoided. In order to attain stability, it has been formally proven that the following principles should be strictly adhered to [10]: – Separation of Concerns, enforcing each change driver to be separated; – Data Version Transparency, enforcing communication between data in a version transparant way; – Action Version Transparency, requiring that action components can be updated without impacting their calling components; – Separation of States, enforcing each action of a workflow to be separated from other actions in time by keeping state after every action. As these principles result in a very fine-grained modular structure in which each change driver has to become separated, five higher-level software elements were proposed as a constructive prove that it is possible to build such normalized (i.e., stable) software systems: action elements, data elements, workflow elements, trigger elements and connector elements [9]. Recently, initial efforts have been made to relate the above mentioned principles and elements to the concept of entropy from thermodynamics as well [27]. 3.2 Applying Normalized Systems theory at the organizational level Previously, it has been argued that besides software systems, organizations (and possibly other system categories as well) can equally be regarded as modular structures and hence Normalized Systems theory should be applicable in someway [12, 11]. Indeed, the feasibility of applying the NS principles at the level of business processes was proven by Van Nuffel [13] while Huysmans has done so for the high-level design of enterprises [14]. More specifically, in order to conform with NS theorems, a business process was proposed to be defined as being a constrained sequence (including iterations and selections) of tasks on one and only one life cycle information object [13]. A life cycle information object is then to be interpreted as a concrete and identifiable entity of information with a clear business meaning and having a distinct life cycle of states, which is represented by its corresponding business process(es). Next, it is argued that combinatorial effects, as defined in the previous section, can also occur at the

6

P. De Bruyn et al.

business process level when the impact of an elementary change is related to the overall size of the system (in this case the organization or process repository). Hence, each change driver (concern) should be isolated and encapsulated in its own task (i.e., elementary function of work) or business process (i.e., control flow of a constrained set of tasks). In order to further guide the identification process of these concerns, 27 guidelines for delimiting processes and tasks were proposed [13]. However, the research also stated that the identified concerns are still dependent on time, context and subjective interpretation. Consequently, as part of the quest to organizational constructional business process patterns as a next step in the NS research stream [12], the evaluation of enterprise process reference models might constitute a first attempt towards the reduction of these concern dependencies. 3.3 Employing Normalized Systems theory for evaluating reference models In previous work, already some initial efforts were made to analyze certain specific reference models with regard to their adherence to the Normalized Systems principles. First, it was investigated to which extent the processes available in the MIT Process Handbook [28, 29] provided the possibility to derive the corresponding organizational NS conform elements and patterns as described in Section 3.2 [30]. When trying to build the normalized constructional organizational building blocks based on the processes in the Handbook, the following issues emerged: – Underspecification: highly specified and detailed descriptions of the processes and (sub)activities are frequently missing, not attaining the needed finegrained broken down modular structure for building normalized patterns; – Lack of adherence to prescriptive design principles: no prescriptive guidelines are proposed, leaving (explicitly) the design effort to the personal intuitive insights of the contributors; – Top-down modeling and functional decomposition: processes are primarily derived from functionally decomposing general high-level processes into more detailed processes, resulting in process elements of a functional decomposition instead of elements from a constructional decomposition. However, it also needs to be stressed that the authors of the Handbook equally mentioned themselves that incorporating highly detailed processes based on rigorous design principles was not their initial aim neither. Next, some research has already been done in assessing REA’s compatibility towards Normalized Systems [31]. REA is an ontology originally proposed to design accounting information systems [23] and generalized later on for modeling economic exchanges in terms of Resources, Events and Agents [32]. Here, it was concluded that REA models cannot be directly translated to NS compatible patterns as REA does not force the modeler to include certain (oparational) elements which are required in NS conform models. Also, REA models do not offer any explicit guarantee for avoiding combinatorial effects.

Applying NS theory implications to Enterprise Process Reference Models

7

The taxonomy of Kodaganallur and Shim [25] proposes to map analysis patterns based on their abstraction and granularity. The former refers to the extent to which the framework can be reused in different application domains, while the latter is measured by its number of constituting elements. Relating the SAP Reference Model to this taxonomy illustrates one way in which it differs from the the frameworks discussed earlier (i.e., exhibiting a higher abstraction and lower granularity) and constitutes one reason reason why the SAP Reference Model has been chosen in this paper: it possesses a more granular nature and has been used as a blueprint to configure and guide the usage of many actual information systems. Section 4 will elaborate in more depth why the SAP Reference Model denotes a legitimate research object to be analyzed using the NS theory.

4 Analyzing excerpts of processes in the SAP Reference Model In order to prove the feasibility of leveraging the NS principles for enterprise process reference model analysis, the SAP R/3 Reference Model was chosen. First, in contrast with some other vendors possessing extensive and bestpractice largescale enterprise models, the SAP R/3 Reference Model is—at least partially—publicly available and documented in [15, 16]. Second, the framework has also been employed in many academic publications (see e.g., [33, 34, 35, 36]) and has served as one way to document the SAP R/3 system implementation. As such, it is one of the exceptional examples of how a published catalogue of bestpractice artifacts in the domain of software architectures and business processes can spur both academic research and prove practical relevance [37]. Traditionally, the framework has employed the event-driven process chain (EPC) notation to represent and visualize its processes. In essence, the notation requires the user to define flows between events (i.e., things that have happened in reality) and functions which represent the transitions of these processes from certain events to one or more other events. Additionally, three basic logical operators are available to allow different kinds of branching in the process. A concise overview of the notation legend is provided in Figure 1. Before analyzing the chosen framework in more depth, it should be noted that this analysis is not a mere trivial extension of the above clarified related framework investigations and the analysis might be expected to end up with other results. First, chances for so-called “underspecification” might be considered as reduced as these processes have served as a basis for documenting real-life software implementations used in different organizations. Moreover, the reference model has been included in SAP’s joining configuration methodology: the Iterative Process Prototyping (IPP) method. In short, this method is claimed to guide organizations in discovering which modules and processes of the SAP applications are needed for their purposes and to which extent adaptation of the processes or organizational procedures is required to achieve alignment between both. In contrast, the MIT Process Handbook has in fact resulted in primarily

8

P. De Bruyn et al.

Fig. 1. Legend for Event Driven Process Chains (EPCs)

a knowledge management framework offering organizations a means or tool to document, exchange and store business processes, rather than an extensively updated process repository which is publicly available. One of the uttered limitations regarding the REA modeling method is the fact that it has been mainly used for educational purposes, while its practical implementations in business situations have remained rather limited. Second, it was argued that the NS theorems as such are not new in the sense that they comply with the heuristic knowledge of highly skilled programmers [10]. Instead, the innovative character of the theory is situated in the formal proof of its theorems and their unification based on the systems theoretic notion of stability. The same phenomenon was observed in relation to its application for business processes, meaning that highly skilled and experienced business process analysts and designers acknowledged that the guidelines indeed correspond with their (tacit) knowledge of best-practice design [13]. Hence, we could expect upfront that the SAP Reference Model exhibits a more intrinsic tendency towards complying with the NS design principles, possibly unconsciously. However, also some indications were detected in earlier publications suggesting possible violations. For example, in their study for fragment-based version management of business process model repositories, Ekanayake et al. [35] identified “nearly 14% of redundant content in the SAP R/3 reference model ” [35, p. 21] based on their study in Uba et al. [36] . Besides their identified associated disadvantages related to version management (e.g., consistency between resembling business processes, the locking of particular parts of workflows, etcetera) this could also concur with a violation of the Separation of Concerns principle as this theorem requires the separation of all redundant parts into a single but separate module (in this case business process) in order to avoid combinatorial effects. 4.1 Indications towards conformance with NS principles Consider Figure 2, in which a part of the process for handling automatic vendor payments is depicted [15, p. 584–595]. It details the procedure to be followed for

Applying NS theory implications to Enterprise Process Reference Models

9

Fig. 2. Excerpt of the “Automatic vendor payment” process [15, p. 584–595]

a company to be able to fulfil its obligations in terms of payments as they fall due and allows the company to monitor its disbursements. In an international context, it is important to allow the features of different payment methods, forms or data media. In some first steps, the process reacts on payments of which the necessary parameters are defined, the deadline is reached and posted and released for payment. Next, accounts, due date and vendor are selected and some additional checks are performed. The concerned items for settlement are selected, grouped and a suitable bank as well as payment method is chosen. Finally, the details are checked, the payment is posted and completed. Based on this process, several facts can be noticed as tending towards compliance with Normalized Systems guidelines. First, the processes are formulated and drafted as a kind of information objects going through their respective lifecycles. In case of the above described payment process, for each individual payment for which an invoice is posted and the payment deadline has been reached, an instance of the object and a corresponding business process flow is instantiated after which each individual payment flows through the process of account selection, due date check, vendor selection, etcetera. Second, the extensive use of events highly resembles the usage of states in Normalized Systems software and its business process application. Indeed, both events (SAP) and states (NS) reflect the state (i.e., current situation or progress in the process) of an information object and are used in both approaches to trigger (i.e., start, execute) a function on that specific object. These functions might then be seen as the equivalents of the individual tasks in NS as both functions (SAP) and tasks (NS) perform the elementary actions in the processes and result in event (respectively state) transitions. Hence, both approaches result in viewing business processes as flows reacting on states by executing functions.

10

P. De Bruyn et al.

Third, the framework has specified tasks and actions in a more specified way than the earlier studied frameworks in relation to NS and discussed in Section 3.3. The REA model merely focuses on the business partners and resource exchanges that are involved in the business case of an organization. As such, the concerned “events” only refer to economic events such as “money income” or “sale”. The operational realization of these events and resource flows is (consciously) left out of scope. Considering the MIT Process Handbook, the general “Sell” process has a subprocess labeled “obtain order”. Logical reasoning would allow us to identify the “Purchase order processing” process of the SAP Reference Model as its counterpart. In the MIT Process Handbook, however, the “Obtain order” process is already situated at the most detailed and specified level. By contrast, in the SAP Reference Model, the “Purchase order processing” process has been split up into a flow of 10 separate functions with their respective events. Fourth, some guidelines as earlier proposed in [13] seem to find their reflection in the SAP Reference Model. For example, the Elementary Business Process guideline [13, p. 107–113] states that “a business process denotes a constrained sequence — i.e., sequence, iteration or selection — of individual tasks representing state transitions in the life cycle of a single life cycle information object”, which highly parallels our argumentation above as viewing the EPC notation in terms of objects going through their associated life cycles. The Value Chain Phase guideline [13, p. 132–134] states that the “follow-up of an organizational artifact resulting from a value chain phase denotes a different business process” as the different phases in the value chain constitute separate concerns and should thus be separated in their own module. In the SAP Reference Model, these processes seem to have been separated as well. For example, separate processes are drafted for “demand management”, “purchase order processing”, “invoice processing”, “good recept processing”, “inspection lot completion for goods movement”, etcetera. Additionally, stakeholder types and access channels seem to be generally regarded as cross-functional concerns [13, p. 153–160] (i.e., no separate process is identified solely for the sake of a different access channel or stakeholder, without an involved separate concern). 4.2 Indications towards violations with regard to NS principles When analyzing the SAP Reference Model, also some indications towards violations of the NS principles might be noticed. First, concerning the identification of the individual tasks/functions, it might be argued that frequently several separate change drivers are combined into one function. NS obviously does not allow this, as the combination of multiple change drivers into one function can result in combinatorial effects. Consider for example Figure 3 depicting an excerpt of the “Analysis of profitability” process of the SAP Reference Model [15, p.772–777]. It might be reasonable to expect that the “Analyze report online” function contains multiple separate tasks (functional entities of work) or change drivers, such as “change navigation hierarchy”, “create ranking”, “perform currency translation”, etcetera. This is also reflected in the fact that this function (just as some other functions which can be noticed in the framework) can result

Applying NS theory implications to Enterprise Process Reference Models

11

in multiple events (symbolizing multiple tasks that have been fulfilled during the execution of the function). Additionally, Normalized Systems theory does not allow a flow or business process to be in multiple states at one point in time. Each object requiring the tracing of an individual object state (i.e., not exhibiting state transparency with respect to the other objects) is to be considered as a life cycle information object having its own business process flow with exactly one state at a time. Hence, we could assume that functions in the SAP Reference Model framework are thus still not formulated fine-grained enough and combine several change drivers of which NS would prescribe them (1) to be split in multiple separate tasks or (2) to be represented in a separate business process flow.

Fig. 3. Excerpt of the “Analysis of profitability” process [15, p.772–777].

Second, some indications are provided that several concerns are combined into a single business process. According to NS, a single business process should be related to only one concern. Having multiple concerns into one business process would thus imply that some of them are not situated in the appropriate process. For example, consider the processes “delivery processing” and “goods delivery processing”, responsible for handling the delivery once an order is released [15, p. 706–725]. Here, it can be noted that the function “carry out credit control” is included in both processes. Not only might one assume that this function most likely is not simply one function (i.e., a single atomic functional entity of work) in temporary business situations and thus should be split out in multiple activities (as in the previous example). What is more, the activities related to carrying out a credit control (including things like checking the client risk, his payment history, etcetera) also look as depicting another concern than finalizing the delivery of a particular order (i.e., not financially or accounting related activities) which might evolve independently. Moreover, activities for this credit control might also turn out to be useful outside the flow of delivery processing, as is illustrated by the fact that the function is also employed in multiple processes. Based on this reasoning, one might conclude that the business processes “delivery processing” and “goods delivery processing” combine multiple concerns which should be properly separated according to NS theorems.

12

P. De Bruyn et al.

Third, as a consequence of not consistently isolating each concern in its own distinct business process, some of these concerns might spread out and become repeated in multiple processes. For example, referring back to Figure 2, a sequence of no less than 12 functions and 27 events as part of this process is literally replicated in the process “Automatic customer payment” [15, p. 595–584]. While it could be considered reasonable to assume that both concerns might be depicted as separate business processes as they might have their own specificities and change drivers, the duplicate part of the process (which actually seems to refer to specifying certain payment details, a process probably identically repeated regardless of the beneficiary and payee) should be isolated. In that way, changes in this payment details specification procedure could be limited to only this process. Consequently, the other processes would be change resistant with regard to the changes as they only should be performed once (instead of twice or more). Hence, while the previous example only consisted of a single SAP function, which we consider to denote multiple tasks, this example illustrates very clearly the redundant nature of functionality if a separate concern is not isolated in its dedicated business process. Referring to NS theory itself, the duplication as occurring in the reference model results (1) in a combinatorial effect as the impact of a change in the payment details specification procedure would be related to the size of the overall system and (2) uncertainty regarding where exactly to perform the changes as the specific spots are not “indexed”. Hence, white-box inspection of every possible process in the repository is required to be fully sure that all necessary adaptations are performed. This example can, first, be seen as a manifestation of the issue earlier cited and raised by Ekanayake et al. [35] and Uba et al. [36] in the sense that the SAP Reference Model contains some duplicate and redundant content, highlighting the difficulties for maintaining consistency among the duplicates in terms of version management. Next, this phenomenon reveals that the considered reference model does not have the tendency to analyze the business processes in a constructional way, but rather decomposes them from a functional perspective. The latter refers to the perspective in which the external behavior of a system is described (i.e., its function), while the former focuses on the structure, composition and operation of system (i.e., how is the function brought about?) [38]. However, as explained previously in [30], NS rationale would require to first decompose complex functional requirements into more basic requirements and only then consider the transformation of these basic requirements into constructional business process patterns. These constructional business process patterns could then serve as a kind of primitives or building blocks for composing the actual business processes realizing the functional requirements as the primitives are “called” and instantiated.

5 Conclusion In this paper, we investigated the feasibility of applying NS theory implications to enterprise process reference models by analyzing excerpts of the well-known SAP Reference Model. While the interpretation of business processes as flows

Applying NS theory implications to Enterprise Process Reference Models

13

consisting of states and functions and the partial reflection of the proposed guidelines in [13] show some conformance towards NS, also some examples of indications towards violations (both on the level of tasks and processes) in relation to NS were illustrated. While doing so this paper, first, contributes to the challenging issue of evaluating reference models by demonstrating the usefulness of NS for this purpose in the context of evolvability. Second, this paper also contributes to the validation of the findings in [13] on an extensive large-scale enterprise model (in terms of EPCs) and shows that the principles (initially illustrated in BPMN) can be applied irrespective of the notation language. Third, the paper also contributes to the quest for organizational constructional business process patterns as a next step in the NS research stream [12] by partially evaluating the suitability of a well-known reference model in this respect. Regarding the limitations of this paper, we should stress again that our analysis and identification of concerns to be separated depends on the context, time and subjective interpretation [13] in the sense that some concerns might not be valid for every single enterprise and context. Next, our analysis is both partial and tentative as we only focused our attention on a small portion of one process reference model. Hence, in order to ultimately identify more context-independent organizational patterns, a complete analysis of both the SAP and other available largescale reference models should preferably be aimed for in the scope of future research. Also, this analysis was aimed at examples from the SAP Reference Model used for documenting the usage and configuration of some of their modules and not necessarily for their software development. Hence, as as we have no information on the mapping between the SAP Reference Model and any SAP software, this paper obviously makes no single claim, statement or judgment with regard the SAP software itself in any way. This paper merely suggests that, if software is or will be built based on a one-to-one mapping of these reference models to the software level, NS theory would suggest the abovementioned indications of violations. This conclusion is similar to those mentioned in [13], which indicated that BPMN models in several case studies derived from industry practice contained similar violations. Finally, our identification of concerns based on NS theory primarily focuses on evolvability issues and it is deemed conceivable that other perspectives may call for other ways to structure business processes.

Acknowledgment P.D.B. is supported by a Research Grant of the Agency for Innovation by Science and Technology in Flanders (IWT).

References 1. Satzinger, J., Jackson, R., Burd, S.: Systems analysis and design in a changing world. 5th edn. Course Technology (2009)

14

P. De Bruyn et al.

2. Wand, Y., Weber, R.: Research commentary: Information systems and conceptual modeling — a research agenda. Information Systems Research 13(4) (2002) 363– 376 3. Moody, D.L.: Metrics for evaluating the quality of entity relationship models. In Ling, T.W., Ram, S., Li Lee, M., eds.: Conceptual Modeling - ER 98. Volume 1507 of Lecture Notes in Computer Science. Springer Berlin / Heidelberg (1998) 211–225 ¨ 4. Jacobson, I., Christerson, M., Jonsson, P., Overgaard, G.: Object-oriented software engineering: a use case driven approach. Addison Wesley (1992) 5. Fischer, G., Redmiles, C.F., Williams, L., Puhr, G.I., Aoki, A., Nakakoji, K.: Beyond object-oriented technology: where current approaches fall short. HumanComputer Interaction 10 (1995) 79–119 6. Fettke, P., Loos, P.: Perspectives on Reference Modeling. In: Reference Modeling for Business Systems Analysis. Idea Group Publishing (2007) 1–21 7. Frank, U.: Evaluation of Reference Models. In: Reference Modeling for Business Systems Analysis. Idea Group Publishing (2007) 118–140 8. Mannaert, H., Verelst, J.: Normalized systems: re-creating information technology based on laws for software evolvability. Koppa (2009) 9. Mannaert, H., Verelst, J., Ven, K.: Towards evolvable software architectures based on systems theoretic stability. Software: Practice and Experience 42 (2011) 89–116 10. Mannaert, H., Verelst, J., Ven, K.: The transformation of requirements into software primitives: Studying evolvability based on systems theoretic stability. Science of Computer Programming 76(12) (2011) 1210 – 1222 Special Issue on Software Evolution, Adaptability and Variability. 11. De Bruyn, P., Mannaert, H.: Towards applying normalized systems concepts to modularity and the systems engineering process. In: Proceedings of the Seventh International Conference on Systems (ICONS) 2012. (2012) in press. 12. De Bruyn, P.: Towards designing enterprises for evolvability based on fundamental engineering concepts. In Meersman, R., Dillon, T.S., Herrero, P., eds.: OTM Workshops. Volume 7046 of Lecture Notes in Computer Science., Springer (2011) 11–20 13. Van Nuffel, D.: Towards Designing Modular and Evolvable Business Processes. PhD thesis, University of Antwerp (2011) 14. Huysmans, P.: On the Feasibility of Normalized Enterprises: Applying Normalized Systems Theory to the High-Level Design of Enterprises. PhD thesis, University of Antwerp (2011) 15. Keller, G., Teufel, T.: SAP R/3 Process Oriented Implementation. Addison Wesley Longman (1998) 16. Curran, T., Keller, G., Ladd, A.: SAP R/3 Business Blueprint: Understanding the Business Process Reference Model. Prentice Hall PTR (1997) 17. Coplien, J.: The culture of patterns. Computer Science and Information Systems 1(2) (2004) 1–26 18. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley Professional (1994) 19. Hay, D.C.: Data Model Patterns: Conventions of Thought. Dorset House (1996) 20. Fowler, M.: Analysis Patterns: Reusable Object Models. Addison Wesley Professional (1996) 21. Scheer, A.: Business Process Engineering – Reference Models for Industrial Enterprises. Springer-Verlag (1998) 22. Silverston, L.: The Data Model Resource Book v.1 : A Library of Universal Data Models for All Enterprises: Vol 1. John Wiley & Sons (2001)

Applying NS theory implications to Enterprise Process Reference Models

15

23. McCarthy, W.E.: The rea accounting model: A generalized framework for accounting systems in a shared data environment. The Accounting Review 57(3) (1982) 554–578 24. Dietz, J.: Enterprise Ontology. Springer-Verlag (2006) 25. Kodaganallur, V., Shim, S.: Analysis patterns: A taxonomy and its implications. Information Systems Management 23(3) (2006) 52–61 26. Fettke, P., Loos, P.: Multiperspective evaluation of reference models – towards a framework. In Jeusfeld, M., Pastor, O., eds.: Conceptual Modeling for Novel Application Domains. Volume 2814 of Lecture Notes in Computer Science. Springer Berlin / Heidelberg (2003) 80–91 10.1007/978-3-540-39597-3 9. 27. Mannaert, H., De Bruyn, P., Verelst, J.: Exploring entropy in software systems: Towards a precise definition and design rules. In: Proceedings of the Seventh International Conference on Systems (ICONS) 2012. (2012) 28. Malone, T., Crowston, K., Lee, J., Pentland, B., Dellarocas, C., Wyner, G., Quimby, K., Osborn, C., Bernstein, A., Herman, G., Klein, M., O’Donnell, E.: Tools for inveting organizations: Toward a handbook of organizational processes. Management Science 45(3) (1999) 425–443 29. Malone, T., Crowston, K., Herman, G.: Organizing Business Knowledge: The MIT Process Handbook. The MIT Press (2003) 30. De Bruyn, P., Van Nuffel, D., Huysmans, P., Mannaert, H.: Towards functional and constructional perspectives on business process patterns. In: Proceedings of the Sixth International Conference on Software Engineering Advances (ICSEA) 2011. (2011) 459–464 31. Vanhoof, E., De Bruyn, P., Aerts, W., Verelst, J.: Comparing the usefulness of the REA model and normalized systems theory for accounting information systems design. Unpublished working paper 32. Geerts, G., McCarthy, W.E.: Using object templates from the rea accounting model to engineer business processes and tasks. The Review of Business Information Systems 5(4) (2001) 89–108 33. Mendling, J., Verbeek, H., van Dongen, B., van der Aalst, W., Neumann, G.: Detection and prediction of errors in epcs of the sap reference model. Data & Knowledge Engineering 64(1) (2008) 312 – 329 34. Rosemann, M., van der Aalst, W.M.P.: A configurable reference modelling language. Information Systems 32 (March 2007) 1–23 35. Ekanayake, C.C., Rosa, M.L., ter Hofstede, A.H.M., Fauvet, M.C.: Fragment-based version management for repositories of business process models. In Meersman, R., Dillon, T.S., Herrero, P., Kumar, A., Reichert, M., Qing, L., Ooi, B.C., Damiani, E., Schmidt, D.C., White, J., Hauswirth, M., Hitzler, P., Mohania, M.K., eds.: OTM Conferences (1). Volume 7044 of Lecture Notes in Computer Science., Springer (2011) 20–37 36. Uba, R., Dumas, M., Garc´ıa-Ba˜ nuelos, L., La Rosa, M.: Clone detection in repositories of business process models. In Rinderle-Ma, S., Toumani, F., Wolf, K., eds.: Business Process Management. Volume 6896 of Lecture Notes in Computer Science. Springer Berlin / Heidelberg (2011) 248–264 10.1007/978-3-642-23059-2 20. 37. Mannaert, H., Verelst, J., Ven, K.: Software architectures based on principles and patterns. International journal of software architecture 1(1) (2010) 17–18 38. Weinberg, G.M.: An Introduction to General Systems Thinking. Wiley (1975)