Copyright C IF AC lDIdligent ManuflldUl'ina Systems, Vienna, Austria, 1994 POSSIBILITIES AND LIMITATIONS OF REUSING ENTERPRISE MODELS (New Requirements for Enterprise Engineering Tools) P. BERNUS·, L. NEMES··, R. MORRIS··· • School of Comp . and Info.Techn ., Grifflth Univ ., Nathan Qld 4111 Australia (bemuaOcit .gu . edu .au) •• Division of Manuf. Technology, CSIRO , Preston VlC ., 3072 Australia (InmOmlb.dmt .ceiro.au) ••• Dept . Computer Science, Florida In.t. of Technology, USA (morriaOce.ftt.edu) Abstract. An account is given of the possibilities and limitations of reusing Enterprise Models (EM). Measures are identified which ensure that models are interpreted as intended, thereby controlling the quality of the processes using enterprise models - such as enterprise engineering. A definition of model completeness is presented, based on a pragmatic theory of meaning and theory of communication. New requirements for Enterprise Engineering CASE tools are discussed. Keywords. Enterprise Modelling, Enterprise Integration, Theory of Meaning, Concurrent Engineering, Enterprise Engineering 1 INTRODUCTION 1.1 Why Enterpri6e Goal6. Enterprise Engineering is based on the belief that an enterprise, as any other complex system can be de- signed or improved in an orderly fashion thus giving a better overall result than ad hoc organisation and design. Enterprise Engineering is a large-scale design effort usually carried out by a team of designers, analysts and managers. Enterprise Modelling (EM) encompasses all those modelling tasks which arise in the process of enterprise engineering. EM uses various languages, methods and tools to achieve its goals. These vary according to the life-cycle of the enterprise. Such life cycles are cap- tured in generic models, called Enterprise Reference Architecture (Williams et ai, 1993) . In this article the nature of Enterprise Models is dealt with as used in Reference Architectures, or life-cycle models. EM-s can serve a variety of pur- poses: a. To express the design or re-design of the information- and material flow of the enterprise; b. To achieve common understanding of the enter- prise by participants (management, workers etc) ; c. To control the enterprise based on the model. 1.2 Problems 1.2.1 Need to reU6e models. Although the return from producing high quality enterprise models for en- terprise engineering can be significant model building from scratch is unacceptably expensive for a large part of industry (esp. small and medium scale), and there is a recognised need to share and reuse previously duced models. There are two types of models which 11 lend themselves for reuse: generic model6 and paradig- matic mode16 (where a typical, particular case is cap- tured and is subsequently modified to suit the new situation} ). 1.2.2 Sharing and reu6ing model6. Given the need of reuse it is important to investigate if such models can be really shared. And, if they can, to what extent . Notably, what is it that ensures that the information a model was intended to carry is not distorted in the process of reuse? Are there any guarantees that mod- els are correctly interpreted in a new context? 1.2.3 Completeneu and con6i6tency of enterpri6e model6. Those enterprises who purchase models for reuse would like to have guarantees that the mod- els contain the information necessary for a successful reuse. This need is in stark contrast with reality: it is known to practitioners that EMs are almost never complete in the sense of complete formal specifica- tion, like that of a cCJmputer algorithm. What then, is a useful definition of completeness and how can it be achieved? The main purpose of this article is to give a practically applicable criterion for completeness of enterprise models. Firstly, two important features of EMs need to be un- derstood: • The range of phenomena addressed by enterprise modelling stretches multiple disciplines. Multiple modelling languages and practices are used, and there is no single person/profession who would be able to guarantee consistency; 'The two cases roughly correspond to top-down design and case based design respectively.