EI and Coordination Science Miroslav Benda Boeing A summary report on the Enterprise Coordination Workshop that was held during the International Conference on Enterprise Modeling and Modeling Technology June 6 - 13, 1992. This a report on Enterprise Coordination Workshop that was held during the International Conference on Enterprise Modeling and Modeling Technology held on June 6 - 13, 1992. The workshop itself was a half a day session held on June 12, 1992. I reported the results of the workshop on June 13 in an half hour presentation to the conference participants. What follows is a synopsis of the workshop, of the presentation, and of discussions on the network before and after the conference. Those who participated and contributed to the discussions are: Richard Barson University of Nottingham Nottingham, England Christoph Bussler Digital Equipment Corporation Karlsruhe, Germany Ray Fleming British Aerospace PLC Broughton, England Les Gasser University of Southern California Los Angeles, California Caroline Gormley Digital Equipment Corporation Galway, Ireland Michael Huhns MCC Austin, Texas V. Jagannathan CERC Morgantown, West Virginia Herbert Koenig Siemens Aktiengesellschaft Meunchen, Germany Jintae Lee Massachusetts Institute of Technology Cambridge, Massachusetts Frank Lynch Digital Equipment Corporation Marlboro, Massachusetts Tom Malone Massachusetts Institute of Technology Cambridge, Massachusetts Charles Petrie MCC Austin, Texas Bruno Querenet Hewlett-Packard France Villefontaine, France Al Quillen 3M Greenville, South Carolina Baldev Singh MCC Austin, Texas Morris Sloman Imperial College London, England This report does not reflect all opinions expressed, nor does it represent all issues that the discussions identified. It simply is a brief discussion of the key issues of coordination science and its relationship to enterprise integration; the report also lists references for those who would like to know more about the technology. The first person singular statements and opinions are my "editorial comments"; the rest is the consensus of the workshop participants. Section 1. What is Coordination? We agreed to adopt the definition of the MIT Center for Coordination Science: Coordination is the act of managing interdependencies between activities. The context of this definition assumes that we have one or more actors performing some activities which are directed toward some goals. The interdependencies are relationships between activities; these relationships are a consequence of the activities having to work together in order to reach the goals. Examples of interdependencies include prerequisites (a task needs to be accomplished before another task), shared resources (a shared facility such as a hangar, a conference room, a camera of a satellite), geometrical constraints (one part needs to fit another part), etc. Section 2. What is Enterprise Coordination? A typical enterprise has a number of actors performing activities, i.e. executing business processes directed toward achieving the goals of the enterprise. Goals are at various levels of abstraction: 20% return on stockholder equity being one example, release of a product on a certain date being another example. An enterprise thus provides a context for coordination: Enterprise Coordination is the act of managing interdependencies between business processes of an enterprise. Or, in other words, Enterprise Coordination is the act of applying the principles of coordination science to enterprises. 2.1 Examples of Enterprise Coordination Different enterprises approach the problem of managing interdependencies differently. Here are four historical examples that I used in the workshop (the term enterprise is taken in a very broad sense): 2.1.1 The Boeing Red Barn This was the precursor to what is now called concurrent engineering. In the 1920s it was accomplished by having the engineers and fabrication people in one "room" that served as a medium for resolving the dependencies among individual designers. The dependencies in this example included the geometric and functional relationships among the multitude of parts that need to be satisfied in the final assembly of an airplane, the goal of the activity. 2.1.2 Central planning The former Soviet Union and other countries tried to coordinate their economies, distribution of goods and capital, by a centrally constructed plan. The purpose of the plan was coordination of industry activities toward a set of goals, typically five years in the future. This experiment proved to be a failure; planning and replanning on this scale is not efficient enough to respond effectively to changes in the system. 2.1.3 Desert Storm This is an example of coordination among several armies that used typical hierarchical and negotiation mechanisms and fairly effectively achieved its goal. 2.1.4 India Empire P. Drucker's article on coordinating mechanisms (see Drucker) uses the British rule in India as an example of how a vast undertaking can be coordinated by a relatively shallow, when compared to the previous example, hierarchy. Section 3. What is the Relationship Between Enterprise Coordination and EI? The official definition of enterprise integration is "an improvement in coordination that benefits one or more of the participants". Enterprise coordination then becomes the object of improvement in enterprise integration activities; from the perspective of definitions the relationship between enterprise integration and coordination is academic. The true nature of the relationship comes to the surface when we consider the types of activities that have been going on in these fields during the past few years. It will be useful to preface this discussion with a discussion of some key characteristics of coordination. Section 4. Dimensions of Coordination By dimensions we mean characteristics that, in the context of a coordinating situation, pertain to the nature of the actors, the nature of the dependencies, coordinating mechanisms, time, etc. Some of the dimensions that we identified at the workshop are: o intelligence of actors (from hardware to software to humans) o coordinating mechanisms (from decentralized to centralized) o abstraction levels of dependencies (from micro level to macro levels) o time horizon of goals (from tomorrow to decades in the future) o coordination tactics (coordination by standards, training, etc.) o coordination strategies (policies, culture, visions) All of these dimensions have a meaning in the context of enterprise integration. To illustrate the relationship between Enterprise Coordination and Enterprise Integration we picked the first two dimensions; the domains of the current focus of Enterprise Coordination and Enterprise Integration can then be depicted as follows: FIGURE 1. Enterprise Coordination and Enterprise Integration Relationship Enterprise Integration activities have been concentrated primarily in the area of computing platforms, interoperable databases and application packages, and networks. A single central enterprise model, one of the visions of enterprise integration, is an example of the centralized approach. However, the recent activities in enterprise integration do spread away from the lower left hand corner of the diagram. The Reference Taxonomy Model of Enterprise Integration developed by the previous workshops allows other than centralized mechanisms for integration, federation being one example. On the other axis, let us look at enterprise integration frameworks, such as CIMOSA and Zachman's framework. CIMOSA has been thoroughly discussed at the conference by the European participants, Zachman's framework received attention as well. Both of these frameworks now contain explicit references to the human element of information systems; CIMOSA has its Organization View in the model and Zachman (with Sowa) added columns of essentially the same content (see IBM Systems Journal ...) to his framework. However these developments are relatively recent and have not been integrated with the traditional information systems disciplines. Enterprise Coordination, on the other hand, is primarily dealing with the interaction of humans or of humans and software; the coordinating mechanisms that it investigates tend to be more on the decentralized side. Enterprise Coordination is an interdisciplinary theory and the disciplines that it draws on include Organization Theory, Computer Science, Economics, and Biology; the specific areas in these disciplines are organization design, distributed AI, agency theory, and interaction of living things, respectively. I chose these examples in order to support the placement of Enterprise Coordination in the diagram above, but the examples are in no way contrived. The relationship between enterprise coordination and enterprise integration is thus complementary. Is there a need to distinguish between the two, to draw a boundary? I do not believe so in the long run, but I feel that the distinction is useful while the fields are in their formative stages; I will keep the distinction throughout the paper. Section 5. How can Enterprise Integration Benefit from Coordination Science? At the workshop we listed six potential or existing areas of contribution: 5.1 Integration of people, organizations and technology (specific examples include HITOP and REMBRANDT systems that were reported on at the conference) 5.2 Metrics for the performance of coordination mechanisms (specific examples include the work B. Singh at MCC and B. Huberman at PARC) 5.3 Minimization of scope and agreement (the principle of bounded rationality and the principle of "agree to disagree") 5.4 New mechanisms and explanations for the integration of social action, culture, and history (see C. Savage's book in the references) 5.5 Sensitivity to the dynamic nature of models (an enterprise model must be adaptable and evolvable; i.e., models come and go) 5.6 The cost of coordination In this area I shall go into more detail. The cost of enterprise coordination or enterprise integration is, of course, of great interest to the enterprise. As in a number of other similar situations, the law of diminishing returns suggests that more coordination or integration is not necessarily better. The simple model below makes this point clear. If we imagine the goal of an enterprise to be a point in an n-dimensional space then, in the absence of any "force fields" and in Euclidean geometry, the best path for the enterprise to follow would be on a "straight line", EP, in the direction of the goal, SPi. The actual path of the enterprise at a given moment in time is a result of individual actions toward a perceived goal; this perceived goal and the best direction on how to reach it typically differs, D, from one individual to another as shown by the short arrows below: DIAGRAM 2. Cost of Coordination The difference between the optimal and actual direction of the enterprise is what enterprise integration strives to minimize. However, there is a cost associated with the minimization. Assume that we actually have a function that computes the cost, C(D), of achieving a level of coordination represented by D, the difference between the actual and the optimal direction. Conceptually, this function might look as follows: DIAGRAM 3. Optimizing Cost The high cost of coordination when D is small is the cost of trying to attain perfection. The high cost of coordination when D is large is that the enterprise either is not coordinated-individual efforts pretty much cancel one another out-or it is coordinated but it is producing something that is not compatible with the goal of the enterprise, with what it had set out to produce. Ringelman's effect (see Kravit) provides a simple scenario to illustrate this. We have a team whose task is to lift a weight by pulling on a rope that goes over a pulley. Ringelman found that a group of eight can lift approximately 50% of what might theoretically be achievable: 8 times the weight that one individual can lift. We can imagine that proper training, and diet could bring this figure to perhaps 80% or even 90% of the ideal maximum. The cost of that would be high. On the other side of the spectrum we could imagine a group of gorillas that, even if tied to the rope, would not lift anything because of a completely uncoordinated behavior or that might, in a coordinated fashion, be "pushing" on the rope. Coordination science has a potential to contribute to the understanding of the trade-offs between the end-effect of a coordinated activity and the effort it takes to have the activity coordinated. An example of a study along these lines on this subject includes (Benda). Naturally occurring examples of collective behavior, ants, bees, provide useful examples to analyze and gain understanding of how nature manages to strike the right balance. Section 6. Specific Coordination Science Contribution This section contains an elaboration on some of the ideas proposed at the workshop to answer the question of how Coordination Science can contribute to Enterprise Integration. At the conference itself we have not had time to develop any of the ideas mentioned as potential contributions of coordination science to enterprise integration. The idea that I want to elaborate on is to build on research being proposed by Malone's Center for Coordination Science at MIT. The objective of that research is to develop a "process handbook" which organizations could use to invent new organizational processes and redesign existing organizations. To reach this objective the center proposes to build the "right" tools based on the "right" process representations. How can we use this in enterprise integration? The development of tools for design of business processes is following a path similar to that taken by computer aided design, CAD, tools. Currently, the tools for design of processes are mostly equivalents of drafting packages available to designers of electromechanical components ten years ago. Modern CAD tools, intelligent CAD, contain concepts of higher order of abstraction than the geometry of a specific part: parametrized design and object features are two examples. These concepts enable creative and more reusable design and powerful analyses of the components from various viewpoints. We would, of course, like to have the same capabilities for the design of business processes: creative and reusable process designs and powerful analyses of design processes. As in CAD, (where the wire-frame model was replaced by the solid model, which, in turn, is being augmented by exact geometry and functional representation, etc.) new representations and concepts need to be brought into consideration. The new concept that MIT brings to the table and that seems very promising for rational design of business processes is the concept of dependencies. The reason for designing or modeling a business process is coordination: everyone sings from the same sheet. As we have seen above, dependencies between activities are the primary causes of having to coordinate. A taxonomy of dependencies shared by all could then become a foundation for the design of business processes. With each category of dependencies we could associate the alternative coordinating mechanisms that deal with the dependencies. These coordinating mechanisms would then form the "standard parts" from which to design a new process or construct a model of an existing process. The information system of an enterprise is the ultimate goal of enterprise integration. The information system provides the global coordinating mechanism for enterprise integration if we assume that the information system contains the definition of the business processes used to run the enterprise. To integrate an enterprise we thus need to integrate the demands on information flows generated by the business processes and the opportunities or possibilities generated by advances in information processing technology. The primary driver of this integration is the design of business processes. Below are the linkages that tie all the pieces just discussed together: DIAGRAM 4. Coordination Sciences View On Enterprise Integration The advantages of basing process modeling, design and analysis on the concept of dependencies are several. I will discuss two: one concerning intra-enterprise integration and one dealing with inter-enterprise integration. A uniform taxonomy of dependencies and the associated coordinating mechanisms provides a common set of components from which to build business processes. The implication is that process descriptions become more uniform and reusable across the enterprise. The reason is that dependencies, unlike processes, are not organization specific: an organization cannot choose dependencies, they simply are a part of the "objective reality" of the organization. An organization "selects" coordinating mechanisms to deal with its dependencies, which defines the processes of the organization. This provides a very modular, one might say object-oriented, approach. Dependencies are also independent of enterprises. This is important for inter-enterprise integration since enterprises typically want to keep their business processes to themselves. To integrate several enterprises on a common program, it is only necessary to identify the inter-enterprise coordination dependencies and select the inter-enterprise coordinating mechanisms for dealing with the dependencies. These then become constraint on intra-enterprise coordination that can be accomplished internally. A diagram summarizing the relationships of these concepts, the Enterprise Integration Reference Model, and inter- and intra- enterprise coordination is given below: DIAGRAM 5. Inter-/Intra-Enterprise Integration Coordination View An arrow, X -> Y, indicates that Y can be derived or instantiated from X. The relationship between Dependencies and the EI Reference Model is an open question. The relationship between dependencies and enterprise business processes, an objective of MIT research, is also open, but there we have at least have an approach. This diagram encapsulates most of the concepts we have been discussing. We can again see a nice complimentary between enterprise coordination and integration: coordination is focused mostly on the left side of the diagram, the business processes; enterprise integration focuses on the right side of the diagram, the information systems. More details on the linkages and their significance of how they facilitate inter-enterprise integration will be forthcoming. Section 7. Sources of Information About Coordination Science This is a recommended reading on coordination science; the papers cover a wide variety of perspectives. Papers explicitly mentioned in the text of this paper are listed in References section. J.S. Brown, Research that Reinvents the Corporation, Harvard Business Review, Jan.-Feb. 1991, pp. 102-111. S. Clearwater, T. Hogg, B. A. Huberman, Cooperative Problem Solving, in Computation: The Micro and the Macro View, ed. by B.A. Huberman. World Scientific Publishing, 1992. R. Howard, The CEO as Organizational Architect: An interview with Xerox's Paul Allaire, Harvard Business Review, Sep.-Oct. 1992, pp. 107-121. T.W. Malone, K. Crowston, Toward an Interdisciplinary Theory of Coordination, Center for Coordination Science Tech. Report 120, MIT. T. W. Malone, K. Crowston, J. Lee, & B. Pentland, Tools for Inventing Organizations: Toward a Handbook of Organizational Processes. MIT Center for Coordination Science Working Paper, Cambridge, MA, October 1992. T.W. Malone, J.F. Rockart, Computers, Networks and the Corporation, Scientific American, Sept, 1991, pp, 128-136. B. Singh, Interconnected Roles (IR): A Coordination Model, MCC Technical Report Number CT-084-92. Section 8. References M. Benda, R. Dodhiawala, V. Jagannathan, On Optimal Cooperation of Knowledge Sources, Boeing Technical Report BCS-G2010-28, 1985. C. Savage, 5th generation management: Integrating Enterprise through Human Networking, Digital Press, 1990. P. Drucker, The Coming of the New Organization, Harvard Business Review, Jan.-Feb. 1988, pp. 45-53. D. Kravit, B. Martin, Ringelman Rediscovered: The Original Article, J. of Personality and Social Psychology, vol. 50 (1986) No. 5, pp. 936-941)