Lecture Notes in Business Information Processing 110

Series Editors Wil van der Aalst Eindhoven Technical University, The Netherlands John Mylopoulos University of Trento, Italy Michael Rosemann Queensland University of Technology, Brisbane, Qld, Australia Michael J. Shaw University of Illinois, Urbana-Champaign, IL, USA Clemens Szyperski Microsoft Research, Redmond, WA, USA Antonia Albani David Aveiro Joseph Barjis (Eds.)

Advances in Enterprise EngineeringVI

Second Enterprise Engineering Working Conference, EEWC 2012 Delft, The Netherlands, May 7-8, 2012 Proceedings

13 Volume Editors

Antonia Albani University of St. Gallen St. Gallen, Switzerland E-mail: [email protected]

David Aveiro University of Madeira Funchal, Portugal E-mail: [email protected]

Joseph Barjis Delft University of Technology Delft, The Netherlands E-mail: [email protected]

ISSN 1865-1348 e-ISSN 1865-1356 ISBN 978-3-642-29902-5 e-ISBN 978-3-642-29903-2 DOI 10.1007/978-3-642-29903-2 Springer Heidelberg Dordrecht London New York

Library of Congress Control Number: 2012936119

ACM Computing Classification (1998): J.1, H.3.5, H.4-5

© Springer-Verlag Berlin Heidelberg 2012 This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com) Preface

Enterprise engineering is an emerging discipline that studies enterprises from an engineering perspective. It means that enterprises are considered to be de- signed and implemented systems, which consequently can be re-designed and re-implemented if there is a need for change. Enterprise engineering is rooted in both the organizational sciences and the information system sciences. The rigor- ous integration of these traditionally disjoint scientific areas has become possible after the recognition that communication is a form of action. The operating prin- ciple of organizations is that actors enter into and comply with commitments, and in doing so bring about the business services of the enterprise. This impor- tant insight clarifies the view that enterprises belong to the category of social systems, i.e., its active elements (actors) are social individuals (human beings). The unifying role of human beings makes it possible to address problems in a holistic way, to achieve unity and integration in bringing about any organiza- tional change. Also when regarding the implementation of organizations by means of modern information and communication technology (ICT), enterprise engineering offers innovative ideas. In a similar way as the ontological model of an organization is based on atomic elements (namely, communicative acts), there is an ontological model for ICT applications. Such a model is based on a small set of atomic elements, such as data elements and action elements. By constructing software in this way, the combinatorial effects (i.e., the increasing effort it takes in the course of time to bring about a particular change) in software engineering can be avoided. The development of enterprise engineering requires the active involvement of a variety of research institutes and a tight collaboration between them. This is achieved by a continuously expanding network of universities and other insti- tutes, called the CIAO! Network (www.ciaonetwork.org). Since 2005 this network has organized the annual CIAO! Workshop, and since 2008 its proceedings have been published as Advances in Enterprise Engineering in the Springer LNBIP series. From 2011 on, this workshop was replaced by the Enterprise Engineering Working Conference (EEWC). This book contains the proceedings of the second EEWC, which was held in Delft, The Netherlands.

May 2012 Antonia Albani David Aveiro Joseph Barjis Enterprise Engineering – The Manifesto

Introduction

This manifesto presents the focal topics and objectives of the emerging discipline of enterprise engineering, as it is currently theorized and developed within the CIAO! Network. There is close cooperation between the CIAO! Net- work (www.ciaonetwork.org) and the Enterprise Engineering Institute (www.ee- institute.com) for promoting the practical application of enterprise engineering. The manifesto comprises seven postulates, which collectively constitute the en- terprise engineering paradigm (EEP). Motivation

The vast majority of strategic initiatives fail, meaning that enterprises are un- able to gain success from their strategy. Abundant research indicates that the key reason for strategic failures is the lack of coherence and consistency among the various components of an enterprise. At the same time, the need to operate as a unified and integrated whole is becoming increasingly important. These chal- lenges are dominantly addressed from a functional or managerial perspective, as advocated by management and organization science. Such knowledge is neces- sary and sufficient for managing an enterprise, but it is inadequate for bringing about changes. To do that, one needs to take a constructional or engineering perspective. Both organizations and software systems are complex and prone to entropy. This means that in the course of time, the costs of bringing about similar changes increase in a way that is known as combinatorial explosion. Re- garding (automated) information systems, this has been demonstrated; regard- ing organizations, it is still a conjecture. Entropy can be reduced and managed effectively through modular design based on atomic elements. The people in an enterprise are collectively responsible for the operation (including management) of the enterprise. In addition, they are collectively responsible for the evolution of the enterprise (adapting to needs for change). These responsibilities can only be borne if one has appropriate knowledge of the enterprise. Mission

Addressing the challenges mentioned above requires a paradigm shift. It is the mission of the discipline of enterprise engineering to develop new, appropriate theories, models, methods, and other artifacts for the analysis, design, imple- mentation, and governance of enterprises by combining (relevant parts of) man- agement and organization science, information systems science, and computer science. The ambition is to address (all) traditional topics in said disciplines from the enterprise engineering paradigm. The result of our efforts should be theoretically rigorous and practically relevant. VIII Enterprise Engineering – The Manifesto

Postulates

Postulate 1 In order to perform optimally and to implement changes successfully, enterprises must operate as a unified and integrated whole. Unity and integration can only be achieved through deliberate enterprise development (comprising design, engi- neering, and implementation) and governance. Postulate 2 Enterprises are essentially social systems, of which the elements are human be- ings in their role of social individuals, bestowed with appropriate authority and bearing the corresponding responsibility.Theoperating principle of enterprises is that these human beings enter into and comply with commitments regarding the products (services) that they create (deliver). Commitments are the results of coordination acts, which occur in universal patterns, called transactions. Note. Human beings may be supported by technical artifacts of all kinds, notably by ICT systems. Therefore, enterprises are often referred to as socio- technical systems. However, only human beings are responsible and accountable for what the supporting technical artifacts do. Postulate 3 There are two distinct perspectives on enterprises (as on all systems): func- tion and construction. All other perspectives are a subdivision of one of these. Accordingly, there are two distinct kinds of models: black-box models and white- box models. White-box models are objective; they regard the construction of a system. Black-box models are subjective; they regard a function of a system. Function is not a system property but a relationship between the system and some stakeholder(s). Both perspectives are needed for developing enterprises. Note. For convenience sake, we talk about the business of an enterprise when taking the function perspective of the customer, and about its organization when taking the construction perspective. Postulate 4 In order to manage the complexity of a system (and to reduce and manage its entropy), one must start the constructional design of the system with its ontolog- ical model. This is a fully implementation-independent model of the construction and the operation of the system. Moreover, an ontological model has a modular structure and its elements are (ontologically) atomic. For enterprises the meta- model of such models is called enterprise ontology. For information systems the meta-model is called information system ontology. Note. At any moment in the lifetime of a system, there is only one ontological model, capturing its actual construction, though abstracted from its implemen- tation. The ontological model of a system is comprehensive and concise, and extremely stable. Enterprise Engineering – The Manifesto IX

Postulate 5 It is an ethical necessity for bestowing authorities on the people in an enterprise, and having them bear the corresponding responsibility, that these people are able to internalize the (relevant parts of the) ontological model of the enterprise, and to constantly validate the correspondence of the model with the operational reality. Note. It is a duty of enterprise engineers to provide the means to the people in an enterprise to internalize its ontological model. Postulate 6 To ensure that an enterprise operates in compliance with its strategic concerns, these concerns must be transformed into generic functional and constructional normative principles, which guide the (re-)development of the enterprise, in ad- dition to the applicable specific requirements. A coherent, consistent, and hi- erarchically ordered set of such principles for a particular class of systems is called an architecture. The collective architectures of an enterprise are called its enterprise architecture. Note. The term “architecture” is often used (also) for a model that is the outcome of a design process, during which some architecture is applied. We do not recommend this homonymous use of the word. Postulate 7 For achieving and maintaining unity and integration in the (re-)development and operation of an enterprise, organizational measures are needed, collectively called governance.Theorganizational competence to take and apply these measures on a continuous basis is called enterprise governance.

May 2012 Jan L.G. Dietz Organization

EEWC 2012 was the second Working Conference resulting from a series of suc- cessful CIAO! Workshops over the years and EEWC 2011. These events aimed at addressing the challenges that modern and complex enterprises are facing in a rapidly changing world. The participants in these events share the belief that dealing with these challenges requires rigorous and scientific solutions, focusing on the design and engineering of enterprises. This conviction led to the idea of annually organizing an international work- ing conference on the topic of enterprise engineering, in order to bring together all stakeholders interested in making enterprise engineering a reality. This means that not only scientists are invited, but also practitioners. Next, it also means that the conference is aimed at active participation, discussion, and exchange of ideas in order to stimulate future cooperation among the participants. This makes EEWC a working conference contributing to the further development of enterprise engineering as a mature discipline. The organization of EEWC 2012 and the peer review of the contributions to EEWC 2012 were accomplished by an outstanding international team of ex- perts in the fields of enterprise engineering. The following is the organizational structure of EEWC 2012.

General Chair Jan L.G. Dietz Delft University of Technology, The Netherlands

Conference Chair

Antonia Albani University of St. Gallen, Switzerland

Program Chair

David Aveiro University of Madeira, Portugal

Organization Chair

Joseph Barjis Delft University of Technology, The Netherlands XII Organization

Program Commitee

Bernhard Bauer University of Augsburg, Germany Christian Huemer Vienna University of Technology, Austria Dai Senoo Tokyo Institute of Technology, Japan Eduard Babkin Higher School of Economics, Nizhny Novgorod, Russia Emmanuel Hostria Rockwell Automation, USA Eric Dubois Public Research Centre - Henri Tudor, Luxembourg Erik Proper Public Research Centre - Henri Tudor, Luxembourg Florian Matthes Technical University Munich, Germany Gil Regev Ecole´ Polytechnique F´ed´erale de Lausanne (EPFL), Itecor, Switzerland Graham McLeod University of Cape Town, South Africa Hans Mulder University of Antwerp, Belgium Jan Hoogervorst Sogeti Netherlands, The Netherlands Jan Verelst University of Antwerp, Belgium Joaquim Filipe School of Technology of Set´ubal, Portugal Jos´e Tribolet INESC and Technical University of Lisbon, Portugal Junichi Iijima Tokyo Institute of Technology, Japan Marielba Zacarias University of Algarve, Portugal Martin Op ’t Land Capgemini, The Netherlands Natalia Aseeva Higher School of Economics, Nizhny Novgorod, Russia Olga Khvostova Higher School of Economics, Nizhny Novgorod, Russia Paul Johanesson Stockholm University, Sweden Peter Loos University of Saarland, Germany Pnina Soffer MIS department, Haifa University, Israel Robert Lagerstr¨om KTH - Royal Institute of Technology, Sweden Robert Winter University of St. Gallen, Switzerland Rony Flatscher Vienna University of Economics and Business Administration, Austria Sanetake Nagayoshi Tokyo Institute of Technology, Japan Stijn Hoppenbrouwers Radboud University Nijmegen, The Netherlands Table of Contents

Foundations of Enterprise Engineering

Strengthening the Foundations Underlying the Enterprise Engineering Manifesto ...... 1 Martin Op ’t Land and Jo˜ao Pombinho

The Principles of Enterprise Engineering ...... 15 Jan L.G. Dietz and Jan A.P. Hoogervorst

Towards Applying Normalized Systems Theory Implications to Enterprise Process Reference Models ...... 31 Peter De Bruyn, Dieter Van Nuffel, Jan Verelst, and Herwig Mannaert

Enterprise Control, Flexibility and Governance

Enterprise Dynamic Systems Control Enforcement of Run-Time Business Transactions ...... 46 S´ergio Guerreiro, Andr´e Vasconcelos, and Jos´eTribolet

A Study of the Patterns for Reducing Exceptions and Improving Business Process Flexibility ...... 61 Sanetake Nagayoshi, Yang Liu, and Junichi Iijima

Benefits of Enterprise Ontology in Governing Complex Enterprise Transformations ...... 77 Martin Op ’t Land and Jan L.G. Dietz

Specifying Value

Towards Objective Business Modeling in Enterprise Engineering – Defining Function, Value and Purpose ...... 93 Jo˜ao Pombinho, David Aveiro, and Jos´eTribolet

Monitoring Value Webs ...... 108 Patr´ıcio de Alencar Silva and Hans Weigand

Author Index ...... 125 Strengthening the Foundations Underlying the Enterprise Engineering Manifesto

Martin Op ’t Land1,2 and João Pombinho3,4

1 Capgemini Netherlands, P.O. Box 2575, 3500 GN Utrecht, The Netherlands 2 Delft University of Technology, Delft, The Netherlands 3 Instituto Superior Técnico, Technical University of Lisbon, Lisbon, Portugal 4 CODE - Center for Organizational Design & Engineering, INESC INOV, Rua Alves Redol 9, Lisbon, Portugal [email protected], [email protected]

Abstract. The discipline of Enterprise Engineering aims for enterprises to oper- ate as a unified and integrated whole. This discipline therefore adopts the mis- sion to develop theories, models, methods and other artifacts for the analysis, design, implementation and governance of enterprises in a theoretically rigor- ous and practically relevant manner. The Enterprise Engineering Manifesto postulates the dualities of concepts function/construction perspective, black- box/white-box models and subjective/objective as being opposed to each other in one-on-one relationships. Illustrated by the Pizzeria case, it becomes clear (a) that functions can be de- fined objectively, and (b) that a valuation perspective should be added that truly focuses on the relationship between a system and its stakeholders. These insights can support building stronger bridges between management and organ- ization sciences – traditionally stronger in functional approaches – and information systems science, and computer science – traditionally stronger in constructional approaches.

Keywords: Enterprise Engineering, Enterprise Engineering Manifesto, Func- tion perspective, Construction perspective, Black-box models, White-box models.

1 Introduction

According to the Enterprise1 Engineering Manifesto (EEM)[1], Enterprise Engineer- ing is an emerging discipline that deals with developing theories, models, methods and other artifacts for the analysis, design, implementation and governance of enter- prises in a theoretically rigorous and practically relevant manner. Since this goal encompasses different domains of knowledge, enterprise engineering is itself a multi- disciplinary discipline that combines concepts from management and organization science, information systems science, and computer science. One of the challenges

1 We use the term “enterprise” for any goal-oriented cooperative of people.

A. Albani, D. Aveiro, and J. Barjis (Eds.): EEWC 2012, LNBIP 110, pp. 1–14, 2012. © Springer-Verlag Berlin Heidelberg 2012 2 M. Op ’t Land and J. Pombinho that arise from this approach is being able to coherently and consistently combine the various components of an enterprise, while coping with the adaption and change con- cerns that inherently will arise over time. Indeed, the complexity of businesses and the high change pace of their environments, coupled with increasing ICT support, turn the gap between strategy and its implementation into a major challenge. Studies indicate as much as 90 percent of organizations fail to succeed in applying their strategies [2]. The EEM [1] states that management and organization sciences address these is- sues predominantly from a functional perspective. Conversely, information systems science and computer science mainly make use of the constructional or engineering perspective. The EEM then focuses on the contributions of constructional thinking to the Enterprise Engineering (EE) discipline. Particularly, its Postulate 3 reads: “There are two distinct perspectives on enterprises (as on all systems): function and construction. All other perspectives are a subdivision of one of these. Accordingly, there are two distinct kinds of models: black-box models and white-box models. White-box models are objective; they regard the construction of a system. Black- box models are subjective; they regard a function of a system. Function is not a system property but a relationship between the system and some stakeholder(s). Both perspectives are needed for developing enterprises.” Three dualities of concepts are mentioned, and set in one-to-one relationships: • Function and Construction perspectives; • Black-box and White-box models; • Subjectivity and Objectivity. We agree with EEM that these concepts have a very important role as a referential for the entire EE discipline. Therefore it would be beneficial to clarify their definitions and relations, to not only distinguish these notions, but also be able to connect them. Suppose, for instance, that it would be possible to define functions (more) objectively, then it would be possible to simulate, test and maybe even prove coherence, sufficien- cy, etc. of a certain construction and implementation to bring about certain functions. This would contribute to a core value of Enterprise Engineering, namely unified and holistic design, truly combining management and engineering disciplines. The remainder of this paper is structured as follows. Section 2 begins with a brief Problem Statement, and the introduction of the running Pizzeria example for our con- ceptual exploration. Then Section 3 presents the three mentioned dualities of con- cepts, instantiated with the Pizzeria example. Next, the three dualities are discussed and compared in Section 4. The paper closes with conclusions and recommendations regarding Enterprise Engineering in general, and regarding the EEM specifically.

2 Problem Statement

The main question we want to answer is: “Looking at the three dualities of concepts – function versus construction perspec- tive, black-box versus white box models, and subjectivity versus objectivity – are these three dualities of concepts really one-on-one?” Strengthening the Foundations Underlying the Enterprise Engineering Manifesto 3

As a first illustration, look at the work of a sluice operator. Without knowing his work instructions (white-box), we can observe his behavior (black-box) and compare that with expected behavior in parameters well known in product and reliability engi- neering, such as service times, delivery times, Mean Time Between Failure and error rates. Such Quality of Service (QoS) parameters can be expressed and also measured quite objectively – which is a regular practice in Service Level Management, and also the basis for Service Level Agreements (SLA’s). So there seems not necessarily to be a problem to define functions objectively. Comparable examples can be found in the Six Sigma, which uses black-box obser- vations to systematically search for statistical correlations – which could point to causality in (until now may be unknown) white boxes. Also here functional parame- ters are defined and measured objectively. Yet another example is given by Dietz [3], looking at the heart as a biological sys- tem. The heart has the function of pumping blood, i.e. transporting blood from loca- tion A to location B with a certain velocity range and a certain capacity for adapting to fluctuations in viscosity. This function can be expressed objectively and measura- bly. Dietz then continues to clearly distinguish between function and purpose, where “purpose is a relationship of a system with its stakeholder”. May be that is more a place where subjectivity could be expected, since the interests of me in my heart could well differ from those of the heart surgeon, or those of the poor colleague pa- tient waiting for a heart transplant. We want to approach this –rather conceptual– question with the strategy “valida- tion by instantiation”. To instantiate the three dualities of concepts in the next sec- tions, we will use the following adapted version of the classic Pizzeria example from [4], familiar to the EE community.

Pizzeria Case. The Pizzeria is a business organization that provides pizza to its cus- tomers (1,000 pizzas of at least 95ºC a week with a Mean Time Between Failure of one month). Besides the customers, there are many stakeholders: the investors, the city who grants licenses in return for license fee and the employees working in the pizzeria. It is noteworthy that the customers belong to two distinct segments: regular end-customers and cafés located in luxurious terraces nearby, which complement the offer to their customers with excellent fresh pizza. In an earlier version of the Pizzeria organization, customers could just walk in and make their wishes known at the counter or could order by telephone. In both cases they had to take away the pizzas themselves. Later, an important new service was introduced: one could have the pizzas delivered to an address. Both means of pizza delivery to the customer co-exist today. Customers announce themselves at the counter of the pizzeria or make a telephone call. After making her selection from a menu, the customer is informed about the price and the expected time that the order will be ready. The order is then passed to the kitchen, where the baker prepares the pizzas. Once ready, the pizzas that make up an order are boxed. Depending on the delivery selec- tion, the boxes are then handed over to the customer against payment or delivered a customer-specified address by a transporter, whom also collects the money on behalf of the pizzeria. 4 M. Op ’t Land and J. Pombinho

Fig. 1. Detailed Actor Transaction Diagram (according to DEMO) from the Pizzeria [3]

3 Analysis of the Dualities of Concepts

First we will introduce the Enterprise Engineering concepts of system, model and Generic System Development Process (GSDP). Then we will present each duality and instantiate it with the Pizzeria example.

3.1 Base Theory: System, Model and GSDP

System and Model. Dietz [3] defines something as a system if and only if it has: composition – a set of elements of some category (grey nodes in Fig. 2); environment – a set of elements of the same category, disjoint from the composition (white nodes); production – things produced by elements in the composition and delivered to the environment; structure – a set of influence bonds among the elements in the composi- tion, and between them and the elements in the environment (connections between white and grey nodes). Together, these properties are called the construction of a system.

Fig. 2. The construction of a System [3]

Apostel [5] defines the concept of model of a system is as a role as follows: “Any subject using a system A that is neither directly nor indirectly interacting with a system B, to obtain information about the system B, is using A as a model for B.” Strengthening the Foundations Underlying the Enterprise Engineering Manifesto 5

General System Development Process. In every design process there are two sys- tems involved, the using system (US) and the object system (OS), as depicted in Fig. 3. The OS is the system to be designed; the US is the system that will use the functions or services offered by the OS once it is operational.

architecture

functional constructional principles principles

using system object system construction construction

object function construction ontology system ontology design design function

engineering

reverse engineering reverse design

implem- entation analysis synthesis implem- entation

technology technology

Fig. 3. Generic System Development Process [6]

Function design, the first phase in the design of the OS, starts from the construc- tion of the US and ends with the function of the OS. Function design delivers the requirements of the OS, so a black-box model of the OS. This black-box model clari- fies the behavior of the OS in terms of (functional) relationships between input and output of the OS. This function model of the OS does not contain any information about the construction of the OS. Construction design, the second phase in the design of the OS, starts with the specified function of the OS and it ends with the construc- tion of the OS. Construction design bridges the mental gap between function and construction, which means establishing a correspondence between systems of differ- ent categories: the category of the US (where the function of the OS is defined) and the category of the OS. Construction design delivers an ontology, the highest level white-box model of the OS. This white-box model clarifies the internal construction and operation of the system in terms of collaboration between its elements to deliver products to its environment. By an ontology or ontological model of a system we understand a model of its construction that is completely independent of the way in which it is realized and implemented. The engineering of a system is the process in which a number of white-box models are produced, such that every model is fully

6 M. Op ’t Land and J. Pombinho derivable from the previous one and the available specifications. Engineering starts from the ontological model, produces a set of subsequently more detailed white-box models and ends with the implementation model. By implementation is understood the assignment of technological means to the elements in the implementation model, so that the system can be put into operation. By technology we understand the tech- nological means by which a system is implemented. A wide range of technological means is available, including human beings and organizational entities, ICT artifacts (e.g., phone, email, computer programs) and mechanical means. In general, the design freedom of designers is undesirable large. Dietz and Hoogervorst [6] therefore define architecture (1) conceptually as a normative restriction of design freedom and (2) operationally as a consistent and coherent set of design principles that embody gener- al requirements, where these general requirements hold for a class of systems. Those principles can be functional or constructional, i.e. restricting the function resp. the construction design of a system.

3.2 Objectivity and Subjectivity The notions of objectivity and subjectivity motivate a long ranging philosophical debate where the quest for truth has a main role. A proposition is considered objectively true when its truth conditions are met and are not dependent on the mind of the observer. Objectivism, in this context, is an al- ternative name for realism, the view that there is a mind-independent reality, which implies a definition of truth. Foundationalism, the notion that knowledge is built upon an unchangeable founda- tion, would be the only assurance that truth can be achieved. However, the notion that absolutely secure and final knowledge is attainable – the quest for absolute truth – was progressively regarded as unfruitful as, even if it is reachable, there does not seem to be a way of being certain about it [7]. Additionally, regarding scientific knowledge, the definition of objectivity states that descriptions of physical phenome- na must not change when the phenomena are observed by different observers, under different conditions. Kuhn [8] notably defended the impossibility of scientific under- standing being truly objective, due to the nature of scientific organization around community-bound paradigms. No smooth transactions occur between them, Kuhn observed, as a reigning paradigm would only give way to another after overwhelming evidence of unfitness was accepted by most of its supporting community – revolution, rather than evolution. These facts, illustrative of the towards objectivity, should not be met by considering that everything must then subjective, as these are related but dif- ferent matters – is a voyage, not a destination. The question is then, what obstacles exist on the way of objectivity? For instance, it seems clear that observations are more likely to be recognized as higher in objectiv- ity when they are simpler and closer to sensory experiences - thus, not so influenced by rational paradigms and viewpoints. This is a debatable point, since artificially comfortable notions such as sensatory experiences and unanimity in observations cannot be taken as necessarily objective – the fact that an audience agrees that a rabbit Strengthening the Foundations Underlying the Enterprise Engineering Manifesto 7 came out of a magician’s hat does not make in an objective truth. In this respect, dif- ferent types of objectivity exist - quantitative versus qualitative. We must also take care to differentiate group consensus as potentially illusory and not any better at pro- viding truth than other approaches, such as statistical observation or scientific inquiry. Even influenced by paradigms, efforts should be taken to remove that bias in favor of objective. Objectivity is a valued quality in goal-setting, for instance. The well known “SMART” criteria (Specific, Measurable, Attainable, Relevant, and Time- Based) [9], are a good example of striving for objectivity. The distinction between the process of inquiry for truth and its outcomes is also crucial. While no guarantee of absolute certainty on the results of the inquiries can be provided, the meeting of pro- cedural standards must be valued - making some types of inquiries comparatively better than others. Opening to challenge and scrutiny by a critical community is in- strumental in freeing from biases as concealed valuations. This is notion is crucial to Popper’s Critical rationalism [10], where the quest for continuous falsification follows from the need that a theory has to be falsifiable in order to be scientific. Concluding, objectiveness depends on the seriousness in the pursuit of criticism and refutation. Full objectivity is not attainable - it is, then, a relative measure of the effort to be objective. Therefore, there are no objective results recognizable as an undisputable truth, only a relatively objective way of working.

Example. In the Pizzeria case, a claim that a specific pizzeria’s pizza is the tastiest in town is highly subjective.

Explanation. The fact that different individuals can experience it at different times and in different personal contexts clearly discourages a quest for absolute truth. How- ever, a customer survey can be regarded as a means of increasing objectivity. For instance, its objectiveness can be increased if it is performed by an independent entity, rather than the pizzeria itself, and the criteria are known by all participants.

3.3 Function and Construction

The relation between function and construction is defined in [3] by positioning them in the context of a system development process – the Generic System Development Process (GSDP) as presented in section 3.1. Two notions of a system are clearly sepa- rated: the teleological, concerned with behavior and function, and ontological, con- cerned with the system’s construction and operation. Dietz claims[4] that functional models, typically used in disciplines such as man- agement and organizational science, are useful for the purpose of using or controlling a system and inadequate for bringing about changes. There seems to be an implicit implication that these models are fuzzy by nature and unapproachable from a formal perspective that is useful in enterprise engineering. Building on the previous sections, we argue this is not the case, and that functional models can be SMARTly (as explained in the previous section) and even formally defined.

8 M. Op ’t Land and J. Pombinho

As presented in the GSDP, a given construction is made to support a function. The function is, then, dependent on construction. According to a survey by Sprint [11], nearly two-thirds of the respondents appeared to have used the backlight of their mo- bile phones to look for something in the dark. If, for instance, a mobile phone inter- face is someday replaced by using brainwaves operation instead of hardware, their users will have to use other devices to look for keyholes.

Differentiating Function, Purpose and Value. The function is a characteristic of system and comparatively objective regarding purpose and value (see section on ob- jective/subjective). The first specifies the system’s relation with elements on its envi- ronment, in terms of inputs and outputs. The second, purpose, specifies what usage is given to the system’s function, from a specific external actor’s point of view. Value emerges from the relation: it is attributed to a system function by a stakeholder in regard to a specific purpose. Even so, it can be made less subjective and, therefore, relatively freed from bias, namely by 1) specifying the external actor itself in terms of function and construction, and 2) specifying alternative functions that can be used to the same purpose. As an example, the value that the Pizzeria pizza-for-money func- tion has for the caffé is compared against microwaving pre-baked pizzas, lacking freshness and overall quality, and resulting in less value transferable to the end- customer. As can be noted, the purpose definition process is recursive and results in the notion of purpose being tightly connected to the one of chain. The recursive no- tion of purpose just presented conceptually extends the basic relation of two elements to an arbitrary number and, in the process, building the purpose structure. The specifi- cation is out of this paper’s scope, but the point must be made that it is important to segregate purpose-oriented notions from function definitions as they have a different nature and positioning regarding a system and its environment.

Innovation. The relation between the concepts of function and construction is pre- scribed in the GSDP having construction as subordinate to function - this relation is a consequence of the development process. This follows from the sequence of the process and does not change by considering iteration, since the creative step of the process always happens from function to construction. This also hinders creative reuse of a construction (innovation) because the OS value is limited, by process de- sign, to satisfying the construction of a specific US. Most importantly, the conceptual direction of the process should be reversible; as an application take, for instance, the discovery of new functions for an existing construction.

Example. The way the elements in the Pizzeria construction, namely its delivery (sub) organization, were chosen supports the function of providing pizza to the physi- cal location of customer.

Explanation. It was a strategic decision by the Pizzeria owner to provide pizzas to a given customer location. Also note that the same construction allows providing Pizza

Strengthening the Foundations Underlying the Enterprise Engineering Manifesto 9 to both end-customers and business partners – although in this last case some optimi- zations could be made. It is even the case that the delivery function, by itself, could provide the service to the customers of the business partners – the collection and price visibility would be a little trickier with the current construction, though. Note that in the ontological model the customer types are not differentiated.

3.4 Black-Box and White-Box

The general notion of black-box is a metaphor for an abstraction that obscures the internal workings of a given system so that only output, as reaction to some specific input, is observable (left part of Fig. 4). For instance, that the pizzeria is offering 1,000 pizzas of at least 95ºC a week with a Mean Time Between Failure of one month. Conversely, the composition and structure of a white-box are available for inspection, allowing clarification of the transfer function of the system [12]. While the white-box perspective is embraced by engineering disciplines and objectiveness by need of constructability, the black-box perspective is frequently connected to subjec- tivity. As we will see, this is not necessarily the case.

Partiality versus Subjectivity. Distinguishing subjectivity from partiality is crucial to clarifying the (wrong) notion of necessary subjectivity of the black-box perspec- tive. The black-box of a system can be partial, in the sense it can represent a limited selection of inputs and outputs. However, these must be correspondent to each other, as in a function’s range and domain. Further, and most important, only black-boxes supported by the corresponding white-box are allowed, i.e., the black-box must be coherent with the white-box model.

Fig. 4. Pizzeria Black-Box model from a) Customer perspective; and b) Pizzeria perspective

In the example represented in Fig. 4, the Customer can legitimately assume a sim- plified model of the Pizzeria (a). But using a more complete model with additional stakeholders (b), one must wonder how independent those value exchanges are. In- deed, the holistic and unified approach as ascribed in the EEM must be built upon adequate theory for supporting multiple partial views in an integrated way – e pluri- bus unum.

Relativity. As with subjectivity and objectivity, presented in the previous section, the concept of relativity is also present regarding black-box and white-box perspectives of 10 M. Op ’t Land and J. Pombinho a system. Indeed, a given systems' white-box may be a black-box (or a set of black- boxes) in another referential of system types. This concept is distinct from a simple aggregation by enforcing the commitment to a specific referential. For instance, take the white-box model of a car, which still holds the chemical system of a battery as a black-box. Following the same reasoning, and having finer thresholds between system types, a given overall system model can be further refined into layers. These layers can be defined to model M-N relations between systems, e.g., the car can use both a battery, solar power and gas as energy providing (sub)systems. Therefore, they end up forming a layered solution path where the uppermost layers are dependent on the lower ones. For instance, this concept is clearly presented regarding DEMO’s B, I and D-organizations in [13].

Example. The customer black-box perspective of the Pizzeria is a system that outputs a pizza in exchange for money provided as input (see Fig. 4). From the investor’s black-box perspective, the Pizzeria is a system that outputs money (profit) in ex- change for input money (investment). From the employee’s perspective, the Pizzeria is a system that outputs a/o money (salary) in exchange for input “work”.

Explanation. Only elements from the environment and relations that cross the fron- tier with the composition are relevant from a black-box perspective. A black-box perspective corresponds to a functional vision of the system which, as we have seen, can be partial. However, we must note that the black-box from the Pizzeria’s perspec- tive is more than the sum of its parts, in this case more than an aggregation of the individual external perspectives. In this example, the monetary exchanges are not independent as they must be financially balanced.

4 Discussion

Regarding the three fundamental dualities analyzed in this paper: • Subjectivity/Objectivity is the one with a larger application scope as it is in- dependent of a specific research area; it is also the most generally applicable at the philosophical level; • Function/Construction and Black-box/White-box have one-on-one corres- pondence; however, they are orthogonal to the Subjectivity/Objectivity duality; moreover, their positioning in the objectivity range does not depend on their fundamental essence but on the effort to make them objective through concept analysis and modeling way of work. A point must be made regarding relativity and recursivity of their application: a sys- tem can be conceived as a series of chained conceptual solutions to problems - it can be argued they always are, at some point in the system’s lifecycle as a result from the creative process of problem solving/solution identification. Then, following the rela- tivity principle the black-boxes can indeed be opened to reveal white-boxes, which in turn will again be composed of black-boxes. Since a given construction does not Strengthening the Foundations Underlying the Enterprise Engineering Manifesto 11 support every function, and a particular function is not supported by every construc- tion, logic must be devisable for mutual modeling restriction, either from a positive or negative approach in terms of degrees of freedom. Coupled with the presented conclusions regarding objectivity, it can be concluded that a chaining of black-box and white-box systems ends with a black-box since there is no complete knowledge of the truth. For instance, take the human body as a set of systems, the muscular system, the molecular physical system and the atomic level of description. There is always a basic theory, which is the recursivity stopping point. A white-box model example such as the model of an atom is also a reference of why it is not necessarily objective; in this case, it is theory-bound. This unassertible objective- ness is also the reason that the concept of usefulness of a model, a very important notion in system design and engineering, must be introduced. In the atomic theory example, while there can be no claim that it corresponds to absolute truth, it has un- doubtedly contributed consistently to produce practical results in advancing humanity. In the same way, a theory regarding black-box specification in an integrated way with the construction must be regarded as useful and as sound as possible, provided that demonstrable efforts are made towards objectivity. A system’s construction or function alone is not directly relatable to the usage sce- narios it may have: a work of art can be used as a paper weight. Therefore, a different perspective that is subject-sensitive and includes concepts such as purpose, contribu- tion, value and goal is required. Let’s designate it, following [14], by valuation pers- pective. This perspective should 1) differentiate and formally define these concepts; 2) define the relations between them, and 3) define the direct interface with the func- tion perspective and, through it, the indirect interface with the construction perspective.

5 Conclusions and Recommendations

5.1 Conclusions We found the following weaknesses in the EEM, which we consider worthwhile to consider changing. Though the EEM says that both the function and the construction perspective are needed for developing enterprises, almost all attention goes to the added value of the construction perspective. Also it is said that the functional perspective “is inadequate for bringing about changes", while it is probably meant that the functional perspective is insufficient for bringing about changes. For the stage of the Manifesto as an activis- tic document, to correct common misunderstandings in Enterprise Engineering, this is not a big problem. However, to let the Manifesto grow into the direction of a solid foundation for the Enterprise Engineering discipline as a whole, the added value of the functional perspective should be made explicit as well. It is well possible to define functions of a system objectively and SMARTly. In areas such as mechanical engineering, that is common practice already. For example, by reflecting on the function of a vacuum bag – to trap dirt and let air through – and seeing that the industrial cyclone in a sawmill fulfills exactly the same function, 12 M. Op ’t Land and J. Pombinho

Dyson was able to innovate the vacuum cleaner [15].We admit that in the practice of enterprise engineering there is lots of room for improvement in defining (especially: business) functions. This is no reason however to say that it is inherently impossible to define functions objectively. The “subjectivity", ascribed by the EEM to the function perspective, seems more to belong to the relationship of a system to its stakeholders. Indeed its stakeholder will assess the meaning, contribution and value of a certain system, against his (business and/or personal) interests and goals in that system (its results, transition, implementa- tion or governance); one could call this subjective. It seems more adequate to explicit- ly address these aspects of a system in a separate perspective, named e.g. “purpose”, “contribution”, “goal” or, as suggested by Op ‘t Land et al [14], “valuation”. Using as a working definition for objective(ly) “A proposition is considered to be objectively true, when independent observers, using the same observation instruction, assert it", we can now conclude the following. In principle, both construction and function can be objectively asserted. For value, contribution and the like this is far more difficult, though not impossible. E.g., by interviewing a well chosen set of cus- tomers, one can turn the individual (subjective) customer satisfaction to a shared, inter-subjective notion of customer (or even market) satisfaction. We wonder however why the EEM introduces these – more epistemological – notions as a label überhaupt, since it uses this distinction nowhere else. Using as a working definition for a model “a goal-oriented abstraction from reali- ty", we can conclude the following. Each model will, by definition, be incomplete, since it consciously leaves out certain things from reality. Such – as said: inherent – partiality should not be equaled to subjectivity! So the fact that a functional model of a book generally does include something about the knowledge or the story captured, and not the potential energy delivered when burned (as shown in the 2004-movie “The Day After Tomorrow") does not make this functional model subjective, though it is incomplete. To assess whether a model is adequate, it should be assessed against its goals, e.g., understanding, steering or changing an enterprise.

5.2 Recommendations In the discipline of Enterprise Engineering, we propose to discern between a function perspective and a second perspective named, e.g., valuation perspective, as follows:

• a function of a system is defined as an association between a given input with exactly one output, possibly taking parameters into consideration; ─ this definition of function follows common and mathematical definitions; ─ one system may, and generally will, have more functions; ─ a function of a system is an inherent property of the system itself; ─ a commonly used metaphor or model of a function is a “machine" or “black box" that converts input into output; ─ from this it follows immediately that so-called non-functional requirements are part of a functional perspective as well because they can be described as black- box behavior of the system; Strengthening the Foundations Underlying the Enterprise Engineering Manifesto 13

• a valuation of a system is defined as the contribution of a function of a system for a certain stakeholder ─ this (positive or negative) contribution can differ per stakeholder, because of his specific (business and/or personal) interests and goals in that system; ─ one function can, and generally will, have more contributions; ─ the contribution of a function of a system to a stakeholder is a property of the re- lationship between the system and the stakeholder.

As a consequence, we propose to change the Enterprise Engineering Manifesto as follows.

• Under “Motivation”, change the statement on the value of functional knowledge to “Such (functional) knowledge is necessary and sufficient for managing an enter- prise, but it is inadequate insufficient for bringing about changes". • Split Postulate 3 in two parts 3a and 3b, in which 3a deals with the perspectives, and 3b with corresponding models. • Create Postulate 3a as follows: “There are two three distinct perspectives on enter- prises (as on all systems): construction, function and valuation. All other perspec- tives are a subdivision of one of these. Construction of a system deals with its operation, function deals with its behavior, and valuation with the contribution of that system for a stakeholder. Contrary to valuation, both function and construc- tion are inherent properties of a system. Both All three perspectives are needed for developing enterprises.” • Create Postulate 3b as follows: “The function perspective of a system needs to be modeled with black-box models. Also the other way around applies: a black-box model can only be used for the function perspective. The construction perspective of a system needs to be modeled with white-box models. And also here the other way around applies: a white-box model can only be used for the construction pers- pective, though logic can exist which derives the function from a certain construc- tion. Note. For convenience sake, we talk about the business of an enterprise when taking the function perspective of the customer, and about its organization when taking the construction perspective.”

Other recommendations for the Enterprise Engineering Manifesto are:

• consider leaving the notions subjective / objective out of the Manifesto altogether or elaborate it, introducing inter-subjectivity as well, distinguishing between onto- logical and epistemological notions, and explaining the purpose of this distinction in the Manifesto; • consider introducing explicitly the notion of model adequacy [16]; this will allow for evaluating models against its own stated goals; • describe the whole area of Enterprise Engineering, in which function, construction (both construction on an ontological level and construction on an implementation level) and the influence of context and goals, including the influence of principles are described in a balanced and coherent way; 14 M. Op ’t Land and J. Pombinho

• make clear the state of the art of the Enterprise Engineering discipline, giving the state of the art of the current contributing disciplines, such as management & or- ganization science, economics and traditional (e.g., mechanical, electrical, civil) engineering disciplines; • first clarify the underlying vision on the EEM; is it an activistic document to correct current organization science thinking with a discipline of constructional thinking on organizations, or is the claim to broadly describe the whole area of En- terprise Engineering; we recommend the latter, but at least it should be clear.

References

1. Dietz, J.L.G.: Enterprise Engineering Manifesto (2011), http://www.ciaonetwork.org/publications/EEManifesto.pdf (last vi- sited January 24, 2012) 2. Kaplan, R.S., Norton, D.P.: Strategy Maps: Converting Intangible Assets Into Tangible Outcomes. Harvard Business School Press, Boston (2004) 3. Dietz, J.L.G.: Architecture - Building strategy into design. Netherlands Architecture Fo- rum, Academic Service – SDU, The Hague, The Netherlands (2008) 4. Dietz, J.L.G.: Enterprise Ontology: Theory and Methodology. Springer (2006) 5. Apostel, L.: Towards the formal study of models in the non-formal sciences. Syn- these 12(2), 125–161 (1960) 6. Dietz, J.L.G., Hoogervorst, J.A.P.: Enterprise Ontology and Enterprise Architecture - how to let them evolve into effective complementary notions. GEAO Journal of Enterprise Ar- chitecture 1 (2007) 7. Phillips, D.C.: Subjectivity and objectivity: An objective inquiry. In: Peshkin, E.A. (ed.) Qualitative Inquiry in Education: The Continuing Debate, pp. 19–37. Teachers College Press, New York (1990) 8. Kuhn, T.S.: The Structure of Scientific Revolutions. University of Chicago Press, Chicago (1962) 9. Doran, G.T.: There’s a S.M.A.R.T. way to write management’s goals and objectives. Man- agement Review, 35–36 (1981) 10. Popper, K.R.: Objective Knowledge: An Evolutionary Approach, p. 392. Oxford Universi- ty Press, Oxford (1972) 11. Tsai, A.: Sprint Survey Reveals 56% of Phone Users Do More than Talk (2006), http://www.mobiledia.com/news/43052.html (last visited February 26, 2012) 12. Skyttner, L.: General Systems Theory: Problems, Perspectives, Practice, 2nd edn. World Scientific Publishing Co. Pte. Ltd., Singapore (2005) 13. Baarda, P.J.: Smart SOA - IT Foundations and Enterprise Relativity, Via Nova Architectu- ra (2011) 14. Op ’t Land, M., Proper, H., Waage, M., Cloo, J., Steghuis, C.: Enterprise Architecture – Creating Value by Informed Governance. The Enterprise Engineering. Springer, Berlin (2009) 15. Salustri, F.A.: Art Markman reinvents the wheel on innovation (2012), http://filsalustri.wordpress.com/2012/01/14/art-markman- reinvents-the-wheel-on-innovation/ (last visited January 21, 2012) 16. Reggiani, M.G., Marchetti, F.E.: On Assessing Model Adequacy. IEEE Transactions on Systems, Man and Cybernetics SMC-5(3), 322–330 (1975)

The Principles of Enterprise Engineering

Jan L.G. Dietz and Jan A.P. Hoogervorst

[email protected], [email protected]

Abstract. A century ago, Taylor published a landmark in the organizational sciences, his Principles of Scientific Management. Many researchers have ela- borated on Taylor’s principles, or have been influenced otherwise. The authors of the current paper evaluate a century of enterprise development, and conclude that a paradigm shift is needed for dealing adequately with the challenges mod- ern enterprises are facing. Three generic objectives are identified. First, em- ployee empowerment; modern employees are highly educated knowledge workers; yet, the mindset of managers has not evolved accordingly. Second, mastering complexity; current approaches fall short in mastering the complexity of enterprises and enterprise changes. Third, unity and integration; this can only be achieved by deliberate enterprise design. The emerging discipline of Enter- prise Engineering is able to achieve these objectives satisfyingly. It does so by providing new, powerful ideas and intellectual techniques, collected in the Prin- ciples of Enterprise Engineering.

Keywords: Scientific Management, Enterprise Engineering, Enterprise Gover- nance, Enterprise Ontology, Enterprise Architecture.

1 Introduction

A century ago, Frederic Winslow Taylor published his famous paper, titled "The Principles of Scientific Management" [1]. In the present paper we take the anniversary of Taylor’s seminal paper as an opportunity to look back at a century of theory and practice in enterprise1 development, to assess the current state, and to propose a radical new way of addressing current problems, under the name of ‘Enterprise Engineering’. Typical characteristics of the scientific management approach are the minute division of labor in simple, repetitive tasks, and the clear separation between thinking and doing. Workers are instrumentally viewed as parts of the enterprise ‘machine’. According to Taylor, a man fit to do the manual work is however unfit to understand the science of doing his work. Hence, managerial control is essential. Taylor’s pers- pective is supported by contemporary writers, such as Henri Fayol [2] and Max Weber [3].

1 With “enterprise” we refer to all kinds of organized activity (like companies, governmental agencies, health care institutions, and building projects).

A. Albani, D. Aveiro, and J. Barjis (Eds.): EEWC 2012, LNBIP 110, pp. 15–30, 2012. © Springer-Verlag Berlin Heidelberg 2012 16 J.L.G. Dietz and J.A.P. Hoogervorst

Over the years, scientific management has contributed to significant increases in the productivity of enterprises. Nonetheless, the approach has been heavily criticized. Basically, two kinds of criticisms can be identified. The first one regards ethical con- siderations concerning the deployment of human capacities in enterprises. Various researchers have argued that the principles of scientific management lead to worker deprivation and alienation, and to destroying the meaning of work itself [4, 5, 6]. These phenomena were already visible a few years after Taylor published his paper, when his principles were practiced in Ford car manufacturing: workers’ jobs were depleted of skill, autonomy and control, leading to extreme worker turnover rates [7]. Contenders of Taylor thus argue the importance of employee development, self- initiated behavior, and self-control. Considerations concerning the effectiveness and efficiency of enterprises constitute the second kind of criticism. Essentially, the critique boils down to two aspects. First, the notion that proper attention to employees as a social group can significantly en- hance enterprise effectiveness and efficiency, as for example, evidenced by the clas- sical Hawthorne studies [8]. Noteworthy within this perspective is the ‘socio-technical approach’ – introduced by the seminal work of [9] – that argues the mutual relation- ship between the social and technological ‘system’ of an enterprise. Hence, these systems must be jointly designed since they can mutually support each other to en- hance enterprise effectiveness and efficiency. Second, it is argued that the mere in- strumental view on employees – workers as resources for labor – undervalues human cognitive and intellectual capacities. This shift in focus is evidenced by landmark publications like [10], [11], and [12]. The shift in focus considers employees, and their involvement and participation, as the critical core for enterprise success. Rightly so, Drucker considers aspects of human behavior as the primary concerns of man- agement science [13]. Hence, “the test of a healthy business is not the beauty, clarity or perfection of its organizational structure, it is the performance of people” [13, p. 602]. Next to the involvement of employees for productivity improvement, said in- volvement is further essential for a focus on quality, as well as on service and cus- tomer orientation [14]. Moreover, one might observe that the character of work for a considerable part has shifted from physical labor to intellectual labor: creating, processing, integrating and applying knowledge [15, 16]. It is virtually all about mak- ing knowledge productive [17]. Within this perspective, enterprise learning2 is, and will increasingly become, an indispensable competence. Learning is a prerequisite for innovation, adaptation and change. Again, the focus on employees is crucial. Evident- ly, a learning enterprise is inconceivable without individual learning of employees, on whose skills and commitment enterprise learning depends [18, 19]. This type of learn- ing acknowledges the non-planned, emerging character of many enterprise develop- ments [20]. Progress in the area of information and communication technology (ICT) has enabled the creation of massive amounts of data associated with enterprise processes.

2 In the traditional organizational sciences this notion is commonly referred to as ‘organization- al learning’.

The Principles of Enterprise Engineering 17

Work is no longer merely automated (to enhance productivity), but ‘informated’ [22]. As indicated earlier, work has almost become synonymous with ‘knowledge work’: the processing of physical assets is increasingly replaced or complemented by the processing of intellectual assets [15, 17]. Making knowledge productive thus amounts to integrating knowledge (information) into a common task [op. cit.]. Creating and sharing knowledge is considered crucial for gaining competitive advantage [23]. Evi- dently, this holds likewise for the competence of enterprise learning. It seems super- fluous to stress the importance of ICT for enterprise learning, hence for the ability to improve, adapt, and change. Without enterprise learning, these changes cannot be established. From the perspective of the ‘relationship economy’ the new capabilities and possi- bilities created by information and communication technology are essential for suc- cessfully pursuing long-standing relationships with customers, and for employees supporting them. The vast amount of actions and data pertinent to customers, and their relationships, desires and needs, can only be meaningfully and effectively ad- dressed with the help of ICT. Deep support cannot take place outside the digital me- dium [21]. Additionally, ICT makes customer self-support possible and valuable. Moreover, since establishing relationships cannot take place within the principles of the transaction economy, the nature of ICT utilization must change; not only for ef- fectuating customer support and proactively exploiting the relationship in a value- adding manner, but also for making the economic value of customer relationships explicit. Finally, one can observe the increasing ‘commoditization’ of basic products and services. Customers can easily switch between suppliers of commodities. However, highly valued individual supportive relationships with customers are anything but a commodity. Hence, they can create a considerable competitive advantage. Over the years, various other approaches have been proposed in addition to, or as a replacement for, Taylor’s principles of scientific management in order to enhance enterprise performance. The list is impressive: Activity-Based Costing, Balanced Score Card, Business Process Management, Business Process Reengineering, Cus- tomer Relationship Management, E-business, End-to-End (Supply) Chain Manage- ment, Enterprise Resource Planning, Lean Production, Learning Organization, Mergers and Acquisitions, Quality Function Deployment, Six Sigma, Total Quality management, and so on. Many, if not all, of these initiatives heavily depend on the successful utilization of ICT services. Based on reviews of these approaches, their successful application in enterprises is limited: the majority of initiatives fail [20]. Also from the general perspective on en- terprise strategic initiatives, the picture is not overly favorable. Mintzberg speaks of less than 10% success rate [24]. Other sources show comparable figures. According to Kaplan and Norton, many studies show that between 70% and 90% of strategic initia- tives fail, meaning that the expected results are not achieved [25]. Whereas all too often, for convenience sake, unforeseen or uncontrollable events are presented as the causes of failure, research has shown that strategic failure is mostly the avoidable result of inadequate strategy implementation. Rarely is it the inevitable consequence of a poor strategy [25]. A plethora of literature indicates that the key reason for

18 J.L.G. Dietz and J.A.P. Hoogervorst strategic failures is the lack of coherence and consistency, collectively also called congruence, among the various components of an enterprise [28, 29, 27, 31, 32, 14, 26, 33, 34]. At the same time, the need to operate as an integrated whole is becoming increasingly important. Globalization, the removal of trade barriers, deregulation, and so on, have led to networks of cooperating enterprises on a large scale, enabled by the enormous possibilities of modern ICT. Future enterprises will therefore have to oper- ate in an even more dynamic and global environment than the current ones. They need to be more agile, more adaptive, and more transparent. Moreover, they will be held more publicly accountable for every effect they produce. Creating a unified and integrated enterprise is by no means simple. An enterprise is an intentionally created entity of human endeavor [35, 36]. Enterprises are organized complexities [37]: highly complex, as well as highly organized. Unlike problems of ’organized simplicity’ that can be dealt with analytically, or problems of ’unorganized complexity’ that can be addressed statistically, the large problem area of ’organized complexity’ is in need of a formal approach [37]. The apparent lack of a theory for addressing the problem of organized complexity was mentioned decades ago as a core problem confronting modern science [39, 40].

2 Motivation for Enterprise Engineering

As stated, an enterprise is an intentionally created entity of human endeavor with a certain purpose. The intentional character of enterprise creation requires design activi- ties. For some, the term ‘design’ in the context of enterprises has uncomfortable con- notations, as it is associated with mechanistic approaches to enterprises: arranging them as if they are machines. The ‘social engineering’ label is sometimes used to identify the mechanistic view on organization and management [38]. This approach essentially equates management with control, with the associated conviction that by using certain ‘controls’ management is able to steer the enterprise ‘machine’ (top- down) within the desired range of operation. The enterprise is thereby assumed to be an objective entity, external to management, which, like a machine, merely needs to be controlled. This appears to be the perspective espoused by Taylor; it has been criti- cized above. Our notion of design, however, must be interpreted broadly and seen as devising “courses of action aimed at changing existing (enterprise) situations into preferred ones” [41, p.111]. Ultimately, on the one hand design concerns understand- ing the strategic intentions that are to be operationalized, and on the other hand, arranging this to happen. As Winograd and Flores put it: design concerns “the interac- tion between understanding and creation” [42, p.3]. The discipline of enterprise engineering should thus be viewed broadly from this perspective. The focus on design has enormous practical implications, and is associated directly with strategic and operational enterprise success [43]. Unfortunately, the importance of design is not generally recognized by management. A fairly recent McKinsey re- port argued that “Most corporate leaders overlook a golden opportunity to create a durable competitive advantage and generate high returns for less money and less risks: making organizational design the heart of strategy” [44, p.21]. Managers

The Principles of Enterprise Engineering 19 traditionally focus on structural arrangements for enterprise change; however, “They would be better off by focusing on organizational design” [44, p.22]. Hence, “Organi- zational design, we believe, should be about developing and implementing corporate strategy” [44, p.25]. Over the years (academic) insights have been developed about how to (1) enhance the effectiveness and efficiency of enterprises, (2) effectively ensure quality, service and customer orientation, and (3) avoid core reasons for strategic failure. One would expect that a century after Taylor published his principles of scientific management their influence would have vanished. However, it appears not to be the case. As Doz and Thanheiser observed at the end of the former century: “Despite the ‘moderniza- tion’ of corporate structures and systems, the mindset of managers appears to be re- markably similar to the Taylorist model developed at the beginning of the century” [45, p. 296]. Thus, principles that follow from “a machine-like concept of the organi- zation still dominate managerial practice” [45]. Others argue that “Corporations con- tinue to operate according to a logic invented at the time of their origin, a century ago” [21]. Specifically concerning the use of ICT, the picture seems not radically different. Despite the alternative perspectives to Taylor presented before – including the value-adding, competitive use if ICT – the Taylorist influence appears still re- markable. For example, the Butler group “has consistently found that management in 9 out of 10 companies have never considered the use of IT other than achieving labor replacement” [46, pp 7-9]. The continuation of the Taylorist model can additionally be demonstrated by ob- serving the increase in the number of management functions. For example, in the country where Taylor expressed his views, managers accounted for less than 1% of the labor force in 1900. Thirty years later this figure was already 7.5%, increasing to 10.5% by 1970. By 1990, the figure was approaching 14% [47]. These increases must be understood against the background of increasing population and workforce. Others have given comparable data concerning the magnitude of management positions and the associated administrative burden [48]. The increased population of managers largely consists of people who believe that management is a profession like other professions. As Edward Deming, the renowned quality and productivity leader, observed: “Students in schools of business in America are taught that there is a profession of management; that they are ready to step into top jobs. That is a cruel hoax” [49, p. 130]. This ‘hoax’ resulted in the widely observ- able management crises. An article in the Standardization News (1983) stated that “Practical all our major corporations were started by technical men – inventors, me- chanics, engineers, and chemists, who had a sincere interest in the quality of products. Now, these companies are largely run by men interested in profit, not product. Their pride is the P&L statement or stock report” [49, p. 131]. Detrimental effects of these developments have been documented pertinent to the American automobile industry [50]. Not surprisingly, a recent Time article correlated the rise of business schools with the fall of American industry [51]. Such a paradigm shift is provided by the emerging discipline of Enterprise Engi- neering. It amounts to a theory-based methodology for addressing enterprise (re-) development in an all-encompassing way. A sound and rigid theoretical foundation is

20 J.L.G. Dietz and J.A.P. Hoogervorst crucial. As Deming states: “Experience alone, without theory, teaches management nothing about what to do to improve quality and competitive position, nor how to do it” [49, p. 19]. In view of our previous discussion, and the tenacity of Taylor’s principles, little learning seems to have taken place. We posit that an Enterprise Engi- neering theory is required to give experience meaning, and to provide the basis for appropriately understanding enterprises. It is the aim of Enterprise Engineering to be theoretically, conceptually, and meth- odologically complete, in pursuing the next three generic objectives:

Unity and Integration In order to perform optimally and to implement changes successfully, enterprises must operate as a unified and integrated whole, taking into account all aspects that are deemed relevant. Many approaches to enterprise engineering are ill suited and suffer from theoretical and methodological weakness and incompleteness. It is evidently not sufficient to consider enterprise design domains like processes, the information rele- vant for the processes, the applications providing the information, and their underly- ing infrastructure. A viable theory and methodology for enterprise engineering must be able to address all relevant aspects, even those that cannot be foreseen presently, such that the operating enterprise is always a coherent and consistent whole.

Mastering Complexity Proper theories about the construction and operation of enterprises are needed, next to powerful means for mastering complexity, in order to intellectually manage enterprise changes. Enterprise phenomena that are not fully understood cannot be effectively addressed. Hence, the nature of necessary changes cannot be determined; consequent- ly they cannot be brought about effectively. In addition, current development ap- proaches, both for enterprises as a whole and ICT applications in particular, are cursed with combinatorial impacts of changes, which make their implementation slow and practically unmanageable. New and proper ideas of enterprise evolvability are needed for making changes expeditious and manageable.

Employee Involvement Contrary to Taylor’s mechanistic view on organizations, Enterprise Engineering takes a human-centered view. Enterprise Engineering considers human beings to be the ‘pearls’ of every enterprise. Therefore, all employees should be fully empowered for the tasks they have to perform. They must be endorsed with transparent authority and have access to all information they need in order to perform their tasks in a responsi- ble way.

The theories and concepts on which Enterprise Engineering is based can address these three generic objectives successfully. A detailed outline of the methodology of Enter- prise Engineering exceeds the scope of this article, and is discussed elsewhere [52, 53, 20, 54]. For now, we limit ourselves to presenting the principles on which Enterprise Engineering is founded.

The Principles of Enterprise Engineering 21

3 The Enterprise Engineering Principles

In order to address the generic objectives of enterprise engineering, we have formu- lated seven principles for dealing effectively with enterprise changes, which may range from small ones (like installing a new e-mail system) to major transformations (like mergers and acquisitions). Principles 1 and 7 are visionary principles. They convey our conviction that the employees of an enterprise primarily constitute the enterprise, and that consequently they must get the proper empowerment to perform optimally. Put differently, in our view, enterprises are participatory networks of competent people. The employees of an enterprise (including both workers and managers) also collectively constitute the enterprise’s identity. In economic terms, they are the most precious assets. Everything else only serves to support them in doing their work. Principles 1 and 7 are the prima- ry means to achieve employee empowerment. Principles 2 and 3 serve to make enterprise changes intellectually manageable. They constitute the theoretical basis for understanding enterprises in a proper way, i.e. by doing justice to their inherent nature of being social systems. Principles 5 and 6 serve to make enterprise changes practical- ly manageable. They guide the implementation of changes in such a way that unity and integration are achieved, paired to avoiding combinatorial explosions of change impacts. Principle 4 is the pivot principle, connecting intrinsically the more analytic principles 2 and 3, and the more synthetic principles 5 and 6. All of them contribute to the objectives of mastering complexity and achieving unity and integration.

Principle 1: Distributed Operational Responsibility

Employee empowerment implies that as much responsibility as possible is given to the individual employees. It does not go along with strong hierarchical control me- chanisms. As it turns out, and as will elaborated in principles 2 and 3, many manage- ment or control measures are counterproductive and redundant. This is a common observation in numerous enterprise studies that have been undertaken with DEMO3. A typical example is the organizing of one’s work. It is our conviction that the ideal person to organize work is the worker him- or herself, provided that he/she has access to the information needed. Responsibility is the natural response of a human being to whom full authority is assigned for performing a task or fulfilling a role. Moreover, responsible employees are dedicated to achieve the optimal performance of an enter- prise in all aspects. There is ample practical evidence for our conviction, as exempli- fied by enterprises like Alcoa Inc, W.L. Gore & Associates, Nordstrom, and Semco. Therefore, we consider it to be an ethical necessity to bestow authorities on the employees of an enterprise, and having them bear the corresponding responsibility. The prerequisite is that they fully understand their role(s) in the enterprise. This

3 DEMO is an acronym for Design and Engineering Methodology for Organizations. It is a pioneering methodology in Enterprise Engineering, based on the theoretical basis as laid down in [Dietz 2006] and [Dietz 2008]. See also www.ee-institute.com

22 J.L.G. Dietz and J.A.P. Hoogervorst entails that the employees are enabled to internalize the (relevant parts of the) onto- logical model of the enterprise, as elaborated in principle 4. Bearing responsibility includes that these employees constantly validate the correspondence of the ontologi- cal model with the operational reality and take appropriate measures in case of devia- tions. A typical demonstration of the validity of principle 1 can be found in the current application of DEMO within the Royal Netherlands Marechaussee, which is a gen- darmerie force performing military police and civil police duties4.

Principle 2: Transaction Based Organization

The operating principle of enterprises is that the employees, together with representa- tives of the customers and the suppliers, enter into and comply with commitments regarding the products (services) that they cooperatively produce. This very basic observation makes enterprises primarily social systems, of which the elements are human beings in their role of social individuals, bestowed with appropriate authority and bearing the corresponding responsibility. Commitments are raised and complied with in universal coordination patterns, called transactions, between two actor roles: the initiator (consumer) and the executor (producer). The two actors are fully authorized and responsible for performing all steps in the universal transaction process [52]. The notion of transaction holds for all activities in an enterprise, including e.g. managerial tasks. The deep structure of every enterprise process is that it is a tree of transactions. Every observable process (instance) is some path through a transaction tree. The executor of a transaction is fully and only responsible for the delivered result. In order to live up with this responsibility, he/she may feel the need to initiate a number of other transactions, of which the results become components of the end result. In par- ticular, he/she is responsible for negotiating delivery times of the components and subsequently provide the delivery time of the end result. Hence, the arrangement of work – which Taylor completely reserved for managers – is back again with the employees. Note that current business process modeling approaches, even the most popular ones (like BPMN, ARIS/EPC and Petri Net) completely ignore this underlying struc- ture, whereas the recognition and application of the universal transaction process provides for an enormous contribution to mastering the complexity in understanding the construction and operation of enterprises. There is no typical application of DEMO for demonstrating the validity of prin- ciple 2. In all of the hundreds of studies performed in the past decades, the notion of the universal transaction process has been crucial for the appropriate understanding of an enterprise, and for mastering its complexity. Moreover, principle 2 is not limited to the operational processes in an enterprise. It is applicable to all activities, as demon- strated in [55]

4 A short description of the study can be found on www.ee-institute.com

The Principles of Enterprise Engineering 23

Principle 3: Actor Based Modularity

The complexity of enterprises necessitates a division of tasks to be performed. It is neither effective nor efficient to let every employee do all tasks. Put differently, there is a need for task differentiation. Because the enterprise must operate as a unified whole, task differentiation must be properly paired to the integration of the distinct tasks. The organizational sciences have for long recognized the non-trivial issue of differentiation on the one hand, and integration on the other [56, 36]. Despite this recognition, however, an effective approach to address the issue is still lacking. In our experience, hierarchical schemes, or pseudo (value oriented) process schemes are of little use. The notion of transaction (principle 2) implies the notion of elementary actor. An (elementary) actor role is defined as the amount of authority and responsibility to be executor of a transaction kind, which has exactly one kind of result (e.g. concluding an insurance policy or buying a house). Actor roles are the atomic building blocks of the ontological model of an enterprise [52]. In addition to being the executor of one transaction kind, an actor role may be initiator of a number of transaction kinds. An actor role may be fulfilled simultaneously by several persons (in parallel or collective- ly), and a person may simultaneously fulfill several actor roles. Constructing enterprises by applying actor roles as the elementary building blocks provides another major contribution to mastering the complexity of enterprises and enterprise changes. In addition, it is the best guarantee that even the most encompass- ing enterprise changes will not lead to severe combinatorial explosions of effects. An interesting extension of this idea towards software engineering is presented in [57], where the notions of service and of business component are based on this organiza- tional building block. The same idea of elementary building blocks can be applied to software engineering, as is demonstrated by the Normalized Systems approach [56]. Like it was the case for principle 2, there is no typical application of DEMO for demonstrating the validity of principle 3. In all studies performed in the past decades, the notion of actor role has been as crucial as the universal transaction process for appropriately understanding the construction and operation of an enterprise, and for mastering its complexity.

Principle 4: Technology Independent Essence

Taking advantage of the notion of transaction that we have adopted (principle 2), we now abstract from the technology with which transaction steps are performed. For example, we focus on the essence of a request being made by actor A towards actor B, and disregard the particular way in which the request is made knowable to B (e.g. by face-to-face communication, by postal mail, or by e-mail). Secondly, we also ab- stract from all transaction kinds of which the result is informational or documental, because they do not necessarily need human competence and authority. Informational transactions include the remembering and recalling of information as well as the computing of information. Documental transactions include storing, retrieving, copy- ing, and transmitting data. Modern ICT can effectively take over the production of

24 J.L.G. Dietz and J.A.P. Hoogervorst informational and documental tasks. Only original transactions, in which truly new facts, like decisions and judgments, are produced, need human actor role fulfillers. Focusing on the original transactions – thus, where the product or service consists of decisions, judgments, manufacturing, etc. – while at the same time abstracting from the technology with which transaction process steps are performed, provides us with the third major contribution to mastering complexity. Combined with the ones from principle 2 and principle 3, a reduction of the size of models is achieved that amounts to well over 90%. The typical size of the diagram in which the so-called essential model of DEMO is represented, is an A4 or A3 sheet of paper for a small or medium sized enterprise. At the same time, the represented ontological essence of the enterprise contains all relevant elements. Moreover, it has been arrived at in a structured and controlled manner, and the way back to the implementation level is again structured and con- trolled. Current modeling techniques, like BPMN and ARIS/EPC, are totally unable to achieve such an abstraction, because they lack a theoretical basis of proper and powerful ideas, like the ones presented in principles 2 and 3. A typical demonstration of the validity of principle 4 can be found in the current application of DEMO in the post merger integration of the cargo divisions of Air France and KLM5. Without the insight and overview that is offered by the essential model (on an A2 sheet of paper!), such integrations are unmanageable. The complexi- ty of modern organizations can only be managed intellectually if all change initiatives are based on the essential model of the organization. In addition, the correctness of an implemented change can only be validated from the essential model.

Principle 5: Function Construction Alternation

Unity and integration in implementing strategic change initiatives can only be estab- lished through deliberate re-development of the enterprise, where development in- cludes (ontological) design, engineering (in the narrow sense, i.e. implementation design), and implementation. In this process, the conscious distinction between a system’s function and construction, and the insight in their alternating roles in system development, is of paramount importance. To start with, only the construction of a system is objective. A constructional model (or white-box model), like the essential (ontological) model of an enterprise, can always be validated from the actual con- struction. Contrarily, a functional model (or black-box model) is by its very nature subjective, because function is not a system property but a relationship between a system and a stakeholder. Consequently, every system has (at any moment) one con- struction, but as many functions as there are stakeholders. All these functions are brought about by the (same and only) construction. Next, the construction of a system as a composition of sub systems can only be understood through the alternating roles of function and construction. As an example, the functional specifications for the engines of an aircraft are derived from the constructional model of the aircraft, not

5 A short description of the project can be found on www.ee-institute.com

The Principles of Enterprise Engineering 25 from the aircraft’s functions. In addition, the actual construction of the engines is immaterial for understanding the construction of the aircraft. Let us call the system to be designed the object system, and every stakeholder point of view a using system [53]. We conjecture that the integrity of a development process can only be ensured if it starts from the ontological (construction) models of the using systems. Based on these models, the functional model of the object system is designed. Next, the ontological construction model of the object system is designed. Starting from this model, the engineering of the object system can take place, as a model driven process of including more and more technology dependent details, until the implementation model is arrived at. A logical consequence of principle 5 is, that it makes no sense to develop enter- prise information systems, starting from the goals of the enterprise (although many approaches makes one believe so). Another consequence is, that business IT align- ment can never be achieved through IT governance (although many approaches makes one believe so), because one lacks the knowledge of the business, i.e. the con- struction of the enterprise. A third important consequence is the insight that every operational enterprise information system is some implementation of (some part of) the essential model of the enterprise. Since in current information system develop- ment practice, essential models of the supported enterprise are not produced, one should not be amazed that these systems (including parameterizable ERP systems) do not meet customer expectations. A very interesting new way of developing informa- tion systems, founded on the basic insight of principle 4, is presented in [59]. A typical demonstration of the validity of principle 4 and 5 can be found in the ap- plication of DEMO in the modeling of granting subsidies on different governmental levels6.

Principle 6: Strategy-Operation Alignment

It is one thing for an enterprise to have clear strategic goals and areas of concern, derived from a broadly sustained mission statement. It is quite another thing to have all operational details in the enterprise’s organization fully compliant with them. The challenge is to align strategy and operation in a satisfying way. To ensure that an enterprise operates in a unified and integrated manner, and in compliance with its strategic intentions and areas of concern, the development process of enterprises and of their supporting systems must be controlled by functional and constructional normative principles, which guide the (re-) development of the enter- prise, in addition to the applicable specific functional and constructional require- ments. A coherent, consistent, and hierarchically ordered set of such principles for a particular class of systems is called an architecture. The collective architectures of an enterprise are called its enterprise architecture. The notion of architecture can best be conceived as the deliberate restriction of de- sign freedom, which comes in addition to the specific functional and constructional requirements in (re-) designing an organization. It is expressed in (functional and

6 A short description of the project can be found on www.ee-institute.com

26 J.L.G. Dietz and J.A.P. Hoogervorst constructional) design principles regarding a number of areas of concern and applied in one or more enterprise design domains [53, 20]. As emphasized before, this ap- proach methodologically addresses the enterprise in all its facets. So, for example, the concern for motivated employees must be addressed through appropriate design prin- ciples that are applied in relevant enterprise design domains. An extensive study of architecture principles is contained in [60]. A typical demonstration of the validity of principle 6 can be found in a study on developing architectures at KLM Cargo7.

Principle 7: Distributed Governance Responsibility

For continuously maintaining unity and integration in the (re-) development and opera- tion of an enterprise, organizational measures are needed that exceed operational resp onsibilities and tasks (including management). These measures are collectively called governance. Hence, unlike operational management (‘running the mill’) governance concerns enterprise adaptation and renewal (‘changing the mill’).Very often, the respon- sibility for taking and applying such measures on a continuous basis, usually called en- terprise governance, is assigned to higher levels of management. Factually, this amounts to the continuation of the Taylorist separation of thinking (management) and doing (workers): the locus of knowledge and control rests with executive management. Such an approach is inherently problematic and dysfunctional [20]. Indeed, how could executive management possibly know and comprehend all in- ternal (operational) issues and external developments that necessitate enterprise change and adaptation, and translate them in top-down directives that would innova- tively yield a new, adapted, unified and integrated enterprise? We posit, however, that it is essential to extend the notion of employee involvement also to the realm of enter- prise governance. All employees are considered creative sources for (bottom-up) en- terprise improvements and adaptation. Of course, they must be enabled and competent to do so. In order to ensure coherence and consistency in the development and imple- mentation of new ideas and ways of working, a central governance capability must be exercised at the holistic enterprise level. This central guiding governance capacity utilizes the enterprise engineering theory and methodology for achieving the generic objectives mentioned before. Note that IT governance is an integral part of enterprise governance, despite the many views that do not acknowledge or adequately operationalize this notion due to the absence of a focus on enterprise-wide design [61, 62].

4 Discussion

Enterprises are purposeful entities of human endeavor, and they come in a wide range of forms and dimensions. Arguably, society is largely constituted and dominated by enterprises. For healthcare, education, transportation, or the production and

7 A short description of the project can be found on www.ee-institute.com.

The Principles of Enterprise Engineering 27 acquisition of commercial and governmental goods and services, individuals depend on, and are influenced by, the characteristics and performance of enterprises, as a citizen, consumer or employee. Hence, the characteristics and performance of enter- prises has a bearing on the quality of individual life and society at large: societal and environmental conditions, the quality of work and private life, individual physical and mental health, and economical circumstances: they all are impacted by enterprises. As we have seen, almost all (94%) manifestations of inadequate enterprise perfor- mance are the inevitable results of how enterprises are arranged [49]; the underlying causes are ‘common causes’. Only a limited percentage (6%) of inadequate enterprise performance manifestation are attributable to employees (‘special causes’). Put diffe- rently, poor quality or service, alienated customers and employees, inefficiency, low productivity, waste of human, natural or financial resources, burn-outs, financial cris- es, or failing disaster recovery (to name but a few), are all the inevitable consequences of the very nature of enterprises producing these effects. Yet, within the planning and control (Taylorist) mindset of managers, virtually only attention is paid to ‘special causes’, leading to even more employee control with no, or detrimental effects. All too often, this mindset is combined with relentless focus on short-term financial gain. In view of the enormous impact that enterprises have on individual and societal well-being, we contend that enterprises have a moral obligation to avoid undesired enterprise outcomes and secure desired ones. Since, in line with Deming’s observa- tion, these outcomes are the inevitable consequences of how enterprises are arranged, achieving enterprise outcomes is thus first and foremost a matter of adequate and intentional enterprise design. Consequently, proper attention to enterprise design also has moral connotations. To our knowledge, enterprise engineering is the only effec- tive means to formally operationalize the moral responsibilities that enterprises face. As outlined in this article, it is precisely here that serious rethinking is desperately needed. In a century after Taylor, scientific thinking about enterprises has progressed significantly. Nonetheless, enterprises continue to operate according to a century-old mindset. Hence, there is a large chasm between what science knows and what enter- prises do. It is the aim of enterprise engineering to further increase that knowledge and to make it practically useable. This could initially aggravate the chasm. There- fore, top-management’s comprehension about the importance of enterprise engineer- ing is essential. Our paper is not the first plea for enterprise engineering. For example, more than a decade ago, James Martin stated that “Enterprise Engineering is an integrated set of disciplines for building or changing an enterprise, its processes, and systems” [63, p.58]. With deep insight he foresaw that “A new type of professional is emerging – the enterprise engineer” [63, p.xii]. It coincided with the founding paper by Liles et al. [64] and the set up of the International Society for Enterprise Engineering8. However, this society seems not be active anymore since about 2004. In addition – and presum- ably the cause of their failure – the aforementioned proposals lack a sound and rigorous scientific foundation.

8 Cf. www.iseenet.org

28 J.L.G. Dietz and J.A.P. Hoogervorst

Great leaders may have great ideas, but only engineers can change the world, a deep truth that many managers still have to get used to. And as it goes for all engi- neering disciplines (mechanical engineering, aeronautical engineering, electrical en- gineering, etc.), enterprise engineering will only become a serious and successful discipline if it is based on sound theoretical foundations.

References

1. Taylor, F.W.: The Principles of Scientific Management. Harper Brothers, NY (1911) 2. Fayol, H.: General Principles of Management. In: Pugh, D.S. (ed.) Organization Theory. Penguin Books, London (1990) 3. Weber, M.: Legitimate Authority and Bureaucracy, 1924. In: Pugh, D.S. (ed.) Organiza- tion Theory. Penguin Books, London (1990) 4. Fromm, E.: The Fear of Freedom. Routledge and Kegan Paul, London (1942) 5. Fromm, E.: The Sane Society. Rinehart and Company, New York (1955) 6. Mintzberg, H.: Mintzberg on Management. Free Press, New York (1989) 7. Hounshell, D.: From the American System to Mass production, pp. 1800–1932. John Hopkins University Press, Baltimore (1984) 8. Mayo, E.: The Social Problems of an Industrial Civilization. Routledge and Kegan Paul, London (1949) 9. Trist, E.A., Bamforth, K.W.: Some Social and Psychological Consequences of the Long- wall Method of Coal-getting. Human Relations 4(1) (1951) 10. McGregor, D.M.: The Human Side of Enterprise. McGraw-Hill, New York (1960) 11. Likert, R.: New Patterns of Management. McGraw-Hill, New York (1965) 12. Katz, D., Kahn, R.L.: The Social Psychology of Organizations. Wiley, New York (1978) 13. Drucker, P.: Management. Harper, New York (1985) 14. Hoogervorst, J.A.P.: Quality and Customer Oriented Behavior: Towards a Coherent Ap- proach for Improvement. Delft, Eburon (1998) 15. Drucker, P.: The New Productivity Challenge. Harvard Business Review, 69–79 (Novem- ber/December 1991) 16. Drucker, P.: The New Society of Organizations. Harvard Business Review 70(5), 95–104 (1992a) 17. Drucker, P.: The Post-Capitalist Society. Harper Business, New York (1993) 18. Argyris, C., Schön, D.: Organizational Learning. Addison-Wesley, Reading (1978) 19. Kim, D.H.: The Link between Individual and Organizational Learning. Sloan Management Review 35(1), 37–50 (1993) 20. Hoogervorst, J.A.P.: Enterprise Governance and Enterprise Engineering. Springer, Berlin (2009) 21. Zuboff, S., Maxmin, J.: The Support Economy. Penguin Press, London (2002) 22. Zuboff, S.: In the Age of the Smart Machine. Basic Books, New York (1989) 23. Nonaka, I., Takeuchi, H.: The Knowledge Creating Company. Oxford University Press, New York (1995) 24. Mintzberg, H.: The Rise and Fall of Strategic Planning. The Free Press, New York (1994) 25. Kaplan, R.S., Norton, D.P.: Strategy Maps. Harvard Business School Press, Boston (2004) 26. Galliers, R.D., Baets, W.R.: Information Technology and Organizational Transformation. Wiley, Chichester (1998) 27. Strassmann, P.A.: The Business Value of Computers. The Information Economics Press, New Canaan (1990)

The Principles of Enterprise Engineering 29

28. Miles, R.E., Coleman, H.J., Douglas Creed, W.E.: Keys to Success in Corporate Redesign. California Management Review 37(3), 128–145 (1995) 29. Miles, R.E., Snow, C.C.: Fit, Failure and the Hall of Fame. California Management Re- view 26(3), 128–145 (1984) 30. Beer, M., Eisenbach, R.A., Spector, B., Why Change Programs Don’t Produce Change. Harvard Business Review, 158–166 (November/December 1990) 31. Kaufman, R.S.: Why Operations Improvement Programs fail: Four managerial Contradic- tions. Sloan Management Review 34(1), 83–93 (1992) 32. Kotter, J.P.: Leading Change: Why Transformation Efforts Fail. Harvard Business Re- view 71(2), 59–67 (1995) 33. Pettigrew, A.: Success and Failure in Corporate Transformation Initiatives. In: Galliers, R.D., Baets, W.R.J. (eds.) Information Technology and Organizational Transformation. Wiley, Chichester (1998) 34. Leinwand, P., Mainardi, C.: The Coherence Premium. Harvard Business Review (June 2010) 35. Robbins, S.P.: Organization Theory. Prentice-Hall, Englewood Cliffs (1990) 36. Daft, R.L.: Organization Theory and Design. South-Western Publishing, Mason (2001) 37. Weinberg, G.M.: An Introduction to General Systems Thinking. Dorset House Publishing, New York (2001) 38. Tsoukas, H.: Refining Common Sense: Types of Knowledge in Management Studies. Journal of Management Studies 31(6), 761–780 (1994) 39. Weaver, W.: Science and Imagination. Selected Papers of Warren Weaver. Basic Books, New York (1967) 40. von Bertalanffy, L.: General Systems Theory. George Braziller, New York (1969) 41. Simon, H.A.: The Sciences of the Artificial. MIT Press, Cambridge (1969) 42. Winograd, T., Flores, F.: Understanding Computers and Cognition: A New Foundation for Design. Addison-Wesley, Boston (1987) 43. Nadler, D.A., Tushman, M.L.: Competing by Design: The Power of Organizational Archi- tecture. Oxford University Press, New York (1997) 44. Bryan, L.L., Joyce, C.I.: Better strategy through organizational design. McKinsey Quarter- ly (2) (2007) 45. Doz, Y., Thanheiser, H.: Regaining Competitiveness: A Process of Organizational Renew- al. In: Hendry, J., Johnson, G., Newton, J. (eds.) Strategic Thinking: Leadership and the Management of Change. Wiley, Chichester (1993) 46. Butler, M.: Measuring the Value of IT. Information Economics Journal, 7–9 (March 2005) 47. Osterman, P.: Broken Ladders: Managerial Careers in the New Economy. Oxford Univer- sity Press, New York (1996) 48. Witteloostuijn, A.: De Anorexiastrategie. De Arbeiderspers, Amsterdam (1999) 49. Deming, W.E.: Out of the Crisis. Cambridge University Press, Cambridge (1986) 50. Lutz, B.: Car Guys vs. Bean Counters: The Battle for the Soul of American Business. Pen- guin, New York (2011) 51. Foroohar, R.: Driven of the Road by MBA’s, Time, July 18 (2011) 52. Dietz, J.L.G.: Enterprise Ontology. Springer, Berlin (2006) 53. Dietz, J.L.G.: Architecture: Building Strategy into Design. SDU Publishing, The Hague (2008) 54. Hoogervorst, J.A.P.: A Framework for Enterprise Engineering. International Journal of In- ternet and Enterprise Management 7(1), 5–40 (2011)

30 J.L.G. Dietz and J.A.P. Hoogervorst

55. Aveiro, D., Silva, A.R., Tribolet, J.: Control Organization: A DEMO Based Specification and Extension. In: Albani, A., Dietz, J.L.G., Verelst, J. (eds.) EEWC 2011. LNBIP, vol. 79, pp. 16–30. Springer, Heidelberg (2011) 56. Lawrence, P., Lorsch, J.: Organization and Environment. Harvard Business School Press, Boston (1967) 57. Albani, A., Terlouw, L.: An Enterprise Ontology-Based Approach to Service Specifica- tion. IEEE Transactions on Services Computing (October-December 2010) 58. Mannaert, H., Verelst, J.: Normalized Systems, Re-creating Information Technology Based on Laws for Software Evolvability. Koppa, Kermt (2009) 59. van Kervel, S.J.H.: Enterprise Ontology driven Information Systems Engineering. Disser- tation Delft University of Technology (forthcoming, 2012) 60. Greefhorst, D., Proper, E.: Architecture Principles – The Cornerstones of Enterprise Atchi- tecture. Springer, Heidelberg (2011) 61. IT Governance Institute: Board Briefing on IT Governance. Rolling Meadows (2003) 62. Maizlish, B., Handler, R.: IT Portfolio Management Step-By Step. Wiley, Hoboken (2005) 63. Martin, J.: The Great Transition. Using the Seven Principles of Enterprise Engineering to Align People, Technology and, Strategy. American Management Association (1995) 64. Liles, D.H., Johnson, M.E., Meade, L.: The Enterprise Engineering Discipline. In: Pro- ceedings of the Society for Enterprise Engineering, Orlando (1995)

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, 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 do- main knowledge of the analyst. As a consequence, analysis patterns and reference models have been introduced in the past as a means to con- solidate best-practices in conceptual modeling (often incorporating spe- cific 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 flexibil- ity 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 Sys- tems (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.

Keywords: Normalized Systems, Reference Models, Analysis Patterns, Evolvability, SAP Reference Model.

1 Introduction

Traditionally, the activities to be undertaken during information systems devel- opment are categorized into (successively) analysis, design, programming, test- ing, implementation and maintenance phases [1]. The analysis phase in this overall process has frequently proved to be a difficult assignment as the result- ing quality of the work may vary significantly from project to project and heav- ily 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 con- sequences which are difficult (if not impossible) to remediate later on during

A. Albani, D. Aveiro, and J. Barjis (Eds.): EEWC 2012, LNBIP 110, pp. 31–45, 2012. c Springer-Verlag Berlin Heidelberg 2012 32 P. De Bruyn et al. 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 anal- ysis 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 refer- ence 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 evalua- tion 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,asthemain 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 informa- tion systems, business processes, etcetera) have to adapt themselves accordingly. Reference models enabling this agility might thus incorporate a significant com- petitive 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 canactuallybeinterpretedintermsofandappliedto 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 33

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 Normal- ized 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 produc- tivity [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 anal- ysis 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 in analyzing business functions. While the term “analysis pattern” and “refer- ence model” seem to be frequently employed interchangeable, Kodaganallur and 34 P. De Bruyn et al.

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 qual- ity of reference models such as feature-based evaluation, ontology-based evalua- tion 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 evolv- ability 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 frame- works using the evaluation approaches [7, 6].

3 Normalized Systems Theory

In this section, the essence of Normalized Systems will be outlined. First, the the- oretical 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 proposes to regard the transformation of functional requirements R intoaset of (constructional) software primitives S [8,9,10]: Applying NS Theory Implications to Enterprise Process Reference Models 35

{S} = I{R}

Next, the property of systems theoretic stability is imposed onto this transforma- tion. 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 ver- sion transparant way; – Action Version Transparency, requiring that action components can be up- dated 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 some- way [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 con- form 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 business process level when the impact of an elementary change is related to the overall size of the 36 P. De Bruyn et al. 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., elemen- tary 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 or- ganizational 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 spe- cific 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 fine- grained 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 decomposi- tion 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 rig- orous 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 37

The taxonomy of Kodaganallur and Shim [25] proposes to map analysis pat- terns 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 enter- prise process reference model analysis, the SAP R/3 Reference Model was chosen. First, in contrast with some other vendors possessing extensive and best- practice 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 best- practice 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 oper- ators 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 frame- work 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 soft- ware implementations used in different organizations. Moreover, the reference model has been included in SAP’s joining configuration methodology: the It- erative Process Prototyping (IPP) method. In short, this method is claimed to guide organizations in discovering which modules and processes of the SAP ap- plications 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 38 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 limi- tations 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 program- mers [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 up- front 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 man- agement 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 disad- vantages 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 39

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 com- pliance with Normalized Systems guidelines. First, the processes are formulated and drafted as a kind of information objects going through their respective lifecy- cles. 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 selec- tion, 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. 40 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 reflec- tion 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 represent- ing 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 pro- cesses seem to have been separated as well. For example, separate processes are drafted for “demand management”, “purchase order processing”, “invoice pro- cessing”, “good recept processing”, “inspection lot completion for goods move- ment”, 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 viola- tions of the NS principles might be noticed. First, concerning the identification of the individual tasks/functions, it might be argued that frequently several sepa- rate 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 con- tains multiple separate tasks (functional entities of work) or change drivers, such as “change navigation hierarchy”, “create ranking”, “perform currency transla- tion”, 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 in multiple Applying NS Theory Implications to Enterprise Process Reference Models 41 events (symbolizing multiple tasks that have been fulfilled during the execu- tion 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 ob- ject 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 sev- eral 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 pro- cess 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 re- leased [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 re- lated activities) which might evolve independently. Moreover, activities for this credit control might also turn out to be useful outside the flow of delivery pro- cessing, 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 pro- cesses “delivery processing” and “goods delivery processing” combine multiple concerns which should be properly separated accordingtoNStheorems. 42 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 re- peated 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 repli- cated 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 re- gard 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 du- plication 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 maintain- ing 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 perspec- tive 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 require- ments 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 primi- tives or building blocks for composing the actual business processes realizing the functional requirements as the primitives are “called” and instantiated.

5Conclusion

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 43 consisting of states and functions and the partial reflection of the proposed guide- lines in [13] show some conformance towards NS, also some examples of indica- tions 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 challeng- ing 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 anal- ysis 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 mod- ules 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 indi- cations of violations. This conclusion is similar to those mentioned in [13], which indicated that BPMN models in several case studies derived from industry prac- tice 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) 2. Wand, Y., Weber, R.: Research commentary: Information systems and concep- tual modeling — a research agenda. Information Systems Research 13(4), 363–376 (2002) 44 P. De Bruyn et al.

3. Moody, D.L.: Metrics for Evaluating the Quality of Entity Relationship Models. In: Ling, T.-W., Ram, S., Li Lee, M. (eds.) ER 1998. LNCS, vol. 1507, pp. 211–225. Springer, Heidelberg (1998) 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. Human- Computer Interaction 10, 79–119 (1995) 6. Fettke, P., Loos, P.: Reference Modeling for Business Systems Analysis. In: Ref- erence Modeling for Business Systems Analysis, pp. 1–21. Idea Group Publishing (2007) 7. Frank, U.: Evaluation of Reference Models. In: Reference Modeling for Business Systems Analysis, pp. 118–140. Idea Group Publishing (2007) 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, 89–116 (2012) 10. Mannaert, H., Verelst, J., Ven, K.: The transformation of requirements into soft- ware primitives: Studying evolvability based on systems theoretic stability. Science of Computer Programming 76(12), 1210–1222 (2011); 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, pp. 59–66 (2012) 12. De Bruyn, P.: Towards Designing Enterprises for Evolvability Based on Funda- mental Engineering Concepts. In: Meersman, R., Dillon, T., Herrero, P. (eds.) OTM-WS 2011. LNCS, vol. 7046, pp. 11–20. Springer, Heidelberg (2011) 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 Sys- tems 1(2), 1–26 (2004) 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 Profes- sional (1996) 21. Scheer, A.: Business Process Engineering – Reference Models for Industrial Enter- prises. Springer (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) 23. McCarthy, W.E.: The rea accounting model: A generalized framework for account- ing systems in a shared data environment. The Accounting Review 57(3), 554–578 (1982) Applying NS Theory Implications to Enterprise Process Reference Models 45

24. Dietz, J.: Enterprise Ontology. Springer, Heidelberg (2006) 25. Kodaganallur, V., Shim, S.: Analysis patterns: A taxonomy and its implications. Information Systems Management 23(3), 52–61 (2006) 26. Fettke, P., Loos, P.: Multiperspective Evaluation of Reference Models – Towards a Framework. In: Jeusfeld, M.A., Pastor, O.´ (eds.) ER Workshops 2003. LNCS, vol. 2814, pp. 80–91. Springer, Heidelberg (2003), doi: 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 In- ternational Conference on Systems, ICONS 2012, pp. 93–99 (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), 425–443 (1999) 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), pp. 459–464 (2011) 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 Sys- tems 5(4), 89–108 (2001) 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), 312–329 (2008) 34. Rosemann, M., van der Aalst, W.M.P.: A configurable reference modelling lan- guage. Information Systems 32, 1–23 (2007) 35. Ekanayake, C.C., La Rosa, M., ter Hofstede, A.H.M., Fauvet, M.-C.: Fragment- Based Version Management for Repositories of Business Process Models. In: Meers- man, R., Dillon, T., 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 2011, Part I. LNCS, vol. 7044, pp. 20–37. Springer, Heidelberg (2011) 36. Uba, R., Dumas, M., Garc´ıa-Ba˜nuelos, L., La Rosa, M.: Clone Detection in Repos- itories of Business Process Models. In: Rinderle-Ma, S., Toumani, F., Wolf, K. (eds.) BPM 2011. LNCS, vol. 6896, pp. 248–264. Springer, Heidelberg (2011), doi: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), 17–18 (2010) 38. Weinberg, G.M.: An Introduction to General Systems Thinking. Wiley (1975) Enterprise Dynamic Systems Control Enforcement of Run-Time Business Transactions

S´ergio Guerreiro1, Andr´e Vasconcelos2,3,andJos´e Tribolet2,3

1 Universidade Lus´ofona de Humanidades e Tecnologias, Escola de Comunica¸c˜ao, Artes, Arquitectura e Tecnologias da Informa¸c˜ao, Campo Grande 376, 1749-024 Lisbon, Portugal [email protected] 2 CODE, Center for Organizational Design & Engineering, INOV, Rua Alves Redol 9, Lisbon, Portugal 3 Department of Information Systems and Computer Science, Instituto Superior T´ecnico,Technical University of Lisbon, Portugal [email protected], [email protected]

Abstract. Business transactions models prescribe the design freedom restrictions of the business transactions dynamics but per se do not guar- antee that organizational actors perform them accordingly. Enterprise dynamic systems control (EDSC) guarantees that the prescriptions are followed in the operation by performing a continuously cycle of observa- tion, decision and control action. Control action actuates with a change in the business transaction models prescription to avoid the recurrence of unintended operations or a change in the control rules if the deviation from prescription is recognized as being innovative. This paper proposes a full DEMO-based ontology to enforce EDSC in the run-time operation of business transactions. The EDSC proposal is exemplified using (i) DEMO business transaction ontological specification, (ii) actor’s qualifi- cation mechanim integrated with business transactions and (iii) business rulesenforcedintheactor’sex-post acts.

Keywords: Business transaction, Control, DEMO, Governance, Model, Ontology, Operation, Organization.

1 Introduction

An enterprise is a large, complex and non linear dynamic system whose dynamics encompasses both the business transactions and the organizational structure’s systemic definition. To deal properly with the systemic definition of an enter- prise, scientific foundations with new theories and methodologies that enable the understanding, design and implementation of the organization are needed. Business transactions occur at run-time across a distributed network of actors that constitutes an enterprise. Business transactions establish the design free- dom restrictions prescribed for the organization, but they do not guarantee that the business actors perform the transactions accordingly. Business actors while

A. Albani, D. Aveiro, and J. Barjis (Eds.): EEWC 2012, LNBIP 110, pp. 46–60, 2012. c Springer-Verlag Berlin Heidelberg 2012 Enterprise Dynamic Systems Control 47 playing an active role in business transactions are simultaneously the essentials elements of the enterprise dynamic systems control, because they individually and/or collectively observe the reality and autonomously produce new control actuations that change it. Without actor’s activity there are no performed acts thus the organization does not exist. To guarantee that the prescribed business transactions are respected it is necessary to continuously control the misalign- ments between the prescribed business transactions and the observed operation in the organization. The foundational concepts from dynamic systems control (DSC) theories, which are defined and used successfully in the Engineering fields for decades [1][2][3], are applied in this paper to the enterprise dynamic system to control its outcome. The emerging field of Enterprise Engineering (EE) [4] in- troduces capabilities to deal rigorously with the dynamic aspects of the business transactions using ontological models. An important indication of compatibility between the EE existing laws of organizational dynamics and the case studies developed with success in the industry is pointed in [5]. The integration of the DSC concepts with the EE concepts allows the understanding, designing and engineering implementation of the enterprise dynamic systems control. The problem addressed by this paper - to design and implement EDSC capa- bilities in business transactions operating in a run-time organizational environ- ment, taking in account the misalignments between operational conditions and prescribed references as defined by the organizational models - will be solved tak- ing into account the scientific contributions of DSC and EE. The DEMO theory and methodology [6] that lies at the core of EE will be used in full to solve this problem. The solution consists in enforcing control in run-time business transactions using a bottom-up and top-down integrated approach. Organiza- tional control is a continuous orchestration of combined low-level and high-level control actions taken by the organizational actors. At operational level, the solu- tion checks misalignments between prescribed business transactions models and observed operations in the organization. These observations are used to trig- ger actions by the organizational control. Organizational control checks if the historical business transactions comply with the prescribed business rules. The control action results in changes in the prescribed business transactions models or changes in the business rules. In the first case of control action, the prescribed business transactions are changed to avoid the recurrence of unintended opera- tions. In the second case of control action, innovation is recognized as positive and the deviations from the prescribed transactions models are incorporated in the new prescription. In other words, the observed misalignment is valuated as being a more innovative way of operating the organization and thus it is used to define a new organizational prescription, in what constitutes in fact continuous organizational learning. Organizational control appears in different forms and acts at different levels throughout the distributed enterprise, e.g., actor’s qual- ification or business rules implementation, but in all cases, repeating a pattern of observation, decision and control actuation. The organizational control procedures in our solution are enforced using the concepts of business transaction and control. 48 S. Guerreiro, A. Vasconcelos, and J. Tribolet

A business transaction is a model representation of a given organizational real- ity that is valid within a specific timeframe. As proposed in Enterprise Ontology (EO) [6][7], a business transaction involves (i) actor role definitions, in order to specify who is responsible for each part of the transaction, who initiates it and who executes it, (ii) a transition space definition, and (iii) a state space defi- nition. Hence, actors are positioned at the core of this solution. Actors, which might be carbon-based or silicon-based, are autonomous and act according with their desires and interpretations of reality, for instance, in terms of personal interpretation, environmental change, requirements change or legal change. EO distinguishes the production acts from the coordination acts. A production act (P-act) contributes to bringing the goods and/or services (material or immate- rial) that are delivered to the environment of the enterprise. A coordination act (C-act) enters into and complies with commitments towards each other regard- ing the performance of the production acts. The P-acts and C-acts have effect in the correspondingly two separate worlds: the production world (P-world) and the coordination world (C-world). Moreover, the actors dynamically change the operational reality of the organization while they perform their activities. For this reason, the enterprise is considered as a dynamic system. When a business transaction is instantiated, at a single instant in time, it is called run-time. When the models are designed is called design-time. Control consists in the ability to drive, with a bounded effort, the operation of the enterprise towards a stable state whenever changes or perturbations occur. In the scope of an organization, control is performed implicitly and the overall organizational system maintains its stability involving all the actors, without a clear identification of which parts are controlled and which parts are controllers. Thus, our solution states that control (i) is not always either explicit or ana- lytical, as cybernetic control approaches are, (ii) it is not possible to predict all the business transactions conditions to control before execution due to the high number of possible combinations that could happen at run-time and (iii) the identified deviation from the stable state is sometimes incorporated as orga- nizational innovation. Control requires the capabilities of observation, decision and control actuation. The definition for decision is similar to the definition of enterprise governance proposed in [8][4]: ’...is the organizational competence for continuously exercising guiding authority over enterprise strategy and architec- ture development, and the subsequent design, implementation and operation of the enterprise...’. The same concerns of guiding an organization based in refer- ences and acting in the subsequent design, implementation and operation exists in the enterprise governance and in the decision counterpart of DSC theory. For clarification, this paper defines the boundary of the DEMO business trans- actions to enforce enterprise control. The research regarding enterprise dynamic system control must follow to other dimensions of the organization. The remaining of the paper is organized as follow. Section 2 defines the fol- lowed research methodology. Then, section 3 details the ontology to control the operation of the business transaction in an organization using the DEMO Enterprise Dynamic Systems Control 49 ontology. Section 4 discusses the obtained ontology. And finally, section 5 concludes the paper and points to future work.

2 Methodology

Organizational control is not a recentc concern, early in 1965, Emery and Trist [9] refer that a company is a open system where its behavior is only explained when analysed in conjunction with its interactions with the surrounding environment. Later, Hofstede [10], proposes that control should be formed and evaluated as a homeostatic1 model rather than a cybernetic model. Much more recently, Tri- bolet and Magalh˜aes [11] also state that agility and real-time reconfiguration capability [12] are requirements to the maintenance of the organizations. Also recently, Hoogervorst [8] states that the increasingly complexity is characterised by an increase that follows the size of organizations. Thus, precise models that are able to deal with this complexity without exploding in terms of size are needed. By other words, the models shouldbeabletofollow,atthesamepace, the increase in the complexity size of companies [13]. This research is based in a simplification of the design-science research (DSR) as proposed by Hevner et al. [14] and Winter [15]. The following steps were performed so far: (i) iden- tify the problem in the Enterprise Engineering domain using a simplified case study [16]; (ii) demonstration that no full solution exists for the case study supported by state of the art review with the following main focus [17]: Ac- cess control models [18], DEMO ontology [6], dynamic systems control [19] and Enterprise Governance [20]; (iii) usage of Enterprise Ontology to model a so- lution in the scope of Information Systems and Computer Engineering. Firstly, designing and implementing an EDSC solution. Then, verify and validate the design and the implementation of the solution using modal logics, simulations and case studies. Then, disseminating the contribution in the community, using technical reports, presentations and publications. And finally, learning from the interactions and restarting the researchflowtoEDSCredesign. The remaining of this paper presents the obtained EDSC design after a series of iterations of this research approach.

3 Enterprise Dynamic Systems Control Using DEMO

This section proposes an ontology to control the run-time business transactions modeled in the DEMO methodology [6]. The solution starts by identifying the dynamics of the business transactions in terms of their functional and construc- tional perspectives. The concepts of prescribed (or ex-ante2) model, observed

1 Homeostatic control model considers that there are a large number of interrelated cybernetic systems within an organization, executing different business services and working side-by-side which usually involves communication between Humans and machines. 2 The term ex-post is defined by the expression: ”after the event”. 50 S. Guerreiro, A. Vasconcelos, and J. Tribolet

(or ex-post3) operation, observation act, control act, time, control cycle and control competence layers are considered in the design of the control for the enterprise. The functional perspective is concerned with the behavior of a given function of a given system. Constructional perspective is concerned with the details that are included in a system that, in the end, allows the demonstration of its behavior. Using the two perspectives in complement, it is possible to have the identification of the desired behavior for the control and also the details that are needed to enforce it. The observation and control of the actor’s activity in the scope of the business transactions is enforced using access control concepts integrated with the DEMO business transactions concepts. The transition space and the state space of the solution are described using the DEMO ontology. The implementation is independent from the definition, representation and meaning of the mandatory concepts to control the operation of the organization. DEMO methodology encompasses 7 steps: first 4 steps are obtained by anal- ysis and the last 3 are obtained by synthesis. The sequence is relevant because the methodological process is strongly dependent on the previous steps. In the end, the essential ontology that is obtained allows a true and complete trace- ability between the enterprise’s concepts that could be shared by the different organizational actors. The deliverable of the DEMO methodology is a set of diagrams that are able to summarize the essential of an organization. Next sub- sections include the Transaction Result Table (TRT), then the most relevant Action Rules Specification (ARS) are pointed, afterwards the Object Fact Di- agram (OFD) specification and finally the Organization Construction Diagram (OCD) is depicted and explained.

3.1 Transaction Result Table Table 1 presents the transactions types and the correspondingly result types that are obtained when each transaction is completed successfully. These transactions are ontological. The infological and datalogical references are not considered at this stage. Four sets of transactions are identifiable with respect to DSC domain: 1. Ex-ante definitions regarding the business rules, the business transaction models and the accesses: T01, T02 and T03, 2. Management of the business rules, business transactions models and ac- cesses: T11, T12 and T13, 3. Control regarding the actual session, the accesses and the business rules: T05, T06 and T07, 4. Observation of the actual session: T04. Each transaction is valid regarding a specific period of time. It is interesting to notice that even at this early stage of the ontological design, the identified transactions consists in defining, observing, controlling and managing. Which are typical tasks performed in the scope, for instances, of the management of the software development process [21][22][23][24]. Figure 1 relates the different

3 The term ex-ante is defined by the expression: ”before happening”. Enterprise Dynamic Systems Control 51

Table 1. Transaction result table presenting the transactions types and the obtained result types

Transaction Type Result Type T01 Business rule definition R01 Business rule BR has been defined for period P T02 Model definition R02 Model M has been defined for period P T03 Access definition R03 Access A has been defined for period P T04 Observation of run-time session R04 Session S has been observed for period P T11 Business rule management R11 Business rules BR have been managed for period P T12 Model management R12 Model M has been managed for period P T13 Access management R13 Access A have been managed for period P T05 Run-time control R05 Session S has been controlled for period P T06 Run-time access control R06 Access A has been controlled for period P T07 Run-time business rule control R07 Business rule BR has been controlled for period P result types that are specified in the TRT. From right to the left, and from top to bottom, the following considerations are made. The result type R11 is related with result type R01 because of the management result of the business rules that implies the definition of a business rule. The same happens between the R12 and R02 and also with R13 and R03. The result type R04 which is the observed session is related with the controlled session and consequently with the access controlled (R06) and the business rule controlled (R07). The result R01 is related with the result R07 because the control of the business rules only occur when the business rules have been defined. The same happens between the R03 and R06 regarding the access. The same does not happen with R02 because run- time control is not concerned in controlling if the instances of the DEMO models are complaint with the DEMO transactional patterns specification. Indeed, this work is the research conducted regarding the DEMO processor by Kervel [25]. Within the EG boundary, in Figure 3, exists the responsibility for the obser- vation of the operation of the enterprise and to act when needed. In detail, the

R06 R11 R01 Access A has been Business rules BR Business rule BR has controlled for period P have been managed been defined for period P for period P R04 R05 R07 R12 R02 Session S has Session S has Business rule BR Model M has been Model M has been been observed for been controlled has been controlled managed for period P defined for period P period P for period P for period P

R13 R03

Accesses A have been Access A has been managed for period P defined for period P R01 R07 Business rule BR has Business rule BR been defined for period P has been controlled for period P

R03 R06

Access A has been Access A has been defined for period P controlled for period P

Fig. 1. Result structure of the result types obtained in the TRT of Table 1 52 S. Guerreiro, A. Vasconcelos, and J. Tribolet business rule manager (A01) is responsible to self-initiate the business rule defi- nition transaction (T01) and also to initiate the business rule management trans- action (T11). Similarly, the model manager (A02) is responsible to self-initiate the model definition transaction (T02) and also to initiate the model manage- ment transaction (T12). And finally, the access controller (A03) is responsible to self-initiate the access definition transaction (T03) and also to initiate the access management transaction (T13). The idea of having a self-initiate transaction is to enable the definition of the controller ex-ante references to be made by some- one. If no reference are established then no control can be performed. References are considered herein as the control bootstrap. The actuation is performed by initiating one of the following transactions: business rule management (T11), model management (T12) or access management (T13). From the EG kernel functional perspective, the control of the run-time business transactions is per- formed by observing all the process steps operated by the users (CA04) and when needed T11, T12 or T13 are triggered. The observation initiates the observation of run-time session transaction (T04). An user might be a person or a machine. Ontologically, transaction T04 means the connection of the EG kernel with the operation of a given business transaction that is complaint with a DEMO model. In practice, it means that observability is a mandatory requirement to enable EG. Once, the observation over the DEMO artifacts4 is established then control is a matter of evaluating the observations and deciding which is the correct action to be taken. Then, every business transaction execution that we want to control must be connected with the boundary of the EG. The idea, is that the coordination and production, acts and facts, keeps being executed outside the EG. Therefore, EG is observing the operation and acting accordingly with its predefined definitions that were made by the business manager, model manager and access controller. Moreover, the business transaction can only advance if EG allow it to ad- vance. By default, a negative-policy is enforced. The ontological solution for this requirement is based in the wait link available in the DEMO process model aspect. To further clarification at this stage, the transaction T04 is similar to the technological interceptor concept proposed by Sun Microsystems [26]: ”a thin layer of software that verifies every bean transaction but only acts over it whenever a precoded situation happens”. The elementary actor role Interceptor (A04) initiates T05 which is named as the run-time controller and that creates a new fact in the ontology that is ”Session S has been controlled for period P”. The run-time controller executes T05 initiating two parallel transactions: 1. run-time access control (T06), control if the access to the sessions should be granted or revoked, 2. run-time business rule control (T07), control if the ex-ante defined busi- ness rules are satisfied. 4 DEMO artifacts are considered, in this paper, as the basic constructs defined by the DEMO ontology. Enterprise Dynamic Systems Control 53

Listing 1.1. Action rule for the promise of transaction T06

1 when run−time access control of [Session] is promised 2 with user of [Session] is [User] 3 and role of [Access] is [Role] 4 and permission of [Access] is [Permission] 5 and staticconstraint of [Access] is [StaticConstraint] 6 and dynamiconstraint of [Access] is [DynamicConstraint] 7 and current time frame on [Period] 8 if [Role] is ElementaryActorRoleverified in [Role,DEMO:ElementaryActorRole] 9 valid within the current time frame on [Period] 10 and [User] is UserRoleverified in [User,Role] valid within the current time frame on [Period] 11 and [Permission] is Permissionverified 12 in [Role,Permission,DEMO:FactType,DEMO:ActionRule] 13 valid within the current time frame on [Period] 14 and [StaticConstraint] is StaticConstraintverified in [Role] 15 valid within the current time frame on [Period] 16 and [DynamicConstraint] is DynamicConstraintverified in [Role] 17 valid within the current time frame on [Period] 18 then run−time access control of [Session] must be executed 19 run−time access control of [Session] must be stated

The following DEMO artifacts are controlled: Elementary actor roles as specified in the ATD, Transaction kind as specified in the ATD and TRT, Action rule as specified in the ARS, Fact type and Object class and Result type as specified in the OFD. Transactions T06 and T07 are performed by the correspondingly actors: the run-time access controller (A06) and the business rules engine (A07).

3.2 Action Rules Specification

The promise steps regarding T06 and T07 are presented herein using the SBVR specification [27]. The actual observation of the T04 is only able to evolve if and only if all T06 and T07 are accepted successfully by T05. To start with, A06 is responsible to execute the run-time access control that is enforced between the user’s activity in the enterprise reality and its privileges restrictions that are ex-ante defined. Considering an ontological specification, the access control of the DEMO model instances is enforced with five consecutive verification steps. The access to the artifact of the DEMO model instance is only granted if and only if the user fulfills all these five steps successfully as depicted in Listing 1.1. The elementary actor role A07 is related with the capability of executing a set of business rules of the kind: if...then...else, as presented in Listing 1.2. Each rule encompasses a rule condition and a rule action. If the rule condition is TRUE then the rule action is triggered otherwise it is not triggered. In the case of more than one rule condition being TRUE at the same time, then the priority is used to only execute one rule action. The rule condition are calculated using the DEMO artifacts presented in the session.

3.3 ObjectFactDiagram

Regarding the applicability of the obtained state model, remark that the state model is not a database relationship model, neither an entity-relationship 54 S. Guerreiro, A. Vasconcelos, and J. Tribolet

Listing 1.2. Action rule for the promise of transaction T07

1 when run−time business rule control of [Session] is promised 2 with priority of [BusinessRule] is [Priority] 3 and rulecondition of [BusinessRule] is [RuleCondition] 4 and ruleaction of [BusinessRule] is [RuleAction] 5 do for all [RuleCondition] in [BusinessRule] 6 if TriggerCondition in [Session] valid within current time frame on [Period] 7 od 8 then run−time business rule control of [Session, RuleAction] with higher [Priority] 9 must be executed 10 run−time business rule control of [Session, RuleAction] with higher [Priority] 11 must be stated

diagram or an UML class diagram, but rather a conceptual presentation that would be used to be shared among the enterprise’s actors in order to exist an unique conceptual schema of a given world. In other words, the goal of a state model is to specify, in the OFD (Object Fact Diagram), the subjective inter- pretation of a given world using two concepts: (i) individual concepts and (ii) concept type. From the variables available at the TRT depicted in Table 1 the following fact types are identified: Business rule, regarding a rule that is en- forced in the run-time business transactions to react to an ex-ante condition; Model, regarding the DEMO business transaction model that is supposed to be followed. The model is used to enforce the security concerns; Access, regarding the ex-ante security concerns that are supposed to be followed and the ex-post restrictions that the security concern should satisfy; Session, regarding all the activities that are attempted by the users in the reality of the organization. All these fact types are related with another variable which is the period of time. The fact type Period is thus considered to bound the result type execution within the desired period of time. Figure 2 depicts the proposed overall OFD, it is based in the previous definition of the TRT, ATD and ARS.

3.4 Organization Construction Diagram

Figure 3 depicts the OCD of the EG ontology. Some few considerations are made regarding this model. An information link exists between A12 and T13 to obtain the access configuration from the DEMO model definition during the configuration phase of the references. The A07 has three information links to the T11, T12 and T13. They correspond to the control action that are taken when any misalignment occur. T11 corresponds to a self-change in a business rule, T12 corresponds to a change in the DEMO model to be controlled, it is expected to be performed by the model manager which is a person and T13 that corresponds to a change in the access management. A06 has an information link with the T13 because of the static and dynamic constraints that need to change the access management. Enterprise Dynamic Systems Control 55

4 Discussion

The main driver for this research started with a single statement that is followed by many practitioners and researchers: enforcing control in the activity of the organizations. In general terms, it is related with the ability to drive, with a bounded effort, the operation of the enterprise towards a stable state whenever occur changes or perturbations. This ability by its turns already exists in the DSC field. A DSC approach is composed of two mains parts: the controller and controlled process. Many times, control is considered as an isolated organizational component that reacts accordingly with the behavior of the system to be controlled. In practice, due to the organizational complexity, this approach is insufficient as long as the dynamic of the system to be controlled could not be fully specified. Having this problem in mind, our solution is inspired in the DSC but with a spe- cialized view, which is how to enforce control in the transactions that operates in a real run-time organizational environment, in order to face the misalignments between the operational conditions and the references defined by the organiza- tional models. In this way, this research effort is bounded to offer well defined scientific developments using a constructive and incremental approach. More- over, we consider that control is a matter of awareness, where individual actors

Period

R06 A P Access A has been controlled for period P R13 A P R03 Access A have been P A managed for period P PFT DEMO: Fact type Access A has been P is enforced in FT defined for period P DEMO: Action Permission A P PAR Rule Period The run-time permission P is enforced in AR of access is Permission DEMO: Business rule BR has been A RPC C PR Role The run-time RPC R is mapped in P AR R Elementary controlled for period P R is enforced in AR of access is RPC and constrained by C Actor Access A R Role Business rule BR has been P BR The run-time role U is mapped in R defined for period P R07 of access is Role and constrained by C P BR A URC C R U User The run-time URC R01 of access is URC Business rules BR have Business been managed for period P A C Constraint Rule The run-time constraint P BR of access is Constraint R11

Priority Static Dynamic Constraint Constraint

Behavior B P R The bbehaviorh B of R with priority P

R is composed R RL RCA of C and A R changes the RL

Rule Condition Rule Action

R is composed by O1, OR, O2 RO1ORO2 Model M has been S in DCID S in FTID S in T S in RLID S in AID S in UID Operand managed for period P MODEL R05 DEFINITION R04 PM Operator Session SP Period Model M T Period PS R12 T is the transaction in M Session S has been Session S has been controlled for period P observed for period P P M Model M has been defined for period P R02 DEMO: Transaction Kind

Fig. 2. Object Fact Diagram for governance enforcement in DEMO ontology: the over- all state space representation 56 S. Guerreiro, A. Vasconcelos, and J. Tribolet and collective actors creates the sense of awareness towards the need of control- ling, and then, the execution of their actions reveals the specific control actions that they perform in the reality. Usually, control in organizations is strictly con- sidered as a black-box perspective that lies inside the actors capabilities, and the models of the business transaction specifies what the actors should do. Then, the organization trust that control is tacitly implemented. Again, this paper, identi- fies that this perspective is valid but only represents a partial coverage of control in organizations. In a black-box perspective, control is thus only identified by the result of the actors in the reality which can only be seen as a whole but not by its parts. Thereafter, in this scope, this paper defeats that besides the capability of the individual and collective actors to decide and take control actions, also au- tonomous mechanisms of observing and acting should be completely understood by ontologies and then enforced in the operation of an organization. It is true, that actually, the capability to fine-grained control the access to the artifacts of an organization, or even, the capability to define and implement business rules, are most of the times, decoupled from the enterprise design. The practical consequence of this decoupling, is (i) the duplication of effort in the control and models design counterparts and (ii) with the designed models not aligned with control. Nowadays, a change in the control requires a change in the model design, and vice versa. Integrating the access control at the models design enables a fine-grained access control to the artifacts directly in the design with a perfect alignment that enables the continuous changes throughout time.

CPB17 CPB14 CPB16 CPB15

Enterprise Governance 1

Observation Business rule Business rule A01 A11 of run-time definition management run-time session control A04 T01 Business T11 Business T04 rule rules T05 Interceptor manager provisioner CA04

run-time User Model Model A05 access control A12 definition A02 management T06 Run-time T02 T12 Model Model controller provisioner CPB16 manager A06A0

Run-time Access T07 access definition A03 CPB18 A13 run-time controller T03 business T13 Access Access rule control controller Access provisioner management A07

Business rules engine

CPB15 CPB17

Fig. 3. Organization Construction Diagram for governance enforcement in DEMO ontology Enterprise Dynamic Systems Control 57

Moreover, this integration enables a full observability of the operation of the enterprise and thus allows the enforcing of business rules that are able to react in run-time based in the actual and historical observations. As a consequence of this, the business rules are kept as directions that are truly followed by the organization. Also, the separation of concepts between the controller and the controlled process should also be considered and precisely ontological specified if a real implementation is expected. If so, it is possible to (i) continuous observe the design restrictions of the run-time business transactions from the inside and then (ii) actuate with a change in the business transaction models when needed. In the limit, parts of the control could be performed by automatic systems rather than exclusively performed by actors. DEMO is used in this paper to argue about the enterprise’s ontology own proposal and also to specify a solution that could be used in any DEMO or- ganizational model. Despite this strong foundation in DEMO community we state that are not extending the DEMO meta-model but rather increasing the knowledge regarding control in the DEMO models. To summarize the reasons for our ontology are: Automatically configure the accesses,usingtheDEMO models itself. Avoiding all the effort related with the ex-ante access configu- ration, as presented in Listing 1.1 and by Access fact type in Figure 2. Only the users need to be related with their role(s), which from our understanding is the specific responsibility of each organization. Moreover, it is identified that EO do not cope with the concepts of access control. It is postponed for the implementation phases, however, access control is not an add-on that could be later added, as stated by ACM community, but rather something that should be included in the essential description of the organization, The business rules enforces high-order actuation in the operation of the organization, as pre- sented in Listing 1.2 . That is true, if exists a set of values in the Operand fact type that are derived from the Session fact type. Then, they could be used to validate the Rule condition and to trigger the Rule action. The objections are the following: the difficulty in designing ontological models for the enterprises, and the demand to use more case studies taken from the in- dustry to full validate this EDSC proposal. To conclude, from our point of view, the ontological modeler should always have in mind that besides using the on- tology to express the essence of the organization between different stakeholders, it should also be used to strongly found the software development. Moreover, a complete traceability between normalized EO and normalized software engi- neering [28] would optimize the deliverable of software cycles in enterprises.

4.1 Implementation Aspects Besides the presented ontological discussion, the implementation of EDSC is at this stage of the paper envisioned. The Session fact type plays a central role in the capability of observing what is being done in the operation of the enterprise. The implementation of an universal identification to all DEMO artifacts kept by Session allows a fine-grained controllability of each DEMO artifact involved in DEMO business transaction steps performed by the actors. Hence, a new 58 S. Guerreiro, A. Vasconcelos, and J. Tribolet transaction (T08) is proposed to deliver a result type of ”R08 Identification ID has been controlled for period P”. This proposed implementation is quite similar with a class concept developed in any object-oriented programming language, such as JAVA or C++. The instantiation of such a class is the act of giving an unique memory allocation, with its own data space where the properties of that object are stored. No other object is equal with the first one in terms of identity. Universal identifiers are postponed to this implementation phase, because they represent the instantiation of Figure 2 and not the EDSC concepts. Other issue that should be taken into account in the implementation is the large amount of data that is obtained from the observation (T04) of run-time business transactions. It is useful to decide upon the correct control action to take but places a huge computational problem. Future research should be done regarding this issue.

5 Conclusions and Future Work

Our DSR approach represents an effort for conceptualizing the control patterns that should be included in the design of the real systems that supports the organization. Moreover, the control concepts presented herein are directly re- lated with the EG area regarding the lower level of governance for a business transaction. For other aspects of the organization, other control layers should be further considered. The solution of this paper consists in enforcing control in run-time business transactions using a bottom-up and top-down integrated approach. Organizational control is a continuous orchestration of combined low- level and high-level control actions taken by the organizational actors. Run-time business transactions control is defined as the delegation capability of assuring that the responsibilities, competencies and authorities are being followed by the actors by the mean of the accountability and actuating in the predefined models. Accountability capability must be explicit considered in the design of the control of the organization, either considering it explicit or considering it implicit within the actors but with a clear separation of concern. Using DEMO, the confidence that is obtained is thus far more significant than with the approaches that are subjective and that leads the designer to a set of own decisions. In most of the cases, the results that are obtained suffer from mistakes and errors that should then be only identified while in development time. Regarding EG, we emphasize that it is not only a matter of guiding the au- thority over the enterprise strategy but also an extremely important matter of creating consistency between the design and the operation of the enterprise. Fo- cusing in this principle, we are able to present a solution that (i) clear identify the competence of the different atomic concepts that are included in a organiza- tional model either Human or machine based and, (ii) enforce the key activities of responsibility and accountability in that models and then that (iii) use the authority to change the models when needed. Lastly, besides the development of an EG approach to be used by the large enterprises, we believe that an open solution for the EG regarding the small and Enterprise Dynamic Systems Control 59 medium enterprises (SMEs) is a benefit that today it is not available at all. The effort needed to implement a complete solution encompassing business process, business rules and security enforcement is not reachable by many of the SMEs. Hence, the economical and financial impact of the knowledge introduced by this paper would be of great benefit to this kind of companies.

Acknowledgments. This work was supported by a PhD scholar- ship: SFRH/BD/43252/2008, and also by a national project: PTDC/CCI- COM/115897/2009, MOBSERV, Sistemas Facilitadores da Utiliza¸c˜ao de Servi¸cos por Dispositivos M´oveis, from Funda¸c˜ao para a Ciˆencia e a Tecnolo- gia, Minist´erio da Ciˆencia, Tecnologia e Ensino Superior, Portugal.

References

1. Ribeiro, M.I.: An´alise de sistemas lineares, vol. 1 e 2. IST Press (2002) 2. Kuo, B.: Automatic Control Systems, 7th edn. Prentice Hall International Editions (1995) 3. Franklin, G.F., Powell, J.D., Emami-Naeini, A.: Feedback Control of Dynamic Systems, 2nd edn. Addison-Wesley Publishing Company (1991) 4. Albani, A., Dietz, J., Hoogervorst, J., Mulder, H.: Enterprise engineering: the con- cise manifesto. In: CIAO network Meeting Minute, version 7 (2010) 5. Ven, K., Verelst, J.: The Adoption of DEMO: A Research Agenda. In: Albani, A., Barjis, J., Dietz, J.L.G. (eds.) CIAO!/EOMAS 2009. LNBIP, vol. 34, pp. 157–171. Springer, Heidelberg (2009), doi:10.1007/978-3-642-01915-912 6. Dietz, J.L.G.: Enterprise Ontology: Theory and Methodology. Springer (2006) 7. Dietz, J.L.G.: Architecture: building strategy into design. Nederlands Architectuur Forum. Academic Service (2008) 8. Hoogervorst, J.A.: Enterprise Governance and Enterprise Engineering. The Enter- prise Engineering. Springer Science (2009) 9. Emery, F., Trist, E.: The Causal Texture of Organizational Environments. Systems Thinking, Frederick Emery edition (1965) 10. Hofstede, G.: The poverty of management control philosophy. The Academy of Management Review 3(3), 450–461 (1978) 11. Tribolet, J., Magalh˜aes, R.: Engenharia Organizacional: das partes ao todo e do todoas ` partes na dial´ectica entre pessoas e sistemas. In: Ventos de Mudan¸ca. Editora Fundo de Cultura, Brasil (2007) (in Portuguese) 12. dos Santos, C.A.L.: Modelo Conceptual para Auditoria Organizacional Cont´ınua com An´alise em Tempo Real. PhD thesis, Universidade T´ecnica de Lisboa, Instituto Superior T´ecnico (2007) 13. Mannaert, H., Verelst, J., Ven, K.: The transformation of requirements into soft- ware primitives: Studying evolvability based on systems theoretic stability. Sci. Comput. Program. 76(12), 1210–1222 (2011) 14. Hevner, A.R., March, S.T., Park, J., Ram, S.: Design science in information systems research. MIS Q. 28, 75–105 (2004) 15. Winter, R.: Design science research in europe. Eur. J. Inf. Syst. 17, 470–475 (2008) 16. Guerreiro, S., Vasconcelos, A., Tribolet, J.: Adaptive Access Control Modes En- forcement in Organizations. In: Quintela Varaj˜ao, J.E., Cruz-Cunha, M.M., Put- nik, G.D., Trigo, A. (eds.) CENTERIS 2010. CCIS, vol. 110, pp. 283–294. Springer, Heidelberg (2010) 60 S. Guerreiro, A. Vasconcelos, and J. Tribolet

17. Guerreiro, S., Vasconcelos, A., Tribolet, J.: Enforcing control in the run-time busi- ness transactions. In: Proceedings of 5th International Conference on Research and Practical Issues of Enterprise Information Systems, CONFENIS 2011. Center for Industrial Production, Aalborg University, Fibigerstraede 16, DK-9220 Aalborg, Denmark (2011) ISBN: 978-87-91831-42-3 18. Sandhu, R., Ferraiolo, D., Kuhn, R.: The nist model for role-based access control: towards a unified standard. In: Proceedings of the Fifth ACM Workshop on Role- Based Access Control, RBAC 2000, pp. 47–63. ACM, New York (2000) 19. Ogata, K.: Modern control engineering. Prentice-Hall, Inc. (1997) 20. Hoogervorst: Enterprise architecture: Enabling integration, agility and change. In- ternational Journal of Cooperative Information Systems 13(3), 213–233 (2004) 21. Pressman, R.S.: Software Engineering, A practitioner’s Approach, 3rd edn. Mc Graw Hill Book Company, Europe (1992) 22. Sommerville, I.: Software Engineering, 8th edn. Addison-Wesley (2007) 23. Kandt, R.K.: Software Engineering Quality Practices. Auerbach Publications (2005) 24. IEEE15939, C.S.: Ieee standard adoption of iso/iec 15939:2007, systems and soft- ware engineering, measurement process. Technical Report 15939, New York, USA (2007) 25. Kervel, S.: Enterprise ontology driven information system engineering. In: Presen- tation Given at CIAO! (November 2009) 26. Sun, M.I.: Interceptors requirements jsr 318 enterprise javabeans tm. v3.1 Proposed Final Draft (February 2009) 27. OMG: Semantics of business vocabulary and business rules (January 2008), http://www.omg.org/spec/SBVR/1.0/PDF (accessed in June 2011) 28. Herwig, M., Verelst, J.: Normalized Systems: Recreating Information Technology based on Laws for Software Evolvability. Koppa (2009) A Study of the Patterns for Reducing Exceptions and Improving Business Process Flexibility

Sanetake Nagayoshi, Yang Liu, and Junichi Iijima

Tokyo Insutitute of Technology, Graduate School of Decision Science and Technology Department of Industrial Engineering and Management 2-12-1, Ookayama, Meguro-ku, Tokyo, Japan {nagayoshi.s.aa,liu.y.af,iijima.j.aa}@m.titech.ac.jp

Abstract. Exceptions are the events or situations that prevent business processes from completing normally. When exceptions such as cancellation of customer order occur, additional time and resources are often needed to resolve them. It is important for enterprise to pay attention to exceptions, for reducing exceptions efficiently and effectively may trace business process oriented improvement or innovation. In this study, a conceptual level pattern for reducing exceptions is proposed and discussed. This study contributes to research by 1) understanding how DEMO can help to reduce exceptions and improve business process flexibility through a case study of a Japanese company; 2) discussing suggestions for reducing exceptions and improving business process flexibility in general, 3) analyzing reasons of exceptions generating in the context of business model change from production centered to customer-centered, and how DEMO could help to enhance this change.

Keywords: Business Process Re-design, Exception, Process Flexibility, DEMO, Customer-centered Business Process.

1 Introduction

In computer science, an exception is an event that disrupts the normal flow of a computer program’s execution. In general, when a program encounters a situation that it cannot effectively resolve, an exception will be raised. An exception must be handled immediately or the computer program will be terminated. In the business world, exceptions also exist. Events such as cancellation of order and termination of contract are exceptions that prevent business processes from completing normally. For example, a salesperson would decline an order from a customer because his or her company does not offer the requested products and/or services. A customer might reject delivered products and/or services because the customer is not satisfied with the quality of the products and/or services. DEMO [1], a business process modeling methodology based on the Language Action Perspective (LAP) theory [2], defined exceptions as “decline of request”, “rejection of statement” and “cancellation of commitment” from communication theory perspective. Such exceptions prevent business processes from moving forward (e.g. entering into negotiation mode or finish mode) until they are handled.

A. Albani, D. Aveiro, and J. Barjis (Eds.): EEWC 2012, LNBIP 110, pp. 61–76, 2012. © Springer-Verlag Berlin Heidelberg 2012 62 S. Nagayoshi, Y. Liu, and J. Iijima

Handling exceptions incur extra time, managerial effort, and costs. For example, when a customer rejects delivered products and/or services, the salesperson in charge and his or her manager may need to take time to negotiate with the customer until an agreement is reached. Prior studies [3] also suggest that handling exceptions always increases time and cost incurred and reduces the efficiency of an organization. If exceptions are not handled effectively, the level of customer satisfaction might decrease. The causes of exceptions could be considered as for example: Reason (1) Lack of business capability to handle the request; Reason (2) Incomplete or inflexible business processes; Reason (3) Incomplete information sharing and communication; Reason (4) Improvable business processes. Although modifying or improving business processes cannot handle exceptions related to Reason (1), exceptions related to Reason (2), (3) and (4) can do be reduced. It is important to note that exceptions is still worth being specially focused, although they are sometimes regarded as normal parts of business process such as declining customer’s order. Because efforts on reducing exceptions might provide opportunities for improving the business process, furthermore triggering business process oriented innovation. Despite the importance of understanding exceptions, there is a lack of research on this topic. This study proposes an alternative methodology for analyzing and reducing exceptions based on DEMO [1]. Authors want to answer research questions like: How can we reduce exceptions from conceptual level modeling? The remainder of the paper is organized as follows: First, we review related researches in chapter 2. Then, authors generate hypotheses for reducing exceptions in chapter 3. Next, our study’s design and method are outlined in chapter 4. Analysis of case study based on DEMO and validation of our hypotheses is presented in chapter 5. Some additional findings are discussed in chapter 6. Finally, the limitations of this study and implications for future research are described in chapter 7.

2 Literature Review

2.1 Related Studies The capture and management of information about exceptions are described in David [3]. The study provided an idea of control organization by including the generation and operationalization of organizational artifact to solve dysfunctions. The study focuses on handling dysfunctions, which are automatically detected and addressed. Our study differs from David [3] in the point that we include exceptions that may not be automatically detected, such as a salesperson declining customer requests. We also try to identify some general patterns for reducing such exceptions to encourage process-oriented improvement as well as facilitating innovation. The few studies on the topic related with business process flexibility and adopt the workflow perspective [4], [5], [6], [7]. Flexibility is defined as the ability of business processes to respond to changes in their operating environment without necessitating a complete redesign of the underlying process definition [4].In most of these studies, business processes are realized by runtime-bounded activities [8]. Nataliya [4] A Study of the Patterns for Reducing Exceptions and Improving Business Process Flexibility 63 described flexibility in terms of four aspects: flexibility by design, flexibility under specification, flexibility by deviation, and flexibility by change. Among them, flexibility by design refers to “the ability to incorporate alternative execution paths within a process definition at design time allowing for selection of the most appropriate execution path to be made at runtime for each process instance depending on the circumstances encountered [4].” The other three studies related to business process instance run time bounding issues, will be omitted in this research since they are out of our scope. Expected exceptions can be handled easily when processes have high flexibility. However, authors argue that it is difficult to analyze exceptions from the workflow perspective because: (1) Workflow is an implementation level method, which is difficult to provide a complete view for analyzing the causes of exception. (2) Communication features such as commitment and feedback loop (e.g., decline, reject, cancel) are omitted in workflow perspective..

2.2 Ontological Model-DEMO

Ontological model is a model of system’s construction that is completely independent of the way in which it is realized and implemented. Implementation model is an implementation of ontological model by engineering process, which is not a matter of creativity but of craftsmanship.

Fig. 1. The role of ontology in the construction of a system

Unwanted exceptions are implementation level issues. However, it will be helpful for further understanding the reason of exceptions to find proven solutions by identifying whether it is an engineering oriented problem in implementation level or a construction-oriented problem on ontological level. DEMO [1] is an ontological model abstracted from all realization and implementation issues to show only the essence of the operation in an enterprise. It analyzes an enterprise as social entity that constructed of cooperate and responsible actor roles, as well as communicate and produce action sequences between the actor roles. Some key concepts in DEMO are specified as follows:

 Transactions: Transaction is defined in DEMO as a sequence of coordination acts and production acts between two actor roles that aimed at achieving a well-defined result. 64 S. Nagayoshi, Y. Liu, and J. Iijima

 Actor role: Actor role represents the operating unit of an organization, specified by its rule base. Actor roles are the initiators and executors of transactions.  Actor: Actor is the active element of an enterprise. Actor is authorized to fulfill actor role/roles by taking actor role’s responsibility and competence.  Action rules: Action rule is defined in Action Model in DEMO to guide the actors in dealing with their agenda. Authors argue that DEMO can become a good methodology because of its complexity reducing ability and human central specification, to analyze exceptions if it can be somehow extended an specified in implementation level as well. In practice, when exceptions happen, the actors who play the actor roles often have different authorities and follow different rules. At the same time, other actor roles may be involved in coping with or preventing from exceptions. Even if the transactions are not changed on ontological level, some changes might still occur: action rules might be modified; the authorities of actors who play the actor roles may change. Authors want to identify these changes in different model and examine how these changes can reduce exceptions in this research.

3 Hypotheses for Reducing Exceptions

Based upon our pre-research and amount of case investigation, authors generate three main hypotheses for reducing exceptions.

Hypothesis 1. Involve new transactions and corresponding actor roles in ontological level may reduce exception. Some exceptions are generated because the construction method of enterprise could not support the changing requirement in implementation level. Therefore, it may be useful to add new transactions into the current structure. We classify transactions into three types according to their functional difference, as follows: (1) Pre-decision/management Transaction: Internal transaction, which is somehow linked to the internal initiator of problem transaction to prevent from exceptions by pre-decision or management method. (2) Supportive Transaction: Internal transaction, which is added to the internal executor of problem transaction to prevent from exceptions by supportive functions. (3) New Service Transaction: Boundary transaction, which is added to the external initiators as some provided services. Internal transaction is moved to the boundary to provide additional services to the external parties. This is also a methodology for reducing exceptions by providing more services to the stakeholders. Based on the classification, authors generate three sub-hypotheses (shown in Table 1.) from above mentioned perspective: Hypothesis 1 (a). When initiator of transaction is inside boundary, add pre- decision/management type transaction inside boundary might reduce exceptions. A Study of the Patterns for Reducing Exceptions and Improving Business Process Flexibility 65

Hypothesis 1 (b). When executor of transaction is inside boundary, add supportive type transaction to the executor of transaction might reduce exceptions. Hypothesis 1 (c). Provide additional service to outsiders as a boundary transaction might reduce exceptions.

Table 1. Hypothesis 1: involve new transactions and actor roles to reduce transaction

Executor Assertion Initiator Assertion Initiator Executor Add to Add to Add to Add to Executor Initiator Executor Initiator External Internal H 1(a) H 1(c) n/a1 n/a2 Actor Actor Supportive New service H 1(b) Internal External n/a3 Pre-decision/ n/a4 n/a5 Actor Actor Management H 1(b) Internal Internal H 1(a) 2 Pre-decision/ n/a6 n/a Actor Actor Supportive Management

Hypothesis 2. Verify the Actor’s responsibility in implementation level may reduce exceptions.

An actor role represents the execution unit of a transaction, as well as the initiation unit of sub-transactions from the ontological level. However, actors who play the actor role in implementation level will bring different capabilities, accessible resources, and authorities into the practical process. This suggests that different actors who play the same role may reach different results even in the same ontological construction. Thus, authors generate two sub-hypotheses as follows: Hypothesis 2 (a). If there is an indeed authority expansion of the role with new action rules and increased responsibilities on ontological level, with which the previous actor could not fulfill. Then the adjustment and/or expansion of actors who play the role with adjusted and/or expanded authority may reduce exceptions. Hypothesis 2 (b). If there is no indeed authority expansion of the actor role on ontological level, the implementation level adjustment of actors who play the role

1 DEMO is focusing on inside boundary transactions. So we omit add executor to external actor roles. 2 An elementary actor does not allow being an executor of more than two transactions. 3 DEMO is focusing on inside boundary transactions. So we omit add executor to external actor roles. 4 No such case can be assumed. 5 An elementary actor does not allow being only an initiator. 6 It is assumed ‘self-initiate’ type of transaction, however it is not assumed that this type of transaction exists regarding the characteristic of exceptional transaction. 66 S. Nagayoshi, Y. Liu, and J. Iijima may also reduce exceptions if the actor takes helpful authority of the other actor role at the same time. For example, when a salesperson plays the actor role of order completer, he or she is more likely to decline an order when new products and/or services not offered by the company is requested because he or she only has the authority to sell existing goods and services. However, when a manager plays the role, since he or she can also play another actor role as production manager, he or she therefore has the authority to ask the developer to develop new products and/or services to reduce declines.

Hypothesis 3. Ensuring complete information in communication loop on implementation level might reduce exceptions. Exceptions often occur when information is not effectively shared among the right stakeholders or information used in communication loop is incomplete. Incomplete information for making the decision will make the commitment of communication loop invalid and causes exceptions. To ensure information completeness, it is important to clarify who will use what information at what time in the communication loop. However, the complementation is on implementation level, hence without any change on ontological level.

4 Research Design and Method

We employed the case study method [9], [10] and studied a single case. The unit of analysis consisted of a whole business process of a Japanese company named Sangikyo Corporation before and after business process redesign. We collected data through interviews of five representative officers and secondary data such as fifty two pages workflow diagrams from May 2011 to June 2011. The collected data were analyzed mainly by creating Actor Transaction Diagram (ATD). ATD is one of the six DEMO diagrams, which provides a method for analyzing the transactions in a company through abstraction and by reducing complexity. We analyzed the solutions of redesign one by one to justify our hypotheses for reducing exceptions. The analyses were validated in review meetings with the executives of the company.

5 Case Study

5.1 Company Description

Sangikyo Corporation was founded in 1965 as a company that deals with engineering services and/or goods for communication maintenance. Sangikyo Corporation has managed many large IT infrastructure projects for several major Japanese telecommunication carriers [11]. It currently has about 1,100 employees. The high- speed expansion led problems, such as more and more customers cannot be satisfied for their special requirement. To solve the problem, company shifted from product- centered to customer-centered to provide customized services in the business model. A Study of the Patterns for Reducing Exceptions and Improving Business Process Flexibility 67

Some exceptions occur because product-centered business processes are not suitable and flexible enough to support customer-centered business model.

Processes. Sangikyo Corporation operates three types of businesses. First type is related to “construction by contract.” When Sangikyo Corporation receives an order from customers, the company will design, construct, and purchase necessary materials and/or services from external constructors and/or vendors. These activities are usually carried out on the site of Sangikyo Corporation. After the construction is completed, the company requests the customer to inspect and accept the deliverables. When the customer accepts the deliverables, an invoice will be issued and payment will be requested. Second type is “on-site delivery.” This is different from the previous type in the point that tasks are carried out on the site of the customer. Third type is “supplying temporary service provider.” In this type of business, Sangikyo Corporation supplies the employees with specific skills and/or general skills for supporting customers’ activities. Customers who do not have enough or necessary staff to complete their activities will request Sangikyo Corporation for support.

Problems before Re-Design. While Sangikyo Corporation is expanding, the following problems have been hindering their growth: Increasing declines to customers’ requirement decreases customer satisfaction as well as company income: In a traditional production centered business process, a salesperson has the authority to focus on selling only existing products and/or services. When a new product and/or service is ordered, they often decline the order. A salesperson sometimes may ask the designers in the organization about the possibility of fulfilling the order. If the designer declines the request, the company will decline the customer. Occasionally, a salesperson may decline a customer’s order due their inability to understand the specification. For example, a salesperson may decline an order when he or she is not sure whether the skill of its dispatched workers can fulfill the request from customer. The company cannot detect the risks of promising to a request and it is important to avoid unnecessary risks: Traditional processes require project managers to depend on their personal knowledge. Without fully control the statue of its downstream, it may be risky to promise to a request if its stakeholders cannot fulfill the order in time. Managers need to control the issues and risks from multiple viewpoints, such as corporate management, operations, and project management. Meanwhile, the company needs to ensure high quality of their production and/or services.

5.2 Re-analyzing by DEMO ATD

Based on the data collected in our interviews, authors model the business processes in Sangikyo Corporation using ATD as shown in figure 2. Corresponding transaction result table is shown in table 2. 68 S. Nagayoshi, Y. Liu, and J. Iijima

Their problems are also analyzed with the ATD model and be concluded into six cases. All the cases have practical solutions, developed by their redesign process. We will re-consider these solutions from DEMO perspective to verify our hypotheses. The cases are classified by whether it is decline or rejection of a transaction.

Fig. 2. Comprehensive business processes of Sangikyo Corporation using ATD

Table 2. TRT table in Sangikyo Corporation

5.3 Solutions for Reducing Exceptions Based on ATD

Reducing Declines in Sangikyo Corporation. Case1 stands for internal executor’s decline in a transaction between an external actor and an internal actor: the initiator is an external actor and the executor is an internal actor. When a customer requests for a new product and/or service, which Sangikyo Corporation has never provided, or a A Study of the Patterns for Reducing Exceptions and Improving Business Process Flexibility 69 product and/or service that include specifications that are difficult to fulfill, the salesperson usually declines the order because the request is a kind of exception. In addition, when the salesperson is not sure whether the skills of the temporary servicer who will be assigned to complete the order can fulfill the specification, the salesperson also usually declines the order to avoid trouble resulting from the mismatch with the specification later. To reduce such declines, Sangikyo Corporation carried out the following solutions: Solution 1: Instead of allowing a salesperson to play the actor role (A01) and sell only existing products and/or services, a sales manager can propose what Sangikyo Corporation is capable of doing based on the request for proposal (RFP) from a customer plays the actor role. Solution 2: A sales manager asks a developer to develop the new product the customer requested. Analysis: Two of our hypotheses H1(b) and H2(b) are included. Firstly H1(b): a new transaction “T11”, initiated by actor role (A13) “production manager” for developing new products, is added on ontological level to prevent from declining customer order when ordered products do not exist. Secondly H2(b):when a salesperson plays the actor role of order completer, he or she is more likely to decline an order when new products and/or services not offered by the company is requested because he or she only has the authority to sell existing goods and services. However, when a manager plays the role, he or she at the same time plays another actor role as “production manager”, has the authority to ask for the development of new products and/or services and these solutions may therefore reduce declines on implementation level. Solution 3: Especially in case of providing temporary servicer (A11), a customer (CA01) verifies a temporary servicer to check whether they can fulfill their requirements. Analysis: An internal actor role (A12) is linked with customer for providing a new service to customer. Internal transaction is moved to the boundary to provide additional services to the external parties. This is also a methodology for reducing exceptions by providing more services to the stakeholders. Table 3 shows Case 1 and solutions. Case 2 stands for internal executor’s decline in a transaction within the organizational boundary. When a customer (CA01) requests an order with a specification that is difficult to fulfill, the order completer (A01) usually declines the order because the designer (A02) is likely to decline in T02. However, the following solutions for reducing the decline of the order from A02 are observed to be done in Sangikyo Corporation. Solution 4: The order completer (A01) asks a basic designer (A15) to do basic design and estimate the feasibility of the order before the designer (A02) make promise or decline for the order.

70 S. Nagayoshi, Y. Liu, and J. Iijima

Table 3. Case 1 and solutions

H1(a) H1(b) H1(c) H2(a) H2(b) H3 S2 S3 S1: Actor who plays 㻯㻭 㻜㻝 㻭㻜㻝 㻭㻝㻟 㼀 㻜㻝 㻻㼞㼐㼑㼞 㻼㼞㼛㼐㼡㼏㼠 㻯㼡㼟㼠㼛㼙㼑㼞 㻯㼛㼙㼜㼘㼑㼠㼑㼞 㻹㼍㼚㼍㼓㼑㼞 role “order completer” 㻮㼍㼟㼕㼏 Case 1 n/a 㻰㼑㼟㼕㼓㼚 n/a also plays n/a

㻭㻝㻠 another role 㻰㼑㼢㼑㼘㼛㼜㼑㼞 as “production manager”. R17: Temp Servicer R16: New production P is Result n/a TS is verified by n/a n/a n/a developed. customer.

Analysis: a pre-decision/management transaction (T18) is added to initiator of transaction T02, to prevent actor role A02 from generating exception (decline an order). Solution 5: An order completer (A01) requests for approval of the board to prevent the designer (A02) from declining a strategic deal. Some of the orders, for example larger than $10,000, could not be easily declined even if it is difficult for designer. In such situation, the board of committee in Sangikyo Corporation will decides whether the request from customers is acceptable or not, according to the basic designer’s estimation of the cost and feasibility for such orders. Analysis: Authors consider this solution as H2 (a), the expansion of actor role (A01) “order completer,” from {salesperson} to {salesperson, board}. It is an indeed expand of actor authority which change the responsibility of actor role A01.

Table 4. Case 2 and solutions

H1(a) H1(b) H1(c) H2(a) H2(b) H3 S4 S5: From {salesperson} to {salesperson, board} Rule change: if the Case 2 n/a n/a order> $10,000 then n/a n/a it could not be declined by designer but promised or declined by board.

R18. Feasibility of order O is Result n/a n/a n/a n/a n/a established.

A Study of the Patterns for Reducing Exceptions and Improving Business Process Flexibility 71

Case 3 stands for external executor decline a transaction: In case that initiator is internal actor and executor is external actor. A constructor (CA02) is required to construct by Sangikyo Corporation, but the constructor cannot always afford to fulfill the specificity, which may lead delayed-delivery to the customer. Solution 6: A constructor (CA02) asks detail information of the task and/or negotiates due date with Sangikyo Corporation in advance. Analysis: It is an implementation level complication of information in communication loop for transaction T06, in its order phase. Action rule and information requirement are specified in ontological level, however not implemented correctly. The information for making the promise is incomplete in the process before improvement. This incompleteness not only makes the commitment of communication loop invalid, but also causes exceptions. To ensure information completeness, it is important to clarify who will use what information at what time in the communication loop. Solution 7: A purchaser (A05) in Sangikyo makes an arrangement to share the tasks with another division inside Sangikyo Corporation. Analysis: It is an implementation level change, by which the information can be shared among necessary actors. This change is caused by an implementation choice, namely that one actor role is implemented by a collective of subjects (two divisions in the company, in this case) Solution 8: A purchaser (A05) in Sangikyo asks the constructor for a feasible proposal to fulfill the specificity. Analysis: This is also an information level complication of communication loop for transaction 06, in order phase. Action rule and information requirement are specified, however not implemented correctly. The information for making the promise is incomplete in the process before improvement. Table 5 shows Case 3 and solutions.

Table 5. Case 3 and solutions

H1(a) H1(b) H1(c) H2(a) H2(b) H3

Case 3 n/a n/a n/a n/a n/a S6/S7/S8

Result n/a n/a n/a n/a n/a n/a

Reducing Rejections in Sangikyo Corporation. Case4 stands for external initiator’s reject in a transaction between internal actor and external actor: initiator is external actor and executor is internal actor. A customer (CA01) rejects the state from Sangikyo Corporation due to the mismatch of the deliverables with the initial contract. The reason why such mismatch would often occur is that it is almost impossible to define the detail tasks, scope and schedule in advance, as one of the characteristics of the transaction between Sangikyo Coporation and the customers. 72 S. Nagayoshi, Y. Liu, and J. Iijima

Hence, the following solutions for reducing reject are observed to solve these issues between Sangikyo Corporation and the customers. Solution 9: Sales manager asks an internal auditor to ensure the quality to reduce the rejection from customer. Analysis: A supportive transaction (T19) is added to executor of transaction T01 to prevent from exceptions. A sales manager plays both “order completer” and “quality manager” in this case to ensure the quality of the order delivery. Table 6 shows Case4 and solutions. Case 5 stands for an internal initiator’s reject in a transaction inside the boundary. An order completer (A01) recognized that the deliverables would not fulfill the specification from the customer (CA01), the order completer (A01) usually rejects state from the designer (A02). However, the solutions for reducing the reject of the state are observed to be done in Sangikyo Corporation. Solution 10: A designer (A02) requests a proven and/or experienced designer to help improving the quality to fulfilling the specificity of the customer (CA01). Analysis: A supportive type transaction is added to designer (A02) to prevent from exceptions. Solution 11: A process manager is asked to do process improvement to ensure the design quality. Analysis: A pre-decision/management type transaction is added to prevent from exceptions. Table 7 shows Case 5 and solutions.

Table 6. Case 4 and solutions

H1(a) H1(b) H1(c) H2(a) H2(b) H3 S9

Case4 n/a n/a n/a n/a n/a

Result n/a R19. Quality of order O is audted. n/a n/a n/a n/a

Case 6 stands for an internal initiator’s reject in the transaction between internal actor and external actor: initiator is internal actor and executor is external actor. A purchaser for construction (A05) rejects the states from the constructor (CA02) due to the mismatch of the deliverables with the initial contract. As mentioned in case 4, the reason why these mismatch would often occur is that it is almost impossible to define the detail tasks, scope and schedule in advance, as one of the characteristics of the

A Study of the Patterns for Reducing Exceptions and Improving Business Process Flexibility 73 transaction between Sangikyo Corporation and the constructors. Hence, the following solutions for reducing the reject are observed to solve these issues between Sangikyo Corporation and the constructors.

Table 7. Case 5 and solutions

H1 H1 H2 H1(a) H2(b) H3 (b) (c) (a) S11 S10

Case5 n/a n/a n/a n/a

R21: Design Process PRO of Order R20: Design D for order O is Result n/a n/a n/a n/a O is improved. improved.

Solution 12: A purchaser (A05) requests the work planner to narrow the scope, reducing the price of the contractor (CA02) and/or change the task of the constructor (CA02) according to the ability. Analysis: A pre-decision/management type transaction T22 is added to purchaser (A05) to prevent from exceptions.

Table 8. Case 6 and solutions

H1(a) H1(b) H1(c) H2(a) H2(b) H3

S12

Case6 n/a n/a n/a n/a n/a

Result R22. Contract CT is planned. n/a n/a n/a n/a n/a

Through investigating the case study, we found that 1) Three of the exceptions is solved in implementation level by complementation of information in communication loop (S6, S7, S8), 2) Two of the exceptions are solved by expanding or verifying actor of actor role (S1, S5), 3) Seven of the exceptions are solved in ontological level by verifying the construction (S2, S3, S4, S9, S10, S11, S12). In these solutions, pre- decision and/or management transactions are always added to the initiator of the problem transaction to prevent from exceptions. In addition, supportive transactions 74 S. Nagayoshi, Y. Liu, and J. Iijima are accessed with the executor of problem transaction to expand existing solutions to prevent from exceptions. The result somehow proved that our hypotheses could be useful to analyze the exceptions by using DEMO methodology.

5.4 Efficiency of Using DEMO ATD

The workflow diagram of Sangikyo Corporation was described in fifty-two pages. For example T01: order was three pages, T02: design was two pages and T06: construction order was two pages. After applying ATD, a comprehensive description of the business process becomes only one page. ATD reduces by almost 90%.

6 Discussion

6.1 Business Model

A business model describes how a business positions itself within the value chain of its industry and how it intends to sustain itself, which is to generate revenue [12]. It includes strategy model, value model, revenue model, resource model in most of related researches [12]. As authors mentioned before, Sangikyo is shifting in the business model to obtain more revenue from providing customized service, which need organizational principle, structure and process new to product centered model. By analyzing the ATD of Sangikyo Corporation, we recognize that the responsibility of a salesperson (who plays the actor role A01 as the executor of transaction T01) before the improvement was only selling existing product. He or she only provided or received information from other related actor roles to complete the order. When a business model changes from production-centered to customer-centered, the actor role of A01 also changes from a task executor to a service provider. The biggest difference between these two is that a task executor needs to finish his or her assigned task passively while a service provider need to coordinate all the resources in order to provide the service actively. Although the name of actor role A01, “order completer” remains the same, the responsibility of A01 expanded from “selling products for completing the order from customers” to “selling products and providing possible services for fulfilling the requirements of customers”. Correspondingly, it required the actor who play the role owns more authority and better ability to coordinate more resources to actively provide services.

6.2 DEMO and Flexibility DEMO defined construction of system in ontological level. Business process flexibility is an implementation level concept, and the ability of business processes to respond to changes without necessitating a complete redesign of the underlying. This can also be expressed with ontological model and implementation model. Flexibility can be realized if implementation model can be linked with ontological model. A Study of the Patterns for Reducing Exceptions and Improving Business Process Flexibility 75

When an actor plays the actor role, he or she will bring his or her own resources, authorities and processes into the whole process defined as the ability of business processes to respond to changes in their operating environment without necessitating a complete redesign of the underlying. This may provide a bridge between ontological model and implementation model, hence realize business process flexibility.

7 Conclusion and Future Research

This paper explained how the DEMO methodology could be used for reducing exceptions in a company. Authors proposed three hypotheses and verified by 6 cases from the case study on a traditional Japanese company. Therefore, authors would like to call these hypotheses “patterns for reducing exceptions”. By re-analyzing the whole business process, problems, and solutions from the DEMO perspective, we identified that the three patterns could be helpful for reducing exception. Limitation of this research is that only six cases in one company are examined. Therefore, more researches should be performed to assess the quality of proposed patterns. Meanwhile, the patterns need to be assessed in more cases to address that the patterns are common reoccurring problems. Furthermore, authors analyzed why exceptions might occur. Specifically, we identified business model change from production-centered to customer-centered by analyzing actor change in implementation level and structure change in ATD in ontological level. Such changes may be an interesting research topic for future work. For example, “How will the ontological model and implementation model change when business model change?” We will examine these questions in future research.

Acknowledgement. The authors thank Sangikyo staff who kindly dedicated to our research works.

References

1. Dietz, J.L.G.: Enterprise Ontology: Theory and Methodology. Springer-Verlag New York Inc., New York (2006) 2. Winograd, T.: A Language Action Perspective on the Design of Cooperative Work. In: Proceedings of the 1986 ACM Conference on Computer-Supported Cooperative Work, Austin, Texas, pp. 203–220 (1986) 3. de Aveiro, D.S.A.: G. O. D (Generation, Operationalization & Discontinuation) and Control (sub) organizations: a DEMO-based approach for continuous real-time management of organizational change caused by exceptions, Doctoral Dissertation: Department of Computer Science and Engineering, Instituto Superior Técnico, Technical University of Lisbon, Portugal (2010) 4. Mulyar, N., et al.: Process Flexibility Patterns. Technische Universiteit Eindhoven (2008) 5. Bentellis, A., Boufaïda, Z.: Conceptual Method for Flexible Business Process Modeling. In: Proceedings of World Academy of Science, Engineering and Technology 27, 302–306 (2008) 76 S. Nagayoshi, Y. Liu, and J. Iijima

6. Keen, P.G.W.: The Process Edge – Creating Values Where It Counts. Harvard Business Press, New York (1997) 7. Regev, G., Wegmann, A.: A regulation-based view on business process and supporting system flexibility. In: Workshop on Business Process Modeling, Design and Support (BPMDS 2005). Proceedings of CAiSE 2005 Workshops, pp. 35–42 (2005) 8. Daoudi, F., Nurcan, S.: A benchmarking framework for methods to design flexible business processes. Software Process Improvement and Practice 12, 51–63 (2007) 9. Eisenhardt, K.M.: Building Theories from Case Study Research. Academy of Management Review 14(4), 532–550 (1989) 10. Yin, R.K.: Case study research: Design and methods, 2nd edn. Sage Publications (1994) 11. Sangikyo Corporation Website (November 20, 2011), http://www.sangikyo.com/ 12. Rogelio, O., Robert, K.: Managing the transition from products to service. International Journal of Service Management 14(2), 160–172 (2003) Benefits of Enterprise Ontology in Governing Complex Enterprise Transformations

Martin Op ’t Land1,2,3 and Jan L.G. Dietz2

1 Capgemini Netherlands, P.O. Box 2575, 3500 GN Utrecht, The Netherlands 2 Delft University of Technology, Delft, The Netherlands 3 Antwerp Management School, Antwerp, Belgium [email protected], [email protected]

Abstract. Enterprises increasingly execute complex transformations, such as mergers and splits, chain redesign, sharing and sourcing, and the rationalization of products, processes and applications. Its consequences are seldom sufficient- ly timely and completely discerned, while this is essential for governing such a transformation. Already in a small example we can see why Enterprise Ontolo- gy, as defined in DEMO (Design & Engineering Methodology for Organiza- tions) delivers a clear and valuable instrument for transformation governance. Especially DEMO’s Construction Model, which is the most abstract ontological aspect model, combines high expressiveness with a high Return On Modeling Effort (ROME).

Keywords: Enterprise Transformation, Governance, Enterprise Ontology, DEMO, Enterprise Engineering, ROME.

1 Introduction

Heraclitus’ saying “The only constant is change” (500 BC) [13] certainly applies to enterprises1. We observe an increasing need to perform better in “profit – people – planet”, especially in the recent economic crisis. Enterprise activities are shared, in- sourced, out-sourced, off-shored and back-sourced again. They split up and merge. After giving room for regional autonomy, application portfolio rationalization pro- grams are executed. All these attempt to save costs, improve quality and increase agility, which should ultimately lead to unique advantages in customer intimacy, product leadership and operational excellence [31]. The impact of such change-decisions is generally complex and large. Many stake- holders have to be reckoned with, the constraints and opportunities of laws and regulations have to be taken into account, and relevant parties in the chain need to be actively involved. The changes will not only affect products, processes and ICT2 ap- plications, but also the enterprises’ economy and organization. Therefore, such changes call for a well-governed enterprise transformation. To this end, a fundamental

1 We use the term “enterprise” for any goal-oriented cooperative of people. 2 ICT stands for Information and Communication Technology.

A. Albani, D. Aveiro, and J. Barjis (Eds.): EEWC 2012, LNBIP 110, pp. 77–92, 2012. © Springer-Verlag Berlin Heidelberg 2012 78 M. Op ’t Land and J.L.G. Dietz and essential insight in organizations is needed, such that these transformations be- come intellectually manageable. Enterprise Ontology, as adopted in DEMO3 [11], reveals the essential, deep struc- ture of an organization. A series of case studies [e.g., 16, 22, 23] of real-life reorgani- zations, organizational splits, post-merger integration and application portfolio rationalization has been published, in which DEMO is the core modeling method to support decision-making. These studies also report a tremendous ROME (Return On Modeling Effort). We found particularly that DEMO’s systematic and reproducible abstractions from the realization and implementation of organizations are beneficial. Taking OMG’s EU-Rent Case [20, 18] as an example, we will illustrate the identified benefits and make plausible that applying DEMO provides the required understanding for intellectually manage enterprise transformations, and to do this in 10% of the time commonly used. The remainder of this paper is structured as follows. Section 2 categorizes impact of change in enterprise transformation and presents requirements for better gover- nance of transformations. Section 3 briefly introduces DEMO and its underlying PSI- theory, and hypothesizes causes for the achieved benefits. In section 4 we discuss these hypotheses, using the EU-Rent transformation example. Finally, section 5 pro- vides the conclusions as well as directions for further research.

2 Enterprise Transformation – Needs for Improvement

Rouse defines enterprise transformation as a “… fundamental change that substantial- ly alters an organization’s relationships with one or more key constituencies, e.g., customers, employees, suppliers and investors” [26 p279, italics ours]. But what makes a transformation fundamental? For example, firing 40% of your people can add value from the perspective of the organization striving for operational. Is this a fun- damental change? For the people involved, this will certainly be the case. For the organization the change could be large – e.g. when locations or operating countries are shut down, or complete products are retired. But the change could as well be small – keeping the product portfolio and the processes the same, just operating at a lower volume with the same mechanisms. In his Law of Requisite Variety, Ashby [1] states that each system has to deal with complexity – expressed in variety - in its environment, answering it by sufficient in- ternal variety. Beer [4] elaborates then how organizations should deal with complexity to stay viable. His Viable System Model (VSM, summarized in Table 1) states that each viable system – autonomous system, adaptable to its environment – (1) is recur- sive and (2) is composed of five interacting subsystems (see Fig. 1), of which the highest level has the lowest variety. Using VSM, one can now order typical changes on a scale from low-impact (and frequent) to high-impact (and few) – the latter ones we consider to be fundamental.

3 Design & Engineering Methodology for Organizations (www.ee-institute.com) Benefits of Enterprise Ontology in Governing Complex Enterprise Transformations 79

To what extent are fundamental enterprise transformations successful? Many en- terprises have undertaken transformations, only some flourished [26 p292]. Charan & Colving estimate [6] that 70% of CEO-firings are caused by not getting their enter- prise to implement agreed upon and reasonable strategies. As another example, in spite of the popularity of Mergers & Acquisitions [8], researchers commonly [24] suggest that approximately half of all M&A have proven unsuccessful.

Table 1. The five systems of the Viable System Model (VSM) - summary content example 1 Primary or production system; to deliver changes impacting the daily primary operations, products and services to its environment. such as solving an unexpected customer complaint, trying to speed up one order 2 Coordination, by mutual adjustment be- (re-)scheduling resources such as people and space, tween the Systems 1, to prevent oscillation; so that not all pupils try to have Math in the same e.g. by scheduling, common standards, room, while the Chemistry teachers have nobody to procedures etc. teach 3 Control or Cohesion, manages resources given that we still are delivering the same products to (men, materials, machines, money) and the same markets, resources are re-assigned to any- performance requirements of Systems 1. how perform, or the performance-targets are System 3 is supported by System 3* Audit adapted or Monitoring (sporadic, in-depth). Focus: “Are we doing the things right?” 4 Intelligence or Future, looking outwards to new products or services are proposed, or current the environment to understand how the products or services are going to be delivered with a organization needs to adapt in order to stay different quality, or products & services are viable. Focus: “are we doing the right retired things?” 5 Policy or Identity, balancing current and contemplating our identity, we decide we should no future demands of the organization. longer stay an airline company, but gradually and controlled become a connector of people

Rarely is the impact of the intended change discerned sufficiently timely, coherent- ly and completely. This has a destructive impact on many stakeholders. Indeed, the lack of shared objective insight gives rise to speculations, interpretations, unnecessary polarizations and the unintended overlooking of stakeholders and their interests. On one hand stakeholders know that providing enough time for building support and buy- in is essential for a successful transformation. On the other hand they feel pressure for fast decisions to protect personal positions or to be able to give well-founded answers to customer markets, stock exchanges and labor unions. As a consequence decision- making often tends to oscillate between slow moving and ad hoc.

80 M. Op ’t Land and J.L.G. Dietz

Fig. 1. Subsystems of a viable system, according to the Viable System Model (VSM) [11]

Therefore, to make the fundamental change of enterprise transformation successful, good governance needs to be in place, using an enterprise transformation dashboard [21, 12]. First and foremost, this should be derived from the goals of the enterprise transformation, by clear answers to questions like “what are the intended benefits and the exploitation costs” and “what durability, scalability and sourceability should we aim for”. Next to that, guidance is needed on the process of the enterprise transforma- tion, monitoring transformation costs, duration and risks. Thirdly, the basis of all this is a shared and objective insight in the content of the enterprise transformation. Ap- plying de Leeuw’s governance paradigm [15] with “enterprise transformation” as the target system, several authors propose [21 p29, 12] to use a dashboard as a means for such an informed governance for enterprise transformation, containing at least (1) indicators – e.g., models, views, performance measurements – giving insight into the enterprise's current state, the enterprise's current performance, the enterprise's future (expected) performance, and the (selected) direction and progress of its transforma- tion processes, and (2) controls – e.g., (enforced) reference models, design principles, standards – allowing the transformation processes to be influenced, such as the enter- prise's desired future state, plateaus of intermediary stages and overall regulations. To enable coherent and consistent enterprise (re)design, resulting in unified and in- tegrated enterprise operations, we propose as extra requirements for this dashboard: • it should give an holistic view of the enterprise, clarifying coherence between its components; • the views should be necessary and sufficient to evaluate different future implemen- tations – with each different people/organizations and different (a/o ICT-) means; Benefits of Enterprise Ontology in Governing Complex Enterprise Transformations 81

• therefore implementation-independent views of the enterprise should be available, allowing for mapping or comparing different implementations of the enterprise; • finally, making and maintaining the enterprise views should be cost-effective in relation to the issues to be solved or prevented; i.e., the views should have a good Return on Modeling Effort (ROME).

3 The DEMO Methodology

A complete, so-called essential model of an organization consists of four aspect mod- els: Construction Model (CM), Process Model (PM), Action Model (AM), and State Model (SM). The CM specifies the composition, the environment and the structure of the organization. It contains the identified transaction types, the associated actor roles as well as the information links between actor roles and transaction banks (the con- ceptual containers of the process history). The PM details each transaction type ac- cording to the universal transaction pattern. In addition, it shows the structure of the identified business processes, which are trees of transactions. The AM specifies the imperatively formulated business rules that serve as guidelines for the actors in deal- ing with their agenda. The SM specifies the object classes, the fact types and the dec- larative formulations of the business rules. Let us briefly introduce the concepts of the CM and the way in which it is represented (Fig. 2). A Construction Model shows the network of identified transac- tion types and the corresponding actor roles. E.g., transaction type T01 delivers a business service to actor role A00. A00 is called the initiator (consumer) and A01 the executor (producer). The executor of a transaction is marked by a small black di- amond on the edge of the actor role box. The solid line between A00 and T01 is the initiator link; the solid line between A01 and T01 is the executor link. Fig. 2 also shows that some other actor role (A07) needs to have access to the history of transac- tions T01 (production facts as well as coordination facts (e.g., status “requested”, “promised”, “stated”, “accepted”)). This is represented by the dashed line between A07 and T01.

S01: S01 system border A07

T07 actor A07

transaction T07

A00 A01 T01 actor A00 actor A01

transaction T01

Fig. 2. Typical constructs of a DEMO Construction Model 82 M. Op ’t Land and J.L.G. Dietz

We now want to hypothesize the next benefits of DEMO, compared to common current modeling approaches such as BPMN [19]: • It offers a significant reduction of complexity (over 90% in terms of the size of documentation); • It is an instrument for detecting tacitly performed coordination acts. In order to test the hypotheses, we will first model EU-Rent, OMG’s standard SBVR- and BMM-example ([20, 18]), in its current situation with DEMO. Then we will compare the DEMO model with a common way of process modeling. Finally, we will model a transformation for EU-Rent in DEMO, namely the introduction of loyalty rewards, and explain the use of DEMO in governing this transformation. The next narrative description applies: EU-Rent is a company that rents cars to persons, operating from geographically dispersed branches. The cars of EU-Rent are divided in car types (brands and mod- els); for every car type there is a particular rental tariff per day. A car may be rented by a reservation in advance or by a ‘walk-in’ customer on the day of renting. A rental contract specifies the start and end dates of the rental, the car type one wishes, the branch where the rental starts (called the pick-up branch), and the branch where the rental will end (called the drop-off branch). Rentals have a maximum duration. The person who rents the car is called the renter. The one who is going to drive is called the driver. A rental will only be started if the driver has a valid driving license. In addition, a car of the requested type must be available. As soon as the car of a rental has been dropped-off, the rental can be ended, after the incurred charge has been paid. This charge may consist of several elements. First, there is the basic charge (number of days times the tariff per day). Next, there may be a penalty charge for exceeding this duration (number of extra days times the late return penalty tariff). Lastly, a location penalty charge is added if the car has been dropped-off at another branch than agreed (this charge depends on the distance be- tween the branches). Apparently, the relevant unit of service of EU-Rent is the rental of a car for some period. In the case description this notion was already designated by “car rental”. The rental of a car is a space-time notion, like e.g. the loan of a book from a library, or the rental of a hotel room. Basically, it is the right to use a space-bound service for some time. The usage of such a service has to be started and to be ended explicitly. So, we identify two transaction kinds in the B-organization of EU-Rent, which we will call rental start (B-T01) and rental end (B-T02). The transaction results are re- spectively “[rental] has been started” (B-R01) and “[rental] has been ended” (B-R02). In the formulation of these results “[rental]” is a placeholder for concrete individual instances of the type rental. By convention, the executor of B-T01 gets the actor role number “B-A01”; let us call this actor role “rental starter”. Similarly, the executor of B-T02 is designated by “B-A02”; let us call it “rental ender”. Moreover, we call the initiator of both B-T01 and B-T02 “renter”; let us give this external (and by conven- tion composite) actor role the number “B-CA01”. In the period between the creation time of B-R01 and the creation time of B-R02 of a rental, the rental is considered to

Benefits of Enterprise Ontology in Governing Complex Enterprise Transformations 83 be alive. It means that during the lifetime of a rental, B-CA01 (the renter) has the right to make use of the rented car. Note that booking in advance seems to be a sepa- rate transaction but it is not. Booking in advance means only that the requested crea- tion time of B-T01, i.e. the contracted start date, is some time in the future. When the rental start is promised, the rental starter will proceed with requesting the driver to pick up the selected car at the contracted pick-up branch (B-T03), as well as to drop off the car at the contracted drop-off branch on the contracted end date (B- T04). So, the initiator of B-T03 and B-T04 is B-A01. The executor of B-T03 as well as the executor of B-T04 is an elementary actor role within the (external) composite actor role B-CA02, which we will call “driver”. At some time, the driver will drop-off the car at some branch, and the renter will subsequently request to end the car rental. Before completing the rental end (B-T02), however, the costs of the rental have to be paid. So, we identify the last transaction kind, B-T05 (rental payment). The initia- tor is obviously B-A02 (rental ender) and the executor is (by convention) the elemen- tary actor role B-A05 within the external (composite) actor role B-CA03, which we will name “payer”. When the renter initiates the rental end (B-T02) the rental ender will check whether the car has been dropped off, i.e. whether the car drop-off has been accepted. Note that it may be the case that B-T05 will not be initiated at all because the car pick-up (B-T03) has not been executed! Although strange of course, this may happen. The normal case, however, is that the car has been picked-up and been dropped-off. As soon as B-T05 is accepted, B-T02 will be continued and completed. Fig. 3 shows EU-Rent’s Construction Model (CM), Table 2 is its Transaction Re- sult Table (TRT). The executor of a transaction is marked by a small black diamond on the edge of the actor role box. The other linked actor role is the initiator.

Table 2. Transaction Result Table EU-Rent, current situation

Transaction kind Transaction result B-T01 rental start B-R01 [rental] has been started B-T02 rental end B-R02 [rental] has been ended B-T03 car pick-up B-R03 the car of [rental] has been picked-up B-T04 car drop-off B-R04 the car of [rental] has been dropped-off B-T05 rental payment B-R05 [rental] has been paid

From the action rules (not discussed here) we derive the information links (dashed lines) in the CM. It means that the actor role is allowed to access the contents of the connected C-bank and/or P-bank. Note that there are two external P-banks; they con- tain facts that are the result of transactions outside the boundary of the organization we focus on (the bold grey rectangle named “EU-Rent”).

84 M. Op ’t Land and J.L.G. Dietz

personal B- B- EU-Rent data APB02 APB01 data

EU -Rent

B-CA01 B-A01 B-CA02 B-T01 B-T03

rental rental start car pick -up starter driver

renter B-T04

car drop -off B-A02 B-T02

rental B- rental end ender APB01 B-CA03 B-T05 EU-Rent payer data rental payment

Fig. 3. Construction Model of EU-Rent, current situation

Fig. 4 reuses and shows a Business Process Diagram (BPD) according to the OMG-standard Business Process Modeling Notation (BPMN) [19], elaborated for the same case EU-Rent [18, 20], for the business process “advance reservation” [27 p89]. How does this BPD deal with the identified coordination acts? In the diagram we noticed two of them explicitly, namely the request (“rental request”), the reject (“re- jection”) and the accept (“accept payment”). For many other coordination acts, we are left more or less guessing if they are implicit, asking questions such as “is the accept of the rental request embodied in the hand-over of the paper rental contract?”, “is the pick-up of the car always promised & stated (even if the driver appears to be drunken and unable to show his driver’s license)?” and “is payment of the car ever requested, promised etc.?”. So, a BPD like the one made in BPMN does not enable checking the completeness of transactions. How does this BPD deal with infological and datalogical aspects? As infological examples, it shows calculations, such as “calculate price” and “assign car”. On the datalogical level, it shows a “rental contract” and an “invoice”. We are now left guessing to what extent this BPD is complete here. For instance, are no calculations done elsewhere, such as “calculate credit risk” in deciding whether to accept the ren- ter? Or when the car has been damaged, will a damage report be made, recorded in EU-Rent and a copy been given to the customer? Again, a BPD like this does not enable checking for completeness of I- and D-actions.

Benefits of Enterprise Ontology in Governing Complex Enterprise Transformations 85

Fig. 4. Business Process Diagram “advance reservation EU-Rent” [27 p89]

What signs of organizational and ICT-implementation do we see in the BPD? By using “swimming lanes”, the BPD clearly shows the way how the business activities are organizationally embedded – in this example a geographical unit (London) and three departments within such a geographical unit. If the organization changes – e.g., by outsourcing the car logistics and merging the sales and the accounting unit –, all diagrams need to be changed here as well. Also the ICT- and paper-based implemen- tation are shown by texts ({IT-support = …}) and symbols in the BPD. When such an implementation changes, e.g. by electronic invoices and contracts or fully-automated damage-checking, the BPD needs to be changed. The BPD shows a clear order of working for all people involved. This also means that the BPD has to be changed the moment the order of working changes, e.g. when we decide to ask for a partly payment in advance to decrease the amount of no-shows. 86 M. Op ’t Land and J.L.G. Dietz

Finally, it is difficult to determine whether this BPD is consistent. E.g., by making no distinction between renter and driver, we run the risk that we ask the driver to be credible and the renter to have a driver’s license, which should be, as you will notice, the other way around. Also, by making different processes for “walk-in rental” and “advance reservation” we introduce an opportunity for unintended “unequal treat- ment” between a renter in these two scenarios [cp. 27 p85], while probably uniform processes were meant. From our consulting practice, we sometimes notice user-appreciation of the BPD because it clarifies for all executors of a process the order of working and the current organizational and ICT-implementation. At the same time, our analysis shows several disadvantages of using a BPD for the purpose of governing transformation, because (1) completeness of coordination acts, and thereby completeness for the whole chain of actors and services cannot be checked, (2) completeness of infological and datalog- ical actions cannot be checked, (3) order of working is fixed, and (4) all organization- al and ICT-implementation choices are “hard-coded”.

4 Modeling EU-Rent’s Transformation

EU-Rent provides car rental service across Europe and North America for both busi- ness and personal customers. It operates nation-wide in each country of operation, focusing on major airports, competing head-to-head, on-airport, with other premium car rental companies such as Avis and Hertz. EU-Rent wants to improve customer satisfaction by industry-leading customer ser- vice, well maintained cars and by having vehicles available for rental when and where customers expect them. This should contribute to external recognition of EU-Rent as ‘premium brand’ and to top ratings by parties such as A C Nielsen. EU-Rent herself monitors her progress in this area by a quarterly customer satisfaction survey. As part of the customer satisfaction improvement program, EU-Rent has decided to introduce an attractive loyalty rewards scheme for frequent renters during 2012-H1. Frequent renters should become rewarded by EU-Rent with loyalty credits, especially when they extend their rental. Also customers should be able to spend loyalty credits at EU-Rent in special offerings, such as “three-days-for-the-price-of-two” or simple discounts. In her strategy, EU-Rent has also decided to join an established rewards scheme run by a third party – i.e., outsource rather than building own scheme.

Table 3. Transaction Result Table EU-Rent: extra transactions for future situation

Transaction kind Transaction result B-T06 credits awarding B-R06 credits for [rental] have been awarded B-T07 credits cashing B-R07 credits for [rental] have been cashed

Benefits of Enterprise Ontology in Governing Complex Enterprise Transformations 87

special B- personal B- B- EU-Rent offers APB03 data APB02 APB01 data

EU-Rent

B-CA01 B-A01 B-CA02 B-T01 B-T03

rental rental start car pick -up starter driver

renter B-T04

car drop -off B-A02 B- EU-Rent B-T02 APB01 data rental rental end ender B-CA03 B- special B-T05 APB03 offers payer rental payment

B-CA05 B-CA04 credits B-T07 B-T06 credits casher awarder credits cashing credits awarding

Fig. 5. Construction Model EU-Rent, future situation with loyalty credits

Wiser from some previous experiences, the CEO of EU-Rent wants to ensure integral governance before giving the final go for the loyalty rewards project. First of all, she wants to have a better insight in the ToBe-situation: what does it mean for the organization, the personnel, the ICT, the way of cooperation with third parties and the exploitation costs versus the extra business this should create for EU Rent. Also she wants to have an insight in the transformation involved: what migration should be undertaken, what are the risks, what are the transformation costs and what is the ex- pected duration. And finally she wants to have an understanding about the evolvabili- ty of the solution, e.g. would it be possible to start with a “EU-Rent only” earning and spending of loyalty credits and then broaden it to save and spend loyalty credits with other parties as well – or the other way around. With a similar line of reasoning we build the DEMO CM for the new situation, for which Fig. 5 shows the new complete CM (changes marked in purple) and the TRT in Table 3 shows the additional transactions. The renter (B-CA01) will be informed on special offers (B-APB03), such as discounts or extra loyalty rewards. The same in- formation will be needed by the rental ender (B-A02), when (s)he has to ask for the 88 M. Op ’t Land and J.L.G. Dietz right amount of money to be paid (B-T05), of which a part can be paid by cashing loyalty credits (B-T07). By the rental, the renter can also earn credits (B-T06). From Fig. 5, we now can answer several questions asked by EU-Rent’s CEO. First of all we immediately see several new B-actor roles appear, namely the credits awarder (B-CA04) and the credits casher (B-CA05). Next, the appearance of the new fact-banks credits awarding (B-T06), credits cashing (B-T07) and special offers (B- APB03) introduces also new D-actor roles, responsible for recording, distributing and copying data from these three fact-banks, such as the recording of special offers in B- APB03. And finally we see I-actor roles appear for each new explicit (dashed) or implicit (solid) information link in the CM, such as giving selections from special offers (B-APB03), directed towards specific customers, regions or periods. For each of these actor roles we can consider and compare several alternative orga- nizational implementations such as, for instance, the alternative “outsource loyalty rewards scheme” versus “build own loyalty rewards scheme”. Each alternative puts up another organization border, thereby creating another cooperation with parties, ultimately resulting in other future contracting [23 pp77-92]. Looking back at the questions of the CEO, we see we have now answered some of her questions about the ToBe-situation, namely “what does the transformation mean for the way of cooperation with third parties and for the organization”. In order to answer the “consequences for personnel and ICT”, more insight in Quality of Services is needed – then also the exploitation costs can be estimated, as well as the transfor- mation consequences (content, risks, costs, duration). “The extra business this should create for EU Rent” should be derived from market research, not from the CM. Finally the question about the evolvability of the solution, e.g., would it be possible to start with a “EU-Rent only” earning and spending of loyalty credits and then broa- den it to save and spend loyalty credits with other parties as well – or the other way around. The CM clarifies here that in a situation of outsourcing the loyalty rewards scheme this is a matter of a different Service Level Agreement (SLA) with the “loyal- ty rewards service provider”. In this SLA agreement should be reached about which credits awarded elsewhere should “count” for EU-Rent and the other way around. In case of insourcing the loyalty rewards scheme, all these considerations should be brought into scope and elaborated.

5 Conclusions and Further Research

As main characteristics of using DEMO and its Construction Model (CM) we found: 1. it ensures completeness in unambiguously discerning all activities – business, info- logical and datalogical – required to deliver a certain product or service; 2. this in turn helps considering and comparing different implementations of these activities and their executing actor roles in organizations, people and automation; 3. the models are able to express “just in time, just enough detail”; 4. making the models is possible with an attractive ROME.

Benefits of Enterprise Ontology in Governing Complex Enterprise Transformations 89

The first three characteristics are caused by three parts of the Ψ-theory, namely:

• the distinction axiom, stating that “there are three distinct human abilities playing a role in the operation of actors, called performa, informa en forma”; applied as a means for abstraction to the performa (“business”) level, it offers a significant re- duction (at least 70%4) of complexity; applied as a means for concretion, it ensures completeness in discerning responsibilities in information provision (infological actor roles) and data governance (datalogical actor roles); • the implementation notion, stating that an organization should be made operational by means of technology, being organizations, individual people and other (a/o ICT-) means; applied as a means for abstraction, it offers the opportunity to look across current or envisioned organizations and other means; applied as a means for concretion, it offers the opportunity to compare many different implementations, first in terms of people, functionary types, organizations, next to that also in several ambition levels of automation; • the transaction axiom, stating that “coordination acts (C-acts) are performed as steps in universal patterns”; applied as a means for abstraction to the level of trans- actions, it offers another significant reduction (at least 70%5) of complexity; applied as a means for concretion, it ensures detecting all C-acts, also the ones cur- rently performed tacitly.

The fourth characteristic, an attractive Return On Modeling Effort (ROME), is caused by simultaneous abstraction according to the distinction axiom and the transaction axiom, as is done in DEMO’s Construction Model. Its effect is a reduction of at least 90% of the time commonly used (the earlier mentioned 30%*30%, confirmed by practices such as the SGC-case [16 p77] which even mentions 95%), and a result that has a greater power of expression for evaluating implementation alternatives than commonly used – such as in common process models or flowcharts. As typical benefits of using DEMO and its Construction Model (CM) we found:

1. business-activities, currently executed by different organizations can be made un- ambiguously and fast comparable; this is very handy in post merger integration, implementation of shared service centers, insourcing, outsourcing, and as a first step in uniformizing processes when cross-region staffing is required; 2. ICT-applications, currently supporting different organizations or departments, can be made unambiguously and fast comparable; this is very handy in application portfolio rationalization.

4 One business transaction needs already at least two infological transactions (one per infor- mation link), and each infological transaction at least one datalogical transaction. So only focusing on business transactions would theoretically give even a reduction of 80%. 5 Assuming that at least the four standard coordination acts are generally described, summa- rizing those 4 C-acts in one transaction would give a reduction of 75%. 90 M. Op ’t Land and J.L.G. Dietz

In terms of the VSM subsystems, DEMO supports governing changes as follows:

• DEMO is not useful in directly governing changes in System One, so the impacting of the daily primary operations, though DEMO can be used to structurally improve exception handling and to embed systematic learning in an organization [2]; • for changes in Coordination, System Two, DEMO can clarify which information is really and minimally needed by which actor role; • for changes in Control, System Three, DEMO supports re-assigning responsibili- ties, especially when organizational borders are crossed, such as in BPO or SSCs; • for changes in Intelligence, System Four, DEMO clarifies for several alternative answers to environmental challenges in terms of changed products or services, what actor roles are needed in these alternative products or services; • for changes in Identity, where System Five balances current and future demands of the organization, DEMO can support evaluating implementation alternatives when the DEMO CM is combined with specific mappings on organization and ICT.

In terms of the enterprise transformation dashboard, which part is now fulfilled by DEMO? The current, future and intermediate states of the enterprise can be expressed in DEMO models and their mapping to current and different future/intermediate (or- ganizational and ICT-) implementations. This gives a complete insight in all actor roles needed in each state, and thereby a first order insight in the consequences in terms of organizations, people and required ICT for the future/intermediate state (see e.g. [22]). To what extent does DEMO fulfill our additional requirements for the enterprise transformation dashboard? Indeed, DEMO gives an holistic and implementation- independent view of the enterprise (without names of organizations or functionary types), allowing to compare different (organizational and ICT-) implementations, such as in sharing and sourcing. Together with mappings on (organizational and ICT-) implementations, DEMO has appeared to be a necessary, useful and in some cases even sufficient instrument to evaluate these different implementations. DEMO also shows a complete insight in the information required by each actor role, clarifying also the origin of new facts in reality. By its attractive ROME, also the making and maintaining of views based on DEMO appear to be cost-effective. Because of these unique characteristics, we propose to put DEMO, and especially its Construction Model, as a standard on the enterprise transformation dashboard as the prime model for getting first order insight in impact of change. As shown earlier: not because DEMO models answer all questions stand-alone. It will, as case studies have shown already, always need to be supplemented by, and connected with strategi- cally (e.g. [17]) and functionally oriented models (e.g, with OMG’s Business Motivation Model BMM [18]), with infological and datalogical aspects, with imple- mentation-oriented process and ICT models and with principles guiding the transfor- mation. Examples of enriching implementation-oriented models with DEMO concepts and connecting these to DEMO models (e.g., with Lean Six Sigma [9], ArchiMate [10], ARIS [29], and BPMN [5, 14]) look promising and deserve further research effort.

Benefits of Enterprise Ontology in Governing Complex Enterprise Transformations 91

At the same time, still richer insights are needed in enterprise engineering, e.g.:

• to what extent does enterprise engineering practice empirically confirm that the time savings found in earlier case studies can be ascribed indeed to the abstractions from (1) coordination acts and (2) infological and datalogical actions? • how to apply simulations already on the level of the DEMO CM to support eva- luating several implementation alternatives - as has been done already on the more detailed level of processes [3]; • how to support making first order estimations of (business- and ICT-) performance, exploitation costs and risks of implementation alternatives already on the level of the DEMO CM; • how to support making first order estimations of transformation costs and risks of implementation alternatives already on the level of the DEMO CM; • how could the other three DEMO aspect models (PM, SM, AM) contribute to sup- porting transformations? • what VSM-subsystems do benefit most from applying DEMO?

Already Heraclitus (500BC) – with his statement "The only constant is change" – is seen focusing not on things as constantly changing, but on things as constant while changing. Enterprise Ontology offers an important contribution in discerning poten- tially constant parts in (chains of) organizations, enabling executive management to choose.

References

1. Ashby, W.R.: An Introduction to Cybernetics. Chapman & Hall, London (1956) 2. de Aveiro, D.S.A., Silva, A.R., Tribolet, J.M.N.S.: Modeling the Function Perspective in ODE: Improving Unknown Exception Handling and Change. In: International Workshop on Organizational Design and Engineering – IWODE 2009 (2009) 3. Barjis, J.: The importance of business process modeling in software systems design. Science of Computer Programming 71, 73–87 (2008) 4. Beer, S.: Brain of the Firm. Allen Lane, The Penguin Press, Herder and Herder, London, USA (1972) 5. Caetano, A., Assis, A., Tribolet, J.: Using Business Transactions to Analyse the Consisten- cy of Business Process Models. In: Møller, C. (ed.) Proceedings of CONFENIS 2011, CIP Working Papers. Center for Industrial Production, Aalborg University (2011) 6. Charan, R., Colvin, G.: Why CEOs fail. Fortune 139(12), 68–78 (1999) 7. Dietz, J.L.G.: Enterprise Ontology – theory and methodology. Springer, Heidelberg (2006) 8. Eigruber, S.: Mergers & Akquisitionen: Der Hunger ist vorüber. Wirtschaftsblatt (July 2, 2008), http://www.wirtschaftsblatt.at/home/zeitung/aktuell/ 333341/index.do 9. Ettema, R.: Diagnosing the enterprise, towards a true causal claim (forthcoming) 10. Ettema, R., Dietz, J.L.G.: ArchiMate and DEMO – Mates to Date? In: Albani, A., Barjis, J., Dietz, J.L.G. (eds.) CIAO!/EOMAS 2009. LNBIP, vol. 34, pp. 172–186. Springer, Hei- delberg (2009) 11. Green, N.: Wikipedia: Vsm.gif, http://en.wikipedia.org/wiki/File:Vsm.gif 92 M. Op ’t Land and J.L.G. Dietz

12. Harmsen, F., Proper, H.A.E., Kok, N.: Informed Governance of Enterprise Transforma- tions. In: Proper, E., Harmsen, F., Dietz, J.L.G. (eds.) PRET 2009. LNBIP, vol. 28, pp. 155–180. Springer, Heidelberg (2009) 13. Heraclites of Ephesus (535 BC - 475 BC), as quoted/interpreted by Plato in Cratylus. The quote is rather free; it should originally read “Πάντα ῥεῖ” (panta rhei), which literally means "everything flows" or a bit more free, “everything moves”. Plato quotes “(Πάντα χωρεῖ” (panta chōrei), meaning “everything changes” – from chōros, to change 14. van der Horst, P.: From business transactions to business processes work flows; Using DEMO and BPMN. Master’s thesis, Delft University of Technology (2010) 15. de Leeuw, A.C.J.: Organisaties – management, analyse, ontwerp en verandering; een sys- teemvisie. van Gorcum, Assen (1982) (in Dutch) 16. Mulder, J.B.F.: Rapid Enterprise Design. PhD thesis, Delft University of Technology (2006) 17. Öberg, C., Henneberg, S.C., Mouzas, S.: Changing network pictures: Evidence from mer- gers and acquisitions. Industrial Marketing Management 36(7), 926–940 (2007) 18. OMG: Business Motivation Model, v1.0 (2008) 19. OMG: Business Process Modeling Notation (BPMN), v1.2 (2009) 20. OMG: Semantics of Business Vocabulary and Business Rules (SBVR), v1.0 (2008) 21. Op ’t Land, M., Proper, E., Waage, M., Cloo, J., Steghuis, C.: Enterprise Architecture – Creating Value by Informed Governance. Enterprise Engineering. Springer, Heidelberg (2009) 22. Op ’t Land, M., Zwitzer, H., Ensink, P., Lebel, Q.: Towards a Fast Enterprise Ontology Based Method for Post Merger Integration. In: Proceedings of the 2009 ACM Symposium on Applied Computing, Honolulu, Hawaii, USA, pp 245–252. ACM, New York (2009) 23. Op ’t Land, M.: Applying Architecture and Ontology to the Splitting and Allying of Enter- prises. PhD thesis, Delft University of Technology (2008) 24. Pautler, P.A.: The Effects of Mergers and Post-Merger Integration: A Review of Business Consulting Literature. Federal Trade Commission (2003), http://www.ftc.gov/be/rt/businesreviewpaper.pdf (last visited August 29, 2009) 25. Recker, J.: Opportunities and constraints: the current struggle with BPMN. Business Process Management Journal 16(1), 181–201 (2010) 26. Rouse, W.B.: A Theory of Enterprise Transformation. Systems Engineering 8(4), 279–295 (2005) 27. Schacher, M.: Mini EU-Rent; Business Model v23.06.2008. KnowGravity (2008), http://www.knowgravity.com/pdf-e/Mini%20EU-Rent%20BU.pdf 28. Stein, S.: What is ARIS? Blog of the ARIS BPM Community, http://www.ariscommunity.com/users/sstein/ 2009-10-23-what-aris (last visited January 24, 2012) 29. Strijdhaftig, D.: On The Coupling Of Architectures: Leveraging DEMO Theory Within The ARIS Framework. Master’s thesis, Delft University of Technology (2008) 30. The Open Group: ArchiMate® 1.0 Specification. Technical report. The Open Group, Thames Tower, 37-45 Station Road, Reading, Berkshire RG1 1LX, United Kingdom (2009) 31. Treacy, M., Wiersema, F.: The Discipline of Market Leaders – Choose Your Customers, Narrow Your Focus, Dominate Your Market. Addison-Wesley, Reading (1977)

Towards Objective Business Modeling in Enterprise Engineering – Defining Function, Value and Purpose

João Pombinho1,2, David Aveiro3, and José Tribolet1,2

1 CODE - Center for Organizational Design & Engineering, INESC INOV, Rua Alves Redol 9, Lisbon, Portugal 2 Department of Information Systems and Computer Science, Instituto Superior Técnico Technical University of Lisbon, Portugal 3 Exact Sciences and Engineering Centre, University of Madeira, Funchal, Madeira, Portugal [email protected], [email protected], [email protected]

Abstract. Current Enterprise Engineering state of the art does not fully address concerns such as bootstrapping and reengineering a working organization from the business perspective. It is currently focused on ontology, the constructional vision, rather than the function. We argue that the function design deserves no less modeling effort, as the construction design draws upon it. To this aim, a change of approach is necessary. By combining knowledge from DEMO, Ser- vice Science and e3Value, this paper presents conceptual contributions towards modeling the contribution perspective of a system in an integrated way, namely by defining Function, Value and Purpose. These concepts are first defined in the context of a dual party relationship and then applied to chains of two or more elements. By coupling with an innovative application of the Generic Sys- tem Development Process, an extension of existing Enterprise Engineering theory is proposed, in a way we believe will assist in improve its current state of the art and widen its application scope.

Keywords: Enterprise Engineering, Purpose, Value, Function, Market.

1 Introduction

Modeling organizations as complex systems keeps gaining importance and is an ever- increasing challenge as 1) boundaries between organizations are increasingly more dynamic and 2) the complexity of the combination between organizations and their support systems as a result of increased ICT support. These two factors contribute to the lack of coherence and consistency among the various elements of an enterprise and, in turn, to the failure of strategic initiatives [1, 2]. Enterprise Engineering (EE) is an emerging discipline that aims at intellectually managing complexity with the objective of creating systems that operate as a unified and integrated whole [3]. It entails the creation of theories, models and methodologies for analysis, design, implementation, and governance of enterprises. However, current EE state of the art does not fully address concerns such as boot- strapping and reengineering a working organization from the business perspective,

A. Albani, D. Aveiro, and J. Barjis (Eds.): EEWC 2012, LNBIP 110, pp. 93–107, 2012. © Springer-Verlag Berlin Heidelberg 2012 94 J. Pombinho, D. Aveiro, and J. Tribolet mainly because it is currently focused on ontology, the constructional vision, rather than the function. Particularly, the Design and Engineering Methodology for Organi- zations [4] (DEMO) has no structure or method definition of that supports the initial stage of the system lifecycle from a business perspective. The function perspective deserves no less modeling effort, especially as the construction design draws upon it. Furthermore, we argue that not having traceability between system function and con- struction impairs bootstrapping, maintainability and evolvability of the modeled en- terprise. This paper presents the groundwork of an extensional approach addressing the function dimension objectively. It includes new concepts and their positioning on an overall framework, as an additional perspective that is integrated with current EE theory and methodology. The paper is structured as follows: Section 2 presents problem analysis with a Library as motivation example. Section 3 outlines an innovative approach to framing b-organization development in DEMO. Section 4 builds on that by defining and dis- cussing individual concepts. Section 5 extends the previously defined concepts into a system chain. The paper closes with conclusions and contribution summary in Section 6.

2 Problem Statement and Approach

2.1 Background – The Relevance of the Non-constructional Perspective

It is important to differentiate two aspects of system development1: teleological, con- cerning its function and behavior, a black-box perspective; and ontological, about its construction and operation, a white-box perspective [5]. This distinction is important, as it forces both 1) the separation of these concerns and 2) their articulation. The argument provided in [4] regarding the absurd in asking a mechanic to disas- semble a car according to its functional description (with items such as lighting, pow- er, steering and brake systems) in not entirely valid in this context: there is a physical, chemical, electric system that was purposefully designed to reach a function. It is on the shoulders of that work that a mechanic performs its activity. In reality, during the mechanic’s mental process of diagnosing and solving prob- lems, this mapping must necessarily be made as the customer is not expected to be able to pinpoint the constructional elements affected by a functional failure. We acknowledge a space for argument may remain, related to function design be- ing a craft and not an exact science, and also due to the fact that a design is, by defini- tion, sub-optimal. Nevertheless, this should not discourage from making an honest effort to model the functional (or, in fact, the whole non-constructional) perspective, should that activity provide usable and interesting results. Ultimately, someone will perform the functional/constructional mapping and if it is done with asymmetric- al/incoherent information (in either direction), the invitation to failure is inevitable. Dismissing the functional perspective in favor of focusing on the constructional perspective has impacts on scoping and collaboration with other system development

1 We consider system development to be comprised of both design and engineering activities.

Towards Objective Business Modeling in Enterprise Engineering 95 stakeholders; particularly, the notion of purpose is frequently dismissed as a strategic concern. We are not aware of structured definitions of purpose that can be used as input to a system development process, neither traced back from a developed system, compatible with the models of a system’s construction in formality and detail. For instance, Goal-Oriented Requirements Engineering (GORE) [6] approaches directly and effectively address the traceability issue but do not provide a formal model of the contribution that enforces bidirectional coherence between goals and construction.

2.2 Library Example In order to clarify the problem space, a practical scenario based on the classical DEMO Library case [4] will be used for instantiation. In this example, the elements of the system dealing with the membership (solid line-bounded area in Fig. 1) are not justifiable as bringing direct value to the customer - who only wants to get hold of a book. However, as it can be seen in Fig. 1, this is all but clear in the ontological (con- struction) model:

Fig. 1. Library example – Construction analysis

Regarding the core business of providing reading content: 1) the core service is concealed in the area marked by a dashed line, obscured inside a loan transaction; 2) inside the solid black line, a sacrifice of the customer in obtaining the service and its support (sub)system; finally, the area bounded by points encloses a support process that may need revision, for instance, in a change scenario of going digital. About the Membership Management subsystem, one must ask if there is really a customer who wants a membership or was this subsystem included in the Library as the manifestation of a strategy to get a fixed amount of income to face, for instance, stocking management? Is this still a problem if the organization does not pay for the books and space? Is it done for profit or simply as a response to the cost of keeping a

96 J. Pombinho, D. Aveiro, and J. Tribolet large library? Is it part of the Library concept, i.e., every library also offers it by defi- nition? Under what conditions this decision should be reviewed? We must conclude that in current EE state of the art, the construction of a system resulting from the development process is a compiled structure that obscures the sys- tem/subsystem relations and their motivation, because they were created from a flat description of the operation of the organization, instead of a sequential bootstrap or an incremental design step.

2.3 Problem Statement In this paper, we are particularly interested in exploring the relation between teleology and ontology in the context system development. In DEMO, this corresponds to the functional perspective and constructional perspective, respectively. We note that a function is served by a number of constructions. The tree of possible constructions of the system being developed, let’s designate it as object system (OS), for satisfying a given function is structured by successively restricting their degrees of freedom while introducing constraints. These constraints are the result of applying both functional and constructional principles to the requirements, which are derived from the con- struction of a using system (US). The model of the US and the way requirements are expressed, namely their abstraction level, is also a constraint over the solution. The fact that the DEMO methodology begins by using a description of an organi- zation works skips a very important part: why was it assembled that way? This need for explicit, structured reasoning may be a nice to have in modeling a snapshot of the organization lifecycle but is critical when dealing with change. For instance, the cur- rent construction of a system has a role as an input of its own change process. But, if it does not provide enough information of why each element of the system belongs to it – the reasoning behind its inclusion as a piece of the solution – besides rework it will likely imply risks in cohesion and coherence of the system resulting from the development driven by the as-is/updated hybrid functional model. DEMO's approach to the business-organization, is about ontology, the construc- tional vision, rather than the function. As mentioned in the previous section, DEMO does not currently address, or even aim at addressing, the function perspective in de- tail. However, we argue that the function should not be dismissed on the basis of its apparent subjectivity. Therefore, the main question is: how to (more) objectively represent the teleological perspective of a system? Our proposal consists in introducing the market concept into system modeling activities in order to support dynamics and mediate teleological and ontological visions of a system. The hypothesis is that a system is a value chain itself and can be further decomposed in a value model within the system’s scope. For instance, using the Library example from Fig 1, each subsystem necessarily has a functional model.

2.4 Approach The relevance of a new perspective other than construction and function is discussed in [7] by exploring the dualities Subjectivity/Objectivity, Function/Construction and Black-box/White-box. While construction and function perspectives are characteristic of an isolated system, another perspective must exist to model the relation of that system with other systems. Let’s designate it by contribution perspective, also named as valuation perspective in [8]. This perspective addressed the relation of a system

Towards Objective Business Modeling in Enterprise Engineering 97 with systems belonging to its environment, i.e., its stakeholders. We argue that this perspective is not necessarily subjective and can be addressed in an integrated way with the other two. To this end, we aim at combining Information Systems and Enter- prise Engineering, which are relatively recent disciplines, with other disciplines that study Enterprises, such as Management and Economics. The latter group incorporates hundreds of years of experience in the form of theories, trial and error exercises and practical cases. These are not necessarily correct nor are necessarily usable in integra- tion with EE, but the opposite is also to be proven true. Therefore, we developed ef- forts to integrate knowledge from theories about the same object on a common ontol- ogy. Particularly, contributions were integrated from Marketing - Service Science and Economics - Value Theory. Methodologically, a selection of the relevant theories about the main concepts identified in [9], service, value and purpose, was followed by relevance and compati- bility validation and finally incorporated as mutual restrictions on either side (DEMO and e3Value; DEMO and Service System).

3 A Change of Paradigm – Facing the Market

3.1 The Generic System Development Process The Generic System Development Process (GSDP), included in DEMO’s theory set, is shown in Fig. 2. Following the overview presented at section 2.3, it begins with the need by a system, the US, of a supporting system, called the OS.

Fig. 2. Generic System Development Process. Adapted from [4].

From the white-box model of the US, one determines the functional requirements for the OS (function design), formulated in terms of the construction and operation of the US. Next, specifications for the construction and operation of the OS are devised, in terms of a white-box model (construction design). The US may also provide con- structional (non-functional) requirements. Choices are then made with each transition from the top-level white-box model towards the implementation model. However,

98 J. Pombinho, D. Aveiro, and J. Tribolet nothing is prescribed about the rationale behind these choices. It is clear that system design decisions, either implicit or explicit, remain solely, and certainly not forever, in the minds of the participants in the process. The sheer complexity can quickly cross the limits of human handling or simply enough time passes and the limitations of human memory are exposed. It may then become impossible to know the rationale of past decision, its impacts and dependencies in both today’s scenario and in designing the to-be. Where to start addressing this issue?

3.2 Who Is the Using System of the B-Organization?

We fully agree with DEMO’s application of the distinction axiom, i.e., layered Archi- tecture for B-I-D, in a single organization. But, as it was demonstrated in the example presented at the Problem Statement section, this structure does not include the ratio- nale for having a particular set of actor roles, transactions, and dependencies among them. These concerns clearly belong to the B-organization level. It is not surprising that no support for functional modeling of the B-organization exists, as [5] defines the market as US of the B-organization. Still according to [4], the following classifications applies to systems

• an homogeneous system is a system in one system category – which de- termines the type of elements in a system and their relations; • an heterogeneous system is a layered nesting of homogeneous systems.

This seems to imply that the US of the B-organization, the market, is of another sys- tem type. However, we must assert that the US is another B-organization. Then, we must wonder: if the US definition applies to heterogeneous systems, why should it not apply to homogeneous systems? Can’t a homogeneous system be treated like a hete- rogeneous one, operating in layered manner? In fact, it can be shown that a certain I- Transaction regarding a system is a B-Transaction of the system supporting it [10]; let us designate this as the relativity principle, and conclude that same reasoning can be applied to the remainder relations. This seems plausible even empirically, as a support process from an organization is, by definition, its provider’s core business. Working on the hypothesis that it should be not limited to heterogeneous system types, our investigation reached the frontier with the market. But what is its system category? Is it not a social system? In fact, using the GSDP for connecting homogeneous systems instead of heteroge- neous systems it is a simplification and, therefore, should pose no harm. The only explanation lacking is why one would want to do it. As we have already seen, the GSDP is a structured and conceptually well-defined process for system development – a prime structure for registering the rationale of the design process, step-by-step. However, this process (or a specialization) generally occurs implicitly and (possibly) incompletely, leaving no trace of the rationale besides the memories of the partici- pants in the process. We argue that the B-organization can and should be designed and engineered within the scope of EE and, therefore, propose to apply the GSDP for connecting B-organizations by co-developing US and OS pairs, i.e., develop US and OS as two B systems (see Fig. 3).

Towards Objective Business Modeling in Enterprise Engineering 99

B B B I I I D D D

Fig. 3. Conceptual B-organizations co-development

Modeling US and OS as B-organizations, therefore at the same modeling layer, enables recursive application of the GSDP, as further explained in section 5.3. This approach implies a paradigm shift from single versus multiple (yet coherent) systems engineering. In fact, this is what happens in real settings but is hindered by the diffi- culty that humans have dealing with this kind of complexity in dynamic settings. By providing useful theory and logical instruments over the next sections, we hope to contribute to improving the state of the art.

4 A Simple Market: One Buyer, One Seller

The GSDP was chosen as a reference, because it has articulate and clear primitive concepts that reflect the essential systems development. By providing it with a social setting, relating two social systems begins with a reason to enter an exchange that justifies a relation between two different actor roles. For simplification purposes, let us begin our presentation of the non-functional perspective by analyzing the relation between two systems, designated by S1 and S2. S2 is being developed to support S1; so, in the context of the GSDP they assume the roles of OS and US, respectively. In the next section, we will explore this relation from purely systemic, service, value and teleological perspectives.

4.1 Function

The concept of function has many definitions and different application areas, such as Mathematics and General Systems Theory. The strict notion of function is not subjec- tive - it is related to the notion of observable behavior. As presented in the GSDP, a given construction is made to support a function. The function is, then, dependent on construction. Still according to [4], the function of a concrete system is the set of services it is able to provide. We believe these are dis- tinct concepts; service will be presented next. Continuing, it is said that functional models, characteristic of disciplines such as management and organizational science, are useful for the purpose of using/controlling a system but inadequate for bringing about changes. We agree if they include everything which is not constructional. It need not be so: while the function specifies the system’s relation with elements on its environment, in terms of inputs and outputs, purpose specifies what usage is

100 J. Pombinho, D. Aveiro, and J. Tribolet given to the system’s function, from a specific external actor’s point of view. Value emerges from the relation: it is attributed to a system function by a stakeholder in regard to a specific purpose. The point must be made that it is important to segregate contribution-oriented notions from function definitions as they have a different nature and positioning regarding a system and its environment. The functional perspective is frequently seen as fuzzy. As we have seen, it is not: questions such as what is a sys- tem used for or why was it chosen can and should be formalized - elsewhere!

4.2 Introducing Service

In [11], the concept of service system is introduced, central to both Service Science (SS) [12] and Service-Dominant (SD) logic. It is defined as “a configuration of people, technologies, organization and shared information, able to create value to providers, users and other interested entities, through service”. Service as a process involves using an actor’s resources for the benefit of serving another actor. In SD-Logic, resources are differentiated between 1) operant, which create benefit by acting upon other resources, such as competences and capabilities; and 2) operand, which must be acted on to provide a benefit, such as natural resources and goods. Using the formal definition for a system’s construction, from [4]: 1. only operant resources are part of the composition of a social system; 2. value creation is done through the production of a system towards its en- vironment, through services. A system is a service system if and only if it is possible to initiate a transaction with some agent that (legitimately) assumes the role of provider of the services exposed by that system. In other words, every resource can be part of a service system as long as it contributes to the objectives of the system and there is a person (generally its own- er) who brings it into a solution market, thus bringing it to potentially fulfilling the role of operant resource, in SD-Logic terminology. The service concept builds on the function by framing it in transactional semantics, exchanging contract and operation conditions; for instance, defining the conditions for loaning a book in the library – ex: nr. of days, legal dispute forum, cancellation me- chanisms, eventual costs for unexpected scenarios such as loss, etc. These combina- tions could be advertised as part of the function but would it make unnecessarily complex and render it so customized to the particular organization that its offering would probably not be comparable to other solutions. The contributions from Service Science and SD-Logic regarding value are briefly presented in the next section.

4.3 Introducing Value

The same service can be used to different objectives – depending on the solution chain it belongs. The value concept is therefore critical in relating the services pro- vided by a system and a specific stakeholder. It depends on the alternatives available for a given purpose. Value is, therefore, an emergent property from the relation be- tween the function provided by a (support) system and the purpose another system has

Towards Objective Business Modeling in Enterprise Engineering 101 for that function, as in SD-Logic’s Foundational Principle 10 [13] Value is always uniquely and phenomenological determined by the beneficiary. We devise our specification of the concept of value from e3Value [14] and DEMO. On one hand, e3Value allows expressing the value context of any DEMO transaction, as a manifestation of purpose; on the other hand, system construction modeling is supported by tracing value-production from e3Value to Coordination/Production Facts/Acts level in DEMO [15]. e3Value is directed towards e-commerce and, as such, embodies concerns about economic viability as restrictions. Particularly, an actor is defined as being perceived by his environment as an economically independent entity. Economical independence refers to the ability of an actor to be profitable after a reasonable period of time, or to increase value for him. Modeling the rationale behind a system’s composition, as the solutions market concept presented in [16] requires a broader modeling scope. Thus, we chose to relax this important restriction of economic independence in the stage of composition's design. The main common concept between DEMO and e3Value is that of a transaction between two actors. The service value concept is based on e3Value by relating the buyer/seller dual-party semantics to DEMO’s US and OS. Actors are the active elements of both social systems and value networks. In DEMO, an actor is a subject fulfilling an actor role in a transaction type. The initiator and executor actor roles are bound by their common interest in bringing about a pro- duction result. In e3Value, both actors (provider and requester) are bound by the willingness to share value objects with the concept of reciprocity. The transaction concept represents the relationship between actors by associating value ports of different directions. A unitary DEMO transaction relates to a value exchange in e3Value. A value transaction involves at least two value exchanges, according to the principle of economic reciprocity – fairness of the exchange implies value transmission in both directions.

LIBRARY

CA01 CA00 T01

Library Customer Loan Book Kernel

T02

Payment

Fig. 4. e3Value and DEMO simplified Library Examples

In the examples on Fig. 4, it is the Reader’s choice to use the Library to get a Book in exchange for Money. Obviously, there can be alternative solutions to get a Book. The fact that it is a choice is important, as it positions the Customer as a US [4] and, therefore, being the initiator of the transaction.

102 J. Pombinho, D. Aveiro, and J. Tribolet

Another association critical to the alignment is between production fact (DEMO’s Transaction Result) and value object’s exchange, as the production of each service transaction determines its effective contribution to the value chains it participates in. The principle of economic reciprocity makes it necessary for DEMO’s transactions to have a counterpart. Actually, their production fact is related to value object trans- mission. In the simplified Library example, the requested production facts are: • R01 - book loan (possession of a physical book copy) has started • R02 – book loan was paid (money) For this simple case, it is trivial to relate the production fact and value object. Howev- er, it can be hard in the cases where the value-orientation is not present in the transac- tion definition and it is necessary to make value explicit. For instance, the implicit value objects of R01 and R02 are now explicit, in bold, inside brackets. In e3Value, a value port represents the offer (outbound value port) or demand (in- bound value port) of a value object to the environment. Two or more value ports of different directions are grouped in value interfaces. This concept is critical as it represents the willingness of a system to present a demand or offer towards the mar- ket. In practice, it specifies the matching of the value interfaces as necessary for en- gagement. An offer is made effective by the production of a fact by performing a Value Ac- tivity. A restriction introduced by DEMO into e3Value is that one must specify which actor roles are authorized to perform coordination acts which correspond to certain value ports. For example, actor role book loaner is authorized to perform promise and state c-acts of T01, which correspond to an outbound value port. Additionally, book loaner also has to be competent to perform the p-act. Decomposing value exchanges down to these primitives explicitly connects the value model of the system with its construction. This decomposition is based on solid actor interaction theory. In summary: function, supported by construction, is exposed as a service in a mar- ket through one or more Value Interfaces. DEMO’s transactions correspond to Value Exchanges, which are aggregated in e3Value’s Value Transaction (with economic reciprocity). The main conceptual apports to DEMO are economic reciprocity and value co-generation; the later consists in the notion that value is created by interacting and, therefore, that it is within the scope of a transaction itself, not on good traded by its means – which increases the importance of the production fact semantics. Besides contributing to improve the semantics for value-oriented design, e3Value introduces the concept of chain, which is presented in the next section.

4.4 Introducing Purpose In order to perform meaningful modeling and reasoning it is essential to establish the purpose as it is the base for designing and engineering the solution providing system. Purpose is: ‘(...) an object or end to be attained; what one intends to do or bring about’, according to the Merriam-Webster dictionary. When applied to systems, it may have two different meanings: one notion of pur- pose that reflects what it was designed for and other one that reflects what a system is

Towards Objective Business Modeling in Enterprise Engineering 103 effectively used for. For instance, a cell phone may be used as a flashlight, despite it was originally conceived as a communication device. In fact, as much as two-thirds of mobile phone users claim to do so, according to an inquiry by Sprint [17]. There is, then, an issue regarding balancing design time decisions with unknown usage conditions. The effective usage of a system arises from: 1) the needs and 2) creativity of actors as they procure and assembly solution providing systems to fulfil- ling those needs. Purpose is commonly considered only in the initial stages of the system, during de- sign and engineering activities. This is contrary to the notion we have just introduced: by freezing design decisions without a structured value structure that is traceable to construction, it becomes hard, if not impossible, to reassess the rationale behind deci- sions in order to adapt and evolve the system. To tackle purpose modeling, we conceive not a relation between a system and an informal end-user - stakeholder - but a formal relation between two artificial systems. Therefore, modeling purpose brings about the need for considering the application of the GSDP to more than a pair of US/OS system roles, as presented next.

5 Extending the GSDP to System Chains

5.1 Motivation and Example

Exchanging value objects is the main reason two social actors engage and a transac- tion occurs. The question is how to model it in a uniform way that is reusable regard- less of the relative positioning of the system on a chain? We argue that, by modeling each of the elements of a system as an actor role, each respective transaction represents the subsystem’s contribution towards its environ- ment (the original system). This contribution must be valuable; otherwise it should not be part of the overall system. Let us take as an example the Membership Man- agement subsystem of the Library. Its value to the Library system, let us define it as contribution value, is relative to the systems considered. In this case, the Library sys- tem uses the Membership Management system and is, in turn, used by a Customer Reader system. These two value framings pertain to two different levels of a value- chain: 1) the value that using Membership Management system has to the Library as a business, and 2) the value that using the Library System has to the Customer Reader. We argue that some of the value generated by the Membership Management system is, or at least should be, an enabler to releasing some kind of value to the systems downstream of the Library System. Therefore, the purpose of a given system element is related to the set of value contributions made downstream in the value chain.

5.2 Formal Concepts

A system chain is an ordered list of systems Si, with value exchanges between con- secutive elements. Note that Si-1 is contained in the Environment Si. This definition is recursively applicable; in other words, for any given system Si, its environment is partitioned in both Si-1 and Si+1 – consecutively chaining two US and OS pairs.

104 J. Pombinho, D. Aveiro, and J. Tribolet

The set of services a system S can provide to its environment is directly related to what we designate as the Using System Set (USS). The USS of S is the set of systems that are initiators of transactions of which S is executor. Therefore, the USS fulfills the demand role for S and S fulfills the offer role. For instance, the USS for the Li- brary can be a customer loaning books and a retailer using the Library’s physical space for promoting a book. In turn, for S to deliver its services, it fulfills the demand role in relation with another set of systems which offer the services needed by S – its Object System Set (OSS). In this case, S assumes the role of demand and its OSS assumes the role of offer. For instance, an OSS of S can be a publisher and the owner of the Library’s physical space. A very interesting application of formally defining purpose of a system is that it can be (re)used for modeling the relation between a system and the elements that compose it. We argue that any given complex system can be decomposed into more granular systems: if a single element is part of a system’s composition, then it is nec- essarily connected by means of the system’s structure to other elements; therefore, these connections must represent the element’s contribution to the production of the system. Formally, a single element of a system is also a system (a sub-system of the original system), with a composition constituted by a single element, an environment formed by the other elements in the original system and a structure linking the ele- ment to the environment, as depicted in Fig. 5.

Composition of SN

Environment of SN

Not a part of SN

Fig. 5. The construction of a system - US/OS dualities and subsystem analysis

We are now in position of completing the purpose definition. We argue that if we trace a system’s purpose recursively through the solution chain as func- tion/construction pairs, the last one will be a function / black-box. Philosophically, if absolute truth is not attainable, these chains will end in the meaning of life (i.e., the last why) - traceable to the root of human intentions. Exposing those intentions, even with only partial objectivity will assist in modeling the associated systems. Therefore, we would like to add to the formal system definition from [4]: A pro- duction as the fact pertaining the contribution it makes to the production of the origi- nal system – its purpose, relative to that chain. One must wonder, if the contribution cannot be specified, then what is the reason for being part of the composition?

Towards Objective Business Modeling in Enterprise Engineering 105

5.3 The System within – Relativity and Recursion

The previous reasoning is rooted in two notions: 1) relativity and 2) recursion. The first one, relativity, because a given systems' white-box may be a black-box (or a set of black-boxes) in another referential of system types, e.g., the white-box model of a car still holds the chemical system of a battery as a black-box. Following the same reasoning, and having finer thresholds between system types, this reasoning can be applied to refine a given overall system model into layers. These layers can model M- N relations between systems, e.g., the car can use a battery, solar power and gas as energy providing (sub)systems. Therefore, they end up forming a layered solution chain where the uppermost layers are dependent on the lower ones. Recursion regards the definition of the contribution of each (sub)system element to their main system (which is their US), and is related to the process of engineering these relations. In this way of reasoning, recursive applications of the GSDP would happen, posi- tioning the father system as US and each subsystem as OS. This means rejecting a large, compiled white-box as a model for complex systems. They should instead be modeled as successive implementation levels (implying explicit solution choices), from problem to implementation of a solution, instead of a single effort of engineer- ing - which will result in "hardcoded" implementation and loss of intermediate model- ing elements and constructs. Still elaborating on the inputs of SD-Logic and e3Value, we note that in DEMO only operant resources are modeled, because the composition is entirely made up of actor roles; this way, the atomic service system concept from SD-Logic [11] is com- pliant with this definition. Therefore, modeling purpose as the contribution of a given system’s production to its environment (which is populated by neighboring nodes forming a value network) is a very powerful teleological concept that can be incorpo- rated in SD-Logic conceptualizations. This repositions the issue of addressing the functional perspective from a mere “outside world” problem (which would even so be relevant) to a very relevant system engineering problem: representing components as economically independent parts of a solution. Furthermore, our proposal regarding the level of atomicity of system elements is a step further from the service system conception, by deliberately assuming an econom- ically-independent perspective between producer and consumer and associating a person (actor role) to each component. This is especially differentiating as an ap- proach for otherwise dismissed chains of technological components, such as software applications and infrastructure. This way, one has to make value exchanges explicit and objectively define themes which are generally found on a services contract, i.e., responsibility, assumptions, performance criteria, etc., effectively working at both service and value layers. Continuing on the Library example, let’s assume that man- aging the risk of non-return may be performed by an economically independent sys- tem, such as an external insurance company. Then, the value of insuring a book must be specified in order to setup the value exchange. This is a significant change from assuming the internal subsystem addressing that concern as it makes necessary to specify, for instance, how much of the original book value at loan initiation time can be recovered and how long after a book is assumed to be lost can the value be recov- ered. This specification is necessary for scoping the service demand which is to be

106 J. Pombinho, D. Aveiro, and J. Tribolet placed in the market. Clearly, it is also insightful for analyzing internal alternatives for addressing the same concern. In this way, this explicitation contributes to prepar- ing to answer change events by developing system components more prepared to be swapped according to the offer. Obviously, there will be diminishing returns on mod- eling every component down to the nuts and bolts level in this aspect but, for a theory to be considered sound, such capability must exist if there is a case for doing so. This improved specification is justified by the fact that the network of enterprises collabo- rating in runtime cannot be assumed to be known upfront and, therefore, models should offer increased support for loose coupling from the business perspective.

6 Conclusion

Current EE state of the art approaches, particularly DEMO, are limited concerning non-constructional perspectives. We propose addressing this issue by:

• Distinguishing functional and contribution perspectives; • Improving their objectivity by defining a set of concepts and their relations, namely function, value, and purpose; • Integrating teleological and ontological system development by framing it in a value exchange context – introducing the concept of market, defining the relation between value interfaces and the constructional perspective; • Defining the rationale of system development choices in terms of valuation of solutions in a market context, by recursively defining purpose of a system as its contribution to a specific chain.

We are confident that these concepts are very relevant since they can be reiterated at any system/sub-system relation, either at pure business level, business/ICT interface or inside complex ICT systems. The abstraction and flexibility enabled by the recur- sive application are especially relevant in ICT-intensive environments, as the access to components usable as pieces of a solution chain is increased by maturing technolo- gical advances, such as services based on the Cloud paradigm [18]. In conclusion, true alignment between business and its supporting systems can only be effectively pursued when in possession of a conceptual theory, together with the corresponding methodologies and applications, which integrate both the contribution, function and construction perspectives of a system. The contribution perspective must be clearly addressed by the EE discipline to improve its relevance in connecting to other disciplines, particularly Management, Marketing and Economics, only to name a few which directly address business modeling. Introducing Enterprise Engineering is a critical step towards bridging the gap between strategy and its implementation.

References

1. Kaplan, R.S., Norton, D.P.: Strategy Maps: Converting Intangible Assets Into Tangible Outcomes. Harvard Business School Press, Boston (2004) 2. Laudon, K.C., Laudon, J.P.: Management Information Systems: Managing the Digital Firm. Prentice Hall

Towards Objective Business Modeling in Enterprise Engineering 107

3. Dietz, J.L.G.: Enterprise Engineering Manifesto (2011), http://www.ciaonetwork.org/publications/EEManifesto.pdf (cited January 24, 2012) 4. Dietz, J.L.G.: Enterprise Ontology: Theory and Methodology. Springer (2006) 5. Dietz, J.L.G.: Architecture – Building strategy into design. Netherlands Architecture Fo- rum, Academic Service – SDU, The Hague, The Netherlands (2008) 6. Regev, G., Wegmann, A.: Where do Goals Come from: the Underlying Principles of Goal- Oriented Requirements Engineering. In: 13th IEEE International Requirements Engineer- ing Conference (RE 2005). IEEE, Paris (2005) 7. Op’t Land, M., Pombinho, J.: Strengthening the Foundations Underlying the Enterprise Engineering Manifesto. In: Albani, A., Aveiro, D., Barjis, J. (eds.) EEWC 2012. LNBIP, vol. 110, pp. 1–14. Springer, Heidelberg (2012) 8. Op’t Land, M., et al.: Enterprise Architecture – Creating Value by Informed Governance. The Enterprise Engineering. Springer, Berlin (2009) 9. Pombinho, J., Tribolet, J.: Service System Design and Engineering – A value-oriented ap- proach based on DEMO. In: 3rd International Conference on Exploring Service Science, Geneva (2012) 10. Bardaa, P.J.: On the relativity of enterprises – Essential DEMO Modelling for SOA (2009) 11. Maglio, P.P., et al.: The service system is the basic abstraction of the service science. In- formation Systems and E Business Management (2009) 12. Lusch, R.F., Vargo, S.L., Wessel, G.: Toward a conceptual foundation for service science: Contributions from service-dominant logic. IBM Systems Journal 47(1) (2008) 13. Vargo, S.L., Lusch, R.F., Akaka, M.A.: Advancing Service Science with Service- Dominant Logic: Clarifications and Conceptual Development. In: Handbook of Service Science. Springer (2010) 14. Gordijn, J., Yu, E., van de Raadt, B.: e-Service Design Using i* and e3value Modeling. IEEE Software 23, 26–33 (2006) 15. Pombinho, J., Tribolet, J.: Modeling the Value of a System’s Production – Matching DEMO and e3Value. In: 6th International Workshop on Value Modeling and Business On- tology, Vienna, Austria (2012) 16. Pombinho, J., Tribolet, J.: Issues and Challenges in Dynamic Systems Design and Engi- neering - A Value-Oriented Approach. In: 6th SIKS Conference on Enterprise Information Systems, SIKS. Delft (2011) 17. Tsai, A.: Sprint Survey Reveals 56% of Phone Users Do More than Talk (2006), http://www.mobiledia.com/news/43052.html (cited February 26, 2012) 18. Smith, D.M., et al.: Predicts 2011: Cloud Computing Is Still at the Peak of Inflated Expec- tations. Gartner (2010)

Monitoring Value Webs

Patrício de Alencar Silva and Hans Weigand

Department of Information Management Tilburg University, P.O. Box 90153 5000LE Tilburg, The Netherlands {p.silva,h.weigand}@uvt.nl

Abstract. Value webs are socio-economic systems with a proper dynamics that closest resembles the way business cooperation happens nowadays. In theory, they are economically robust systems, structured on strong market segmentation, especially attractive for medium and small-sized enterprises. It is of a shared concern among its participants that it remains sustainable, and this depends on how manageable its constituent transactions are. Management normally involves monitoring and transformation. The problem considered here is how a value web can be monitored. There is no central point of control of transactions in a value web, though. This problem can be treated by modeling monitoring as a local behavior and propagating it system throughout, by exploring the micro-macro link in social systems. Monitoring here is understood as a communication action phenomenon, and captured on a task model named Enterprise Monitoring Ontology. Its conceptual fitness is demonstrated on a business case on Intellectual Property Rights in the digital music industry. The artifact is evaluated from a Design Science perspective.

Keywords: Enterprise Ontology, Intellectual Property Rights, Requirements Engineering, Service Monitoring, Value Webs.

1 Introduction

A value web can be defined as a business ecosystem of actors exchanging objects of economic value towards a shared goal of profit generation [1]. Markets’ needs drive, shape and sustain value webs. Once a highly demanding market’s need is identified, enterprises network and approach in cooperation, so as to fulfill it. Cooperation here is essentially economic. Enterprises engaged on cooperation tend to focus on providing core business competencies for the sake of market competition. When cooperation is reached, the result, in theory, is an economically resilient system, especially attractive for medium and small-sized enterprises, which ultimately seek for business survival and resilience. On a basic level, a value web is a communication system, resembling a neural network where events propagate throughout. A value transfer is the most important event occurring on a value web. Economically reciprocal value transfers compose what is called a value transaction. A value transaction, therefore, encloses the micro-economic context of a value web. The full set of value transactions composes its corresponding macro-economic context. There is no central point of management of the macro-context, but the control of the

A. Albani, D. Aveiro, and J. Barjis (Eds.): EEWC 2012, LNBIP 110, pp. 108–123, 2012. © Springer-Verlag Berlin Heidelberg 2012 Monitoring Value Webs 109 micro-context is shared between its corresponding pair of actors. From a socio-economic perspective, there is a link between these two contexts propagating system events [2]. For instance, successful value transactions strengthen the system as a whole through value co- creation, but unsuccessful ones produce the opposite effect. This link can be explored to achieve critical purposes, therefore. In a value web, a critical and shared purpose is that its transactions remain manageable, and, hopefully, sustainable. Manageability normally relates to monitoring and transformation. The research question here is how a value web can be monitored. From a Requirements Engineering perspective, the problem can split in at least two sub-questions: (1) what the monitoring requirements of a value web are; and (2) how to represent them. These questions are treated here taking into account a target group of stakeholders composed by business analysts. The motivation for treating this problem is to furnish this group with a tool for designing early requirements for monitoring value webs. The tool is the so-called Enterprise Monitoring Ontology (EMO), the subject-matter of this paper. This ontology can be used to reproduce a value viewpoint on monitoring Enterprise transactions. The ultimate research goal is to leverage how service monitoring is currently performed: deriving service monitoring requirements from business’ needs to corresponding realization/implementation processes and systems, and not conversely. Monitoring is a specific operation performed by the Enterprise, with its proper set of elements and dynamics. EMO is a task ontology, outcome of a work of Design Science [3] that extends the Enterprise Ontology [4]. Like its predecessor, EMO grounds on early work on Language Action Perspective [5-7], but incorporates elements from the work of Allwood [8], which sheds a different light on a particular aspect of Communication Action: that communication does not occur per se, but is composed/driven by management elements. The approach on deriving EMO is deductive: first, axioms of Allwood’s theory are subtracted to form an upper-level Communication Action Ontology. Second, this ontology is partitioned so as to produce task ontologies for management activities. EMO is one of those. It is aligned with umbrella business theories, such as Contract Theory [9] and Contract Law [10]. Moreover, it somewhat explores the conceptual link between the micro and macro social-economic contexts wherein the Enterprise operates. Artifact viability is demonstrated on a real-world business case, concerned with monitoring issues on managing Intellectual Property Rights in the digital music industry. The idiosyncratic nature of the subject matter of protection (and its evolving ways of distribution) challenges current strategies for monitoring this type of commodity. The demonstration is exploratory, and conceptual fitness is evaluated from a Design Science perspective. The rest of this paper is organized as follows. In section 2, theories grounding the Enterprise Monitoring Ontology are exposed and related. The ontology is described in detail in Section 3. Business case demonstration follows in Section 4. Advances on the treatment of the main research problem, likewise on the case study, are discussed on Section 5. Research contributions and future work agenda closes the paper.

2 Theoretical Background

As communication in a value web is based on economic reciprocity, every actor involved in a value transaction is both managed and manager party at the same time. The problem of how to monitor a value web is an instance of the one of decentralized

110 P. de Alencar Silva and H. Weigand management with communication among managers, therefore. One way of tackling this problem is to model monitoring as a local behavior and use the micro-macro link in social simulation to propagate it as a global phenomenon. By breaking the micro- economic context of a value transaction down into simpler elements, it is possible to identify single enterprises playing market roles (as actors) and engaging in cooperation by performing different types of operations. These are the two main grounding elements of the Enterprise Ontology, proposed by Dietz [4]. However, the problem now shifts to how to make Enterprise operations monitorable. Enterprise Ontology is based on the postulate that enterprises are essentially communication systems. It grounds on earlier work on Language Action Perspective (LAP) of Austin [5], Searle [6] and Habermas [7]. The theory draws a parallel between how human communication is structured and how modern enterprises operate. This parallel develops along four axioms and one theorem. The first axiom states that enterprise actors engage on coordination operations, by responsibility, and on production ones, by competence. The second axiom states that operations form transactions. The third one postulates that transactions can be composed. The fourth states that operations are displayed and sensed through distinct and layered human cognitive processes. Finally, the organization theorem architects the axiomatic elements by assigning them to corresponding realization and implementation resources. Although specifications produced by using Enterprise Ontology lack of important management concepts and dynamics, it is recognized that the theory is extensible [4]. Still adopting a Language Action Perspective, the work of Allwood [8] sheds a different light on Communication Action. The author identifies important elements that explain how communication can be manageable and predictable. For instance, a rational agent normally employs communication with a point (i.e. meaning or purpose); communication is constrained by time, scope and context; and a rational agent uses indicative information objects (i.e. displayors and signals) so as to assess the communicative adequacy of a communication act (i.e. communication is a resource that should be economically used). In addition to these elements, the classification of other types of communicative acts can be part of what could be called an axiomatic theory of management as a communication action phenomenon. Such a theory (or upper-level ontology) could establish the basis for many deductive systems deriving axioms of more specific Enterprise operations, such as monitoring and transformation. Enterprise Monitoring Ontology (EMO) [11] can be classified as a task ontology, according to Guarino’s framework [12]. This time, it is revisited and partitioned from the work of Allwood. It grounds on linguistic concepts and is covered with core management theories, such as Contract Theory (Economics) and Contract Law. It also incorporates concepts from specific theories in organizational management, such as the Balanced Scorecard [13]. In short, it represents an endeavor on understanding Enterprise monitoring from a multidisciplinary perspective. A value web system is a communication system, by definition. The communication occurring there is specific, essentially economic. Ontologies such e3value [1] and the

Monitoring Value Webs 111

Resource-Event-Agent Ontology (REA) [14] explain how this type of system works, from different but related perspectives. The former is focused on the economic reciprocity and sustainability of a value transfer (i.e. an economic communication), whereas the latter is concerned with the flow (i.e. auditing cycle) of economic events. EMO somewhat encompasses both aspects. Those ontologies constitute potential candidates for applying EMO, so as to demonstrate its conceptual fitness. An e3value web from a business case on the management of Intellectual Property Rights (IPRs) in the music industry has been chosen for the sake of pragmatic evaluation. The underlying scenario is a monitoring (business) case, on its core.

3 Enterprise Monitoring Ontology (EMO)

The Enterprise Monitoring Ontology is described as follows. First, its grounding upper-level Communication Action Ontology is presented. This ontology is a parsimonious set of concepts described extensively in the work of Allwood [8]. Second, EMO is represented in detail. The relation between these two ontologies is formalized via model stereotype extension and application.

3.1 Communication-Action and Manageability

Contributions of Allwood’s theory on Communication Action are twofold: (1) that communication can be manageable per se; and (2) that it can be used in such a way so as to achieve different management purposes of a rational agent. Here, an attempt is made to provide an axiomatic description of the theory in form of an upper-level ontology (vide Fig. 1). It is described along with its concepts and relationships as follows. The theory is based on principles of rational agenthood. Three types of agents can be identified in a basic communication action instance: sender, receiver and observer. The last plays the role of a witness of the second. Agents have purposes in mind, such as wishes and needs. A purpose orients action. Not every action has a point, but rational action is normally oriented by higher-instance purposes. At least five types of communication actions can be identified. The inner type of action performed by an agent is the transformation. It changes features of the content, i.e. the subject-matter of the communication process. A transformation act is equivalent from the concept of production act, stated by Dietz. A single agent is the only one who has access to change the state of its own transformation acts, i.e. to modify their internal state from acts to facts. This implies agents can only influence others to perform transformations. Influence starts with engagement in cooperation acts. Allwood defines cooperation as a type of interaction involving two or more agents who are (1) considering each other, and (2) trying to achieve one or more common purposes. This concept is equivalent from Dietz’s concept of a coordination act. A cooperation act relates to all the other types of acts as a purposive plan. Cooperation works as an “envelope” for transformation. So the latter is the subject of the former.

112 P. de Alencar Silva and H. Weigand

Fig. 1. Communication Action Upper-Level Ontology (parsimony from Allwood [8])

Still on action classification, two important types of communication acts can be identified. Acts of display reveal the internal state of all the other types of acts, but do not cause any respective state change. Display acts are used by the sender to influence behavior. They serve to an agent’s internal manipulatory purpose. Apprehensive acts represent a complementary set of acts, corresponding to the receiver’s sensemaking or communicative awareness. Display and apprehension have an action duality, i.e. the state of an apprehension can be displayed, and a display can be (or not) apprehended. The last type of action, and perhaps the most intriguing one, is the coordination act. According to the author, coordination acts resemble a sort of “glue” acts, i.e. an instrumental plan to select and compose all the other types of acts so as to produce economically rational action bundles. Coordination can also take goal orientation as selective parameter. The concept of norm is used to cover any type of superordinate direction which an individual has internalized as dispositions towards beliefs or actual beliefs about the correct way to act [8]. Thus, a norm represents the obligating force of action (i.e. permissive or restrictive force). Norms have a term and scope validness in a certain context. As a single action can be linked to different purposes, a context can disambiguate an action (by associating a conventional meaning to the act). Finally, the state of a private action is made known via display and apprehension acts, which emit and capture, respectively, action state information, reified by the concept of indicator. Thus, a display act is performed on the sender’s side, containing a displayor indicator. On the receiver’s side, the displayor is transformed into a sign, via apprehension action. There is an evidence duality between displayors and signs. An agent can have different interpretations of indicators. A direct report on the occurrence of an indicator is called de re report, i.e. primary (stronger) witnessing. A secondary report is called de dicto report, i.e. secondary (weaker) witnessing, or the “report on a report” of the occurrence of an indicator. Indicators can be representative or non-representative. An indicator that is intentionally displayed or apprehended is called representative. Indicators disconnected to any purpose, are called non- representative. An indicator which is such that the sender could not openly have

Monitoring Value Webs 113 displayed it, or which is such that its intended manipulatory effects could not have been achieved if the receiver had known that it was displayed, will be called a deceptive indicator. There is a strong social disapproval against it. If none of these two conditions hold, but the sender still wishes the fact that he is displaying, rather than acting with no intention, the indicator of action is only concealed. Indicators relate to purpose via communication competence, aiming to asses (or even prospect) if a certain displayed/apprehended action contributes effectively to accomplish the corresponding purpose. It relates to action in general by the principle of economic adequacy in rational agenthood: that actions can be assessed and selected so as to provide the most adequate and efficient way of achieving a certain purpose. In short, the model depicted in Fig. 1 represents parsimony on Allwood’s communication action theory. It encompasses not all but perhaps the most important concepts related to manageability in communication. The main concepts are stereotyped as metaclasses, which are extended to derive the Enterprise Monitoring Ontology, described in the next sub-section.

3.2 Enterprise Monitoring Ontology

Enterprise Monitoring Ontology structures a monitoring system from the perspective of a single agent involved in a business transaction [9-10]. Originally it is composed by other three sub-ontologies, each one representing a management view: goal (purpose) ontology, policy (norm) ontology and metric (indicator) ontology. For the sake of simplicity, the three views are collapsed here into a single view. The present version evolves the original one via alignment with the upper-level communication action ontology, previously introduced. It aggregates management concepts from key management theories, such as Contract Theory, Contract Law and the Balanced Scorecard. It is described as follows (vide Fig. 2). As a task ontology, EMO has a starting point and information flow. The starting point is the one of a basic transaction scenario, typical framework for Contract Theory, Contract Law and Communication Action analysis, involving an addresser and an addressee. Enterprise actors <> can play different roles: as a monitor <>, as a monitoree <>, as an external third-party <> or as a regulator <>. An Enterprise actor has an Enterprise goal <>. Goals can be classified into core business goals (C-Goal) and monitoring goals (M-Goal). C-goals are related to expectations on the performance of the core competence operations provided by an enterprise, whereas M-goals are subordinated to C-goals, and related to the performance of monitoring operations. Yet, goals are assessed regarding their economic feasibility <> through Enterprise indicators. According to Gruber and Olsen [15], indicators can constitute information objects in their own. They can be structured according to four generic dimensions, whose semantics vary according to the subject of indication: quantity, quality, time and space. There is a correlation between quantity and quality. Time and space change the quality of business commodities. This notion can be illustrated in the housing market, for instance. Indicators can also be used to assess economic adequacy of a policy <>.

114 P. de Alencar Silva and H. Weigand

Fig. 2. Enterprise Monitoring Ontology

According to the Role-Based Access Control model (RBAC) [16], a policy is generally structured as a double association defining who can do what. The semantics of a policy varies according to the target system. Here, it links actors (and its possible roles) with types of operations that give access to Enterprise commodities (i.e. Enterprise subject-matter or objects). Thus, a policy stereotypes actor roles according to what kind of operation they can perform, and what and how objects are manipulated. An Enterprise policy also defines possible permissible ways whereby a goal can be achieved <>. A relativist distinction is drawn between monitoring and monitored operations. Another important distinction regards the types of commodities that flow across the Enterprise boundaries. A monitored object is equivalent from the core business commodity being observed and controlled, whereas a monitoring object comprises information about the monitored one’s state of affairs. Monitoring objects comprise all kinds of evidence and witnessing reports (i.e. de re and de dicto reports [8]). A (monitoring) regulatory object comprises all the types of objects that unlock or disclosure access to the monitored object (e.g. accreditations, access rights, public keys and related instances) [17-20]. Finally, a counter-object refers to the objects offered in economic reciprocity for all the other types of

Monitoring Value Webs 115 objects. It comprises one of the principles of Economics from Mankiw [21], which states that the value of something is what you give up to get it. This definition comprehends both tangible and intangible value of a relinquishment. EMO has a flow component. First, a monitoree is assigned to a monitored operation via responsibility, whereas a monitor and a monitoring agent are assigned to a monitoring one via competence. Some transformation event axioms are imported from the Reference Business Ontology of Andersson et al. [22], which is REA-flavored. The transformation process follows. A monitored operation produces a monitored object. This in turn is used along with a corresponding (monitoring) regulatory object by the monitoring operation, so as to produce a monitoring object. The regulator gives regulatory objects to a monitor or/and a monitoring agent (acting on behalf of the monitor). The monitoring object is consumed by the monitor. Orthogonal to this classification, all the communication acts’ stereotypes apply to monitoring and monitored operations. The key concepts of actors, commodity and operations are polymorphous. For instance, an Enterprise actor playing the role of a monitor in a business transaction can play the role of a regulator or monitoree, in another transaction. The same applies to commodities and operations. Finally, Enterprise contexts enclose the validness of term and scope of Enterprise policies. Context is also a relative concept, and here, it refers to types of Enterprise operations, such as the one where the core operations occur (i.e. core context or c-context) and the ones of management operations, i.e. monitoring (m-context) and transformation contexts. Due to its polymorphism, EMO can produce multiple relativistic monitoring contexts (fractal-like), varying according to the perspective of the adopting agent. For the sake of space, some stereotypes presented in the upper-level Communication Action Ontology could not be shown in the current collapsed version of EMO. In the next section, the ontology is applied on a value web system.

4 Demonstration

In this section, the applicability of EMO is demonstrated. First, the business case problem is stated. Second, EMO is used to develop a value viewpoint on monitoring of Enterprise transactions in a value web.

4.1 Business Case The business case comes from the Music Industry market. More specifically, it is concerned with how Intellectual Property Rights (IPRs) on the use of digital music are currently managed. A simplified snapshot on this case is taken and is described as follows. The music consumer’s market is wide, but the segment considered here is the Horeca sector (Hotels, Restaurants and Cafes). There are plenty of alternative distribution channels whereby they can get the digital music commodity. Two paths are considered here: (1) music provided directly from the artistic segment, which includes all related artistic sub-segments, such as producers, lyricists, composers and related ones; and (2) music provided indirectly, via Digital Music Stores, which distribute/retail music. The first path is not the most convenient nowadays, but is possible. The core business case is illustrated in Fig. 3. Notice that it comprises a core business operation context, with its proper set of actors, operations and objects. According to the ontology, it encompasses the c-context in analysis.

116 P. de Alencar Silva and H. Weigand

Fig. 3. Digital Music Distribution Core Value Web

The Berne Convention has recognized the existence of the following IPRs related to artistic works: adaptation, broadcasting, cablecasting, distribution, reproduction and public performance [23]. A public performance regards not only live performances, but the exhibition of a recorded track with the aim of generating profit. Rights related to public performance of digital music tracks comprise the subject-matter of protection in this business case. Every time a commercial establishment plays a music track in public, it must pay for its corresponding IPRs (pay-per-play scenario). The value of music, therefore, has shifted since a long while from the physical commodity itself to its related Intellectual Property Rights or “Neighbouring Rights”. This is due to the “ease with which one or many copies of this type of commodity can be made in private homes or offices and other non-public places where any control over the reproduction of copyrighted material is either impossible (at home) or very difficult (in offices)” [24]. Each new invention threats the way IPRs are managed, therefore. The problem of this case is taken from the perspective of the artistic segment. Full monitoring of the number of instances a certain music track is played in public is not economically feasible or adequate (or nearly impossible). Even if all monitoring systems and devices are placed, and security choke points identified, the monitored object is not anymore monitorable on a 24h/7days a week. For instance, a single user may simply ignore all the online stores and turn on a simple music player device in public (or even make a music cover), and this can be done without leaving a trace. Nonetheless, this is one of the main sources of value creation in this business. As opportunistic behavior is difficult to identify and monitor in this case, the music industry is facing a crisis, and incentives for artistic creativity have been drastically reduced [25]. From a Requirements Engineering perspective, the problem of this case can be stated as how a value web from the digital music distribution can be monitored. Actually, this case is a typical monitoring case. In the following section, the Enterprise Monitoring Ontology is demonstrated.

Monitoring Value Webs 117

4.2 Applying Enterprise Monitoring Ontology on a Value Web System

EMO can be used to derive a value viewpoint on Enterprise transactions taking the perspective of the monitor role as the starting point. Monitoring can be treated itself as a market need, creating opportunity for market exploitation via provisioning of monitoring services. A monitor can be seen as a consumer of monitoring services, and his monitoring problem becomes the one of finding a web of enterprises which could supply this consumer with monitoring services. Thus, the ontology can be used by following a 3-step method, which it is called self-projection on Enterprise monitoring. As the term denotes, self- projection comprises the agent’s internal reasoning process, and does not need to be exposed a priori, but can be used as a strategic tool for negotiation with the other actors involved on the corresponding value web. It also consists on an early requirements analysis method.

Step 1 – Goal Projection: as discussed before, goals give direction to action. A monitoring goal (m-goal) supports a certain core competence business goal (c-goal). The later is subordinated to the former. Indicators can reify and define the economic feasibility of a goal. An example follows. For a certain Dutch artist, it would be economically sustainable to keep producing music (core business competence) for a certain time period and on certain location only if the number of public occurrences (performances) were equal or more than 5000 a month. Production here refers to the process of producing new music, and not to the reproduction of existent ones. As discussed before, the upper-level purpose is to incentive artistic creativity, as the value of the physical commodity in question (digital music) has become purely figurative nowadays. Thus, a goal could be represented by associating an Enterprise indicator with the business commodity needed. This would result in the 5-tuple (Quantity, Enterprise Commodity, Quality, Time, Scope). In this case, one among many c-goals could be defined as (5000, Music Performances, 0.9, Month, Zuid Holland), where the third parameter stands for the quality aspect in consideration, i.e. the probative/recovered value from the absolute price of a music instance, where 0 stands for a void value return, and 1, for full value returned. The goal reads “5000 music performances in a month, in the Zuid Holland province, with 90% of value return”. After a c-goal is defined, its corresponding/supporting m-goals can be likewise. One c- goal can be supported by many m-goals. Monitoring goals are fulfilled by monitoring objects. The problem now is to discover who has the economic competence to provide these objects and to assess the economic feasibility of this endeavor. This takes to the policy projection, on Step 2.

Step 2 – Policy Projection: as stated before, a policy defines permissible/prohibitive ways whereby a goal can be achieved. On this step, monitoring roles for actors, operations and objects apply. These roles are illustrated in Fig. 4, where the e3value graphical notation is decorated with UML-like stereotypes.

118 P. de Alencar Silva and H. Weigand

Fig. 4. Digital Music Monitoring Value Web

It is worth reminding that EMO defines Enterprise actors, operations and objects as polymorphous concepts. The behavior played by an instance of any of these concepts depends on the context in analysis. Moreover, digital music (i.e. the “physical” commodity) flows on the core web, but not on the monitoring one. As discussed before, the current value of this “physical” commodity is purely allegoric nowadays, and its value has shifted to its corresponding Intellectual Property Rights (IPRs). Actors: the role interplay in the monitoring value web, then, is described as follows. Here, a music producer is an IPR owner, and plays the role of a monitor. Music consumers are IPR consumers, and play the role of monitorees. The term is IPR “consumer” has a point in the sense that IPRs expire. Besides, although a commercial establishment from the Horeca sector “uses” music to generate profit (and not for proper consumption or entertainment), it is still worth to use the event axiom of consumption [22] for the sake of enclosing the object flow occurring in the value web. An important actor is included, the IPR societies, which support music producers with IPR management services. IPR management comprises collecting money from IPR users and distributing them to the IPR owners. In this web, IPR societies interplay as monitors, agents and regulators, switching between roles according to the value transaction. IPR societies are appointed by national governments to manage IPRs or Neighbouring Rights [23-24]. Finally, a music retailer, which is also an IPR user, plays the role of a monitoring agent. In this case, use has a different meaning from the one employed

Monitoring Value Webs 119 for the music consumers. Music retailers can get competitive advantage by transferring IPRs granted from IPR owners or societies to the consumers, as front-end enterprises. This is realistic and convenient for a music consumer, who would get the physical commodity bundled with its corresponding IPR. In exchange, they can serve as a strategic witnessing triangulation point between all the other market segments [18-19]. Operations: monitors and agents perform monitoring operations, whereas monitorees perform monitored ones. Thus, the operations of producing, using/distributing and managing music, performed by the music producers, retailers and societies, respectively, play the role of monitoring operations. The operation of consuming music, performed by the music users, is the monitored operation. This distinction is useful, as it makes sense to say that the performance of a monitoring operation depends on the outcome/display of its corresponding monitored one(s). For instance, the performance of the music production operation depends ultimately on the consumption of music. Objects: identifying the subject-matter to be monitored is critical for both core and monitoring contexts of a value web. Actually, they sustain (directly) the entire monitoring value web, as well as its supported core value web (indirectly). In the IPR case, it is necessary to think out-of-the-box. First, the monitored objects must be identified. Due to its ease of reproduction, digital music is not anymore a monitorable commodity, and, by consequence, has only an allegoric value (after firstly released). The event of using digital music is not monitorable either, for obvious reasons, but is highly valuable. But if there is a virtual channel whereby continuous access to witness the event of using music in public could be granted, this would not be the monitored object yet, but it could constitute the most tangible point of the monitored object of using music in public (a business event instance). Here, this object is reified on the Open Monitoring Channel object. The reason to adopt this concept, and not its corresponding event of using/playing music in public, is that, although information about occurrences of this event is often promised, it is seldom reliably delivered. An Open Monitoring Channel, moreover, is a value object which can be agreed upon, and can provide the channel for random inspections and sampling. Thus, these channels are here the monitored objects, granted from the music consumers to the IPR societies and IPR owners. Although in practice it is not economically efficient for an IPR owner to monitor a music consumer directly, it is competent, and therefore, valid. Monitoring objects are the second type to be identified. In EMO, they correspond to the indicators (displayors and signs), which reify information about the state of affairs of a certain monitored subject (e.g. actors, operations or objects). As a monitoring value object, a displayor can assume the form of a report of an observation. De-dicto reports are produced from direct observation; whereas de-re reports are produced from indirect observations (i.e. watch the watcher). Normally, the probative evidence value of a de-dicto report is stronger than a de-re one [17] [19]. Music consumers can provide de-dicto reports (i.e. Proof-of-Performance, PoP) to the music retailers (working as front-end enterprises). This is technically feasible, both online (e.g. via web streaming technology PoP) and offline (e.g. via PoP of membership). Other monitoring objects include de-re reports produced by the IPR societies from direct observation performed via Open Monitoring Channels to the IPR owners; and the ones produced by the music retailers, from direct reports provided by the consumers to either IPR societies or Owners, or both.

120 P. de Alencar Silva and H. Weigand

Regulatory objects are identified at third. Here, they grant rights to access/disclosure of the monitored object. IPRs are of this type. They are originally produced along with the music commodity, and after transferred to IPR societies and music retailers. Finally, counter-objects are added, so as enforce the principle of economic reciprocity. Two instances could be identified. First, the IPRs, which once transferred from owners to societies and music retailers, can be transferred again, with aggregated value. Notice that these are not different IPRs from the ones initially transferred, but they assume a different business stereotype, by polymorphism. They are offered in reciprocity of money and Open Monitoring Channels (from music consumers to IPR societies and IPR owners); and in reciprocity of money and de-dicto proof-of-performance (between music consumers and music retailers). In this context, IPRs work in a way that resembles a ticket in a train: it can be randomly inspected for tracing the monitored event (i.e. the service event instance). Finally, money complements all the six value transactions. There could be other counter- objects, such as the ones of intangible value, but that is not the case here. Final remarks regarding monitoring policies follow. First, monitored objects constitute the core business of a monitoring web, and if they can be traced, so can be all the other ones likewise. Second, EMO communication acts are all implemented on a value web: (1) transformation acts as internal value activities of use, consumption and production; (2) cooperation acts as value transfers; (3) display acts as the information pertinent to the value objects being communicated from a value out-port to an in-port one; (4) apprehension acts being captured on the converse way; and (5) coordination acts are captured via information flow, according to the semantics of a value policy, from actors to actors, through operations, as a an information “glue” pattern. Third, the monitoring web depicted in Fig. 4 is a monitoring policy matrix: it encompasses sub-policies whereby monitoring objects can be provided, which take the form of value creation paths or traces (vide tagged logical connectors). Last, as the monitoring objects constitute the ultimate output of a policy, they can be used to evaluate its economic efficiency. This takes to the indicators’ projection step. Step 3 – Key Value Indicators’ Projection: the concept of a Key Performance Indicator (KPI), from Kaplan and Norton [13] is here adapted to define indicators of organizational performance in value webs (KVIs). In EMO, indicators can be used to assess economic feasibility of Enterprise goals and economic adequacy of Enterprise policies. The value of a policy can be assessed indirectly from its output objects. In a monitoring policy, these objects are the monitoring objects. They are displayors of performance, communicated from the monitoree to the monitor. The value of a monitoring object can somewhat be deduced from the value of its corresponding counter-objects [21]. Each policy, corresponding to a value trace in the monitoring web (vide Fig. 4), outputs a monitoring object. KVI selection can be demonstrated by taking the IPR owner’s perspective, as a monitor. Monitoring objects received comprise the IPR proof-of-performance (de-re report) and the Open Monitoring Channel. The payment form (e.g. money) comprises the main counter-object. Possible instances of modifiers of quantity, quality, time and location were selected and adapted from earlier work on non-functional aspects of services [26]. The derived KVIs can be used to assess individual policies and are summarized in Table 1. After implementation and evaluation cycles, KVIs can be used on goal tuning, which brings to Step 1, closing the private (individual) self-projection cycle on value monitoring.

Monitoring Value Webs 121

Table 1. Suggestive Key Value Indicators – IPR Owner’s Perspective

Key Value Indicator (KVI) Output Value Object Quantity Quality Time Location Money (Payment) Event Acceptability Second Address (pay-per-play) Expiration Minute Ethernet Address Permit Immediacy Hour IP-Address (membership) Liquidity Day Point Negotiability Week Region Offline Month Route Online Year Street Directory Refutability … URI Security … Traceability Transferability IPR Pop: de-re Report Continuous Availability Temp. Locative Entity Negotiable Reliability Entity Nominated Open Monitoring Event Disclosure Temp. Locative Entity Channel Permit Exclusive Entity (Access) Prohibited Restricted Shared

5 Related Work

The outcome of this research can be confronted with related work in at least two aspects: earlier work on organizational monitoring and control in value webs; and their application on the case of IPR management in the music sector. Regarding the first aspect, the closest related approach is the one from Kartseva, Gordijn and Tan [27]. The authors treat monitoring in value webs as an organizational control problem. Patterns are defined to capture organizational controls and a method is proposed to select and compose these patterns so as to cope with a corresponding controlling problem. A critical drawback of this approach is that patterns are not the most appropriate reasoning tool to cope with monitoring situations where the monitored commodity is intangible or difficult to grasp. Business cases like the one treated here are more about idiosyncrasies than patterns. On the second aspect, the IPR case addressed here has been treated elsewhere. In the work of Gordijn, Yu and van der Raadt [28], the case is taken as a configuration problem, focusing more on how music can be provided within a value web rather than monitored. Taking another perspective on the case, Fatemi, van Sinderen and Wieringa [29] treat the IPR case as a coordination problem, demonstrating how value transactions of payment can be coordinated and aligned with underlying business processes. Nonetheless, from our best knowledge, this is the first time value modeling has been used per se to treat the monitoring problem of the digital music IPR management on its inner concerns.

122 P. de Alencar Silva and H. Weigand

6 Discussion

This work innovates how value webs can be monitored. Potential value of its contributions can be evaluated from the perspective of four corners: (1) as a design science artifact [3]; (2) a Requirements Engineering innovation; (3) an advance on IPR Management strategies; and (4) a contribution to the recently published Enterprise Engineering Manifesto [30]. First, in Design Science, models are the core subject matter. As a model, Enterprise Monitoring Ontology (EMO) is relevant for as it takes an important business problem as an argument. Its utility, quality and efficacy have been demonstrated on a real-world business case which challenges how Enterprise monitoring is currently performed. Second, as a Requirements Engineering contribution, it innovates in the sense of furnishing an important stakeholder’s group (business analysts) with a tool for reasoning on early (strategic) requirements on Enterprise monitoring operations. This has potential benefits on the alignment between businesses and corresponding processes and IT systems. Third, EMO application on the IPR case is a think-out-of-the-box endeavor. It explores rather than frame the case, producing alternative strategies instead of a final one. Last, it fits the Enterprise Engineering Manifesto agenda as an extension of the Enterprise Ontology, treating Enterprise monitoring as specific communication action phenomenon. This research has two immediate directions. The first comprises new deductions/partitioning on Allwood’s Theory on Communication Action so as to derive an ontology for Enterprise Transformation. Further inductions/merging can be performed so as to extract an upper-level Enterprise Management Ontology. The second direction regards the formal specification of an architecture that implements/realizes the Enterprise Management Ontology: the Enterprise Management Architecture.

References

1. Gordijn, J., Akkermans, H.: Value-based Requirements Engineering: Exploring Innovative e-commerce Idea. Requirements Eng. Journal 8(2), 114–134 (2003) 2. Alexander, J.C., Giesen, B., Münch, R., Smelser, N.J. (eds.): The Micro-Macro Link. University of California Press (1987) 3. Hevner, A., March, S., Park, J., Ram, S.: Design Science in Information Systems Research. MIS Quarterly 28(1), 75–105 (2004) 4. Dietz, J.: Enterprise Ontology: Theory and Methodology. Springer, Heidelberg (2006) 5. Austin, J.L.: How to do Things with Words. Harvard University Press, Cambridge (1962) 6. Searle, J.R.: Speech Acts: An Essay in the Philosophy of Language. Cambridge University Press, Cambridge (1969) 7. Habermas, J.: Theorie des Kommunikatives Handelns, Erster Band. Suhrkamp Verlag, Frankfurt am Main (1981) 8. Allwood, J.: Linguistic Communication as Action and Cooperation: A Study in Pragmatics. PhD Thesis, Göteborg University (1976) 9. Bolton, P., Dewatripont, M.: Contract Theory. The MIT Press, Cambridge (2004) 10. Lando, O., Beale, H. (eds.): Principles of European Contract Law (Parts I and II) – Prepared by The Commission on European Contract Law. Kluwer Law International (2000)

Monitoring Value Webs 123

11. de Alencar Silva, P., Weigand, H.: Enterprise Monitoring Ontology. In: Jeusfeld, M., Delcambre, L., Ling, T.-W. (eds.) ER 2011. LNCS, vol. 6998, pp. 132–146. Springer, Heidelberg (2011) 12. Guarino, N.: Formal Ontology in Information Systems. In: Proc. of FOIS 1998, Trento, Italy, pp. 3–15. IOS Press, Amsterdam (1998) 13. Kaplan, R.S., Norton, D.P.: The Balanced Scorecard: Translating Strategy into Action. Harvard Business Press (1996) 14. McCarthy, W.E.: The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment. Accounting Review 57(3), 554–578 (1982) 15. Gruber, T.R., Olsen, G.R.: An Ontology for Engineering Mathematics. In: Doyle, J., Torasso, P., Sandewall, E. (eds.) Proc. 4th Int. Conf. on Principles of Knowledge Representation and Reasoning. Gustav Stresemann Institut, Morgan Kaufmann, Bonn, Germany (1994) 16. Sandhu, R., Ferraiolo, D.F., Kuhn, D.R.: The NIST Model for Role-Based Access Control: Toward a Unified Standard. In: Proc. of the 5th ACM Workshop on Role-Based Access Control, pp. 47–63 (2000) 17. Jackson, J.D.: Law’s Truth, Lay Truth and Lawyer’s Truth: The Representation of Evidence in Adversary Trials. Law and Critique 3(1), 29–49 (1992) 18. Twining, W.: Rethinking Evidence: Exploratory Essays. Illinois Northwestern University Press (1994) 19. Pardo, M.S.: The Field of Evidence and the Field of Knowledge. Law and Philosophy 24, 321–392 (2005) 20. Luker, T.: Witnessing Whiteness: Law and Narrative Knowledge. ACRAWSA e- Journal 4(2) (2008) 21. Mankiw, N.G.: Principles of Economics, 4th edn. South-Western College Pub. (2006) 22. Andersson, B., Bergholtz, M., Edirisuriya, A., Ilayperuma, T., Johannesson, P., Gordijn, J., Grégoire, B., Schmitt, M., Dubois, E., Abels, S., Hahn, A., Wangler, B., Weigand, H.: Towards a Reference Ontology for Business Models. In: Embley, D.W., Olivé, A., Ram, S. (eds.) ER 2006. LNCS, vol. 4215, pp. 482–496. Springer, Heidelberg (2006) 23. Sterling, J.A.L.: World Copyright Law, 3rd edn. Sweet and Maxwell (2008) 24. Ricketson, S., Ginsburg, J.C.: International Copyright and Neighbouring Rights: The Berne Convention and Beyond, vol. I. Oxford University Press (2006) 25. SENA: Towards a New Sena – Annual Report (2010), http://www.sena.nl/files_content/ jaarverslag_en_jaarrekening_UK_DEF.pdf 26. O’Sullivan, J., Edmond, D., ter Hofstede, H.M.: Formal Description of Non-Functional Service Properties. Technical FIT-TR-2005-01, Queensland University of Technology, Brisbane (2005), http://www.wsmo.org/papers/OSullivanTR2005.pdf 27. Kartseva, V., Gordijn, J., Tan, Y.-H.: Designing Value-Based Inter-organizational Controls Using Patterns. In: Lyytinen, K., Loucopoulos, P., Mylopoulos, J., Robinson, B. (eds.) Design Requirements Engineering. LNBIP, vol. 14, pp. 276–301. Springer, Heidelberg (2009) 28. Gordijn, J., Yu, E., van der Raadt, B.: E-Service Design Using i* and e3value Modeling. IEEE Software 23(3), 26–33 (2006) 29. Fatemi, H., van Sinderen, M., Wieringa, R.: Value-Oriented Coordination Process Modeling. In: Hull, R., Mendling, J., Tai, S. (eds.) BPM 2010. LNCS, vol. 6336, pp. 162– 177. Springer, Heidelberg (2010) 30. Dietz, J.L.G. (ed.): Enterprise Engineering: The Manifesto, Final Version (January 2011), http://www.ciaonetwork.org/publications/EEManifesto.pdf

Author Index

Aveiro, David 93 Nagayoshi, Sanetake 61 de Alencar Silva, Patr´ıcio 108 Op ’t Land, Martin 1, 77 De Bruyn, Peter 31 Dietz, Jan L.G. 15, 77 Pombinho, Jo˜ao 1, 93 Guerreiro, S´ergio 46 Tribolet, Jos´e 46, 93 Hoogervorst, Jan A.P. 15 Van Nuffel, Dieter 31 Iijima, Junichi 61 Vasconcelos, Andr´e46 Liu, Yang 61 Verelst, Jan 31

Mannaert, Herwig 31 Weigand, Hans 108