Enterprise modelling is the process of building models of whole or part of an enterprise (e.g. process models, data models, resource models, new ontologies, etc.) from knowledge about the enterprise, previous models and/or reference models as well as domain ontologies using model representation languages. This paper reviews commonly used languages for enterprise modelling (CIMOSA language, ARIS ToolSet language, ER models / EXPRESS, GRAI nets, IDEF suite of models, IEM, OOA / OMT, Petri nets, SA/RT, logic-based languages) and compares them on the basis of a list of essential requirements for enterprise modelling.

Currently, there is an increasing need in industry for sound and precise techniques for enterprise modelling and capitalisation of acquired experience and know-how. Enterprise modelling (EM) is perceived as a pre-requisite for Enterprise Integration (EI). People need to better understand their business operations, re-engineer, simplify or out-source their business processes, enforce the company culture and share data and knowledge or develop common applications with partner companies. Enterprise modelling must therefore provide a set of common languages to describe various aspects of the enterprise at different abstraction levels (e.g. business level, engineering level or operational level) and from different angles (e.g. function view, information view, organisation or economic views) (CEN, 1990).

Furthermore, due to rapid changes of economic, geo-political and technological conditions, enterprises must be able to quickly and easily adapt to change. This is called agility. Therefore, modern enterprise systems must be engineered, implemented and integrated in a systematic way very similar to approaches developed for software engineering. This emerging discipline is termed Enterprise Engineering. Enterprise modelling plays a central role in this process because many design, planning, optimisation, performance evaluation or decision-making activities rely on the use of models. Hence, enterprise models must become the basis for business entity design as well as for business entity control and reengineering.

Various techniques have been proposed or borrowed from other fields over the last two decades to deal with enterprise modelling such as the IDEF suite of models, CIMOSA, ER models / EXPRESS, GRAI nets, IEM, OOA / OMT or ARIS ToolSet, but also Petri nets, SA/RT, statecharts and logic-based languages as surveyed by Vernadat (1996). The survey shows that enterprise modelling techniques have evolved from early diagrammatic methods (e.g. SADT, ER models, IDEF tools) to more process-based or workflow-oriented methods (e.g. extended Petri nets, CIMOSA, IDEF3, IEM) which lend themselves to process simulation and enactment. A more recent trend is to consider logic-based languages (for instance, using first order logic) to model procedural and intentional aspects of the enterprise and capture more of the semantics of enterprises in the form of ontologies (Fox et al., 1993).

In this paper, enterprise modelling requirements (as understood nowadays) are first stated. Then, various enterprise modelling notations and languages used in practice are indicated and compared according to modelling features required for enterprise modelling.

An enterprise model should describe the rationale, organisation and behaviour of some business entity (i.e. a part of an enterprise as defined by business users) to support decision making regarding its engineering, control and maintenance. Due to the complexity of the reality to be described, the enterprise model is in fact a collection of models representing various facets of the business entity.

An enterprise model should not be a static view, or a 'snapshot', depicting a business entity at a given point in time. It must contain a representation of the core knowledge about what the enterprise is, how it is organised, what it does and how along the various stages of the enterprise life cycle. It must be kept up-to-date and is therefore itself a dynamic entity.

Enterprise modelling is the process of building and maintaining models of whole or part of an enterprise (e.g. process models, product models, data models, plant layout models, computer network configuration models, organisation models, etc.). It is obtained from knowledge about the enterprise, previous models and/or reference models as well as specific domain ontologies (when they exist) using model representation languages.

Essential features of an enterprise to be modelled include:

Essential modelling principles applicable to enterprise models include (Vernadat, 1996):

- The principle of separation of concerns to analyse a business entity piece by piece and thus break down complexity of enterprise models;

- The principle of functional decomposition introduced by SADT and based on a stepwise-refinement approach to go from a general view to detailed views of a system;

- The principle of modularity where models are made of interconnected building blocks, thus facilitating management of change and maintenance of models;

- The principle of model genericity where standard building blocks are defined as generic classes which can then be specialised to particular needs;

- The principle of reusability to reduce modelling efforts and increase model modularity by the use of pre-defined partial models;

- The principle of separation of enterprise behaviour and functionality to increase organisational flexibility, i.e. enterprise behaviour can be updated without changing installed functionalities and vice versa;

- Finally, the principle of process and resource de-coupling which structures an enterprise as:

The last principle is very important in order to get operational flexibility of the organisation. Business processes indicate the overall logic of what has to be done in the enterprise to achieve business objectives. Functional entities are autonomous units (devices, applications or people) which must execute business processes according to real-world situations, imposed due dates and must react to perturbations. If resources are tightly coupled to processes, the model defines a rigid structure not suitable for the agile enterprise.

On the basis of these requirements, enterprise reference architectures have been defined such as CIMOSA (AMICE, 1993), ENV 40 003 (CEN, 1990), PERA (Williams, 1992) or GERAM (Williams et al., 1994; Williams, 1995). All these architectures recommend that an enterprise modelling paradigm should deal with:

- three modelling levels for requirements definition, design specification and implementation description of the business entity;

- at least four modelling views, namely:

- function view to cover enterprise functionality and behaviour aspects

- information view to cover data and information aspects

- decision/organisation view to cover decision centres and responsibility aspects

- resource view to cover resource requirements and management aspects

- the role and place of humans in a particular enterprise architecture

- and be supported by a modelling methodology.

An important feature of any enterprise modelling language is to be able to explicitly model the three fundamental flows existing in any company, namely the information flow, the material flow and the control flow. This is especially important for manufacturing enterprises because each flow requires a different infrastructure and the three types of flows are interrelated and must be co-ordinated.

The information and material flows can be collectively modelled as object flows of two different natures. In production systems, the problem is to synchronise material flows with associated information flows.

The control flow (or workflow) defines the logic of business processes, i.e. the enterprise behaviour in terms of a sequence or order in which enterprise activities (defining the enterprise functionality) must be performed to achieve business objectives. Business processes can represent administrative procedures, technical processes or support processes. The modelling language must be able to represent the triggering condition of each process (event), the sequence of process steps to be followed (the workflow) and the goal to be achieved by the process (end-result).

Deciding whether the information, material and control flows must be modelled separately or within a unified paradigm remains a secondary or implementation issue as long as they are differentiated in the modelling paradigm.

Other important aspects to be considered when modelling business processes and related concepts (such as information, resource, human and organisation aspects) of an enterprise concern dynamic aspects, i.e. temporal aspects, co-operative activities and process communication, process synchronisation and exception handling mechanisms.

Temporal aspects: The control flow of a process only defines causal relationships governing the enterprise behaviour. Dynamic aspects must add to that the time dimension, especially time-based requirements in the triggering of processes, triggering frequencies and possible delays between process steps. Process step durations (minimum, maximum, average durations) can also be indicated for simulation purposes.

Co-operative activities: In practice, it is common that two or more activities of two different processes must work co-operatively, i.e. exchange messages or objects. In computer science, two fundamental mechanisms are used to support this: message passing and shared memory. Message passing requires four fundamental operations: send (a, m) to send message m to activity a, receive (a, m) to receive a message m from activity a, request (a, m) to request message m from activity a and acknowledge (a) to let activity a that its message was received. Shared memory is another way of communication where two agents involved in different activities will use the same medium to exchange information or objects. Access to the shared medium is usually governed by some pre-defined rules defining the access protocol. Similar mechanisms or at least some indication of co-operation between activities must be provided by enterprise modelling languages.

Communicating processes: In the case processes must communicate, this means that some activities of one process must interact with activities of other processes. The previous mechanisms for co-operative activities can be used.

Process synchronisation: Process synchronisation can happen in three different forms: (1) synchronisation by events, (2) synchronisation by messages and (3) synchronisation by object flows. Assuming that an event represents a change in the system state (e.g. happening, end of an action, issuing an order or even a clock time), synchronisation by events consists in raising an event which will trigger an action. This way a process can raise an event which will trigger another process. Synchronisation by messages concerns the case where a communication is established between two or more communicating processes using the mechanisms described for co-operative activities. Finally, synchronisation by object flows (information or material objects) happens when a process step needs objects as inputs provided as outputs by other process steps (of the same process or other processes).

Exception handling mechanisms: Workflows usually model the ideal structure of a business process. Real-world situations mostly consist of dealing with exceptions. Exception can either be predictable or unpredictable. Unpredictable exceptions cannot be handled by the model. Predictable exceptions can be detected by means of Boolean conditions defined on some system variables (indicators or decision variables). Again, computer science provides two fundamental mechanisms to deal with exceptions which can be used in enterprise modelling. The first one is called a 'watch-dog' and consists of a predicate and an action clause. When the predicate evaluates to true, the process step is suspended and an exception handling procedure indicated by the action clause is called. The second one is called a 'time-out' and consists of a specified duration and an exception clause. If the specified duration is exceeded during the process step execution, execution is suspended and the exception handling procedure is activated. These mechanisms should be used in enterprise modelling.

Enterprise modelling has its roots in systems and especially information systems modelling. The first methods dealing with enterprise modelling were the entity-relationship approach of Peter Chen (1976) and SADT of Douglas Ross (1977). These methods mostly concentrate on the information view and function view of a business entity, respectively. They have been followed by numerous methods for software engineering (SSAD, Yourdon, De Marco, to name a few). These have been reviewed by Martin and McClure (1986). Specific methods for enterprise modelling in the context of CIM appeared in the early 1980's. They include the IDEF suite of methods (ICAM, 1981) and the GRAI method (Doumeingts, 1984) followed by GRAI/GIM (Doumeingts et al., 1992). These were activity-based methods which have been surpassed on the one hand by recent process-centred modelling methods (ARIS, CIMOSA, IEM) and on the other hand by object-oriented methods (OOA, OMT and the like).

In this survey, we consider the following representative methods, listed chronologically. All these methods can be or have been used for enterprise modelling exercises. Some have not been designed specifically for enterprise modelling and each of them has its own objective, purpose and scope, therefore focusing on some aspects mentioned earlier and ignoring partially or totally others.

- Entity-relationship methods: They are based on the entity-relationship (ER) model originally proposed by Chen (1976) and the many extensions of this model. The model describes a universe of discourse in terms of entities (identifiable things), relationships among entities and their attributes. Models produced are static descriptive models. They only concern the information view of an enterprise. More recently, a formal data description language called EXPRESS has been developed on the basis of the ER model to specify STEP entities and is widely used in applications for integration in manufacturing (ISO, 1992).

- SADT is a structured analysis and design technique proposed as a language for communicating ideas (Ross, 1977). In fact, SADT is a graphical notation to represent complex systems in terms of sub-systems. Its major contribution was (1) to provide a simple but yet widely accepted definition of an activity (ICOM box or input / control / output / mechanism box) and (2) to stress the functional decomposition principle. Models produced are static descriptive models. Many SADT tools exist.

- IDEF suite of methods: IDEF0, IDEF1x and IDEF2. IDEF tools produced by the ICAM project (ICAM, 1981; Mayer, 1992) have played a pioneering role in enterprise modelling for CIM. IDEF0, which equals to SADT, is used for the function view. IDEF1x, which is a derivative of the basic ER model, is used for the information view. IDEF2, which is based on the graphical notation of the simulation language SLAM, provides a dynamic model. Models produced remain static descriptive models. Commercial tools for IDEF methods exist.

- GRAI and GRAI/GIM: The GRAI method, with its GRAI grid and GRAI nets, focuses on the decision-making aspects of an enterprise (Roboam, 1993). It has later been expanded to cover the function view, information view and organisation view of an enterprise in the form of the GIM method (Doumeingts et al. 1992). Models produced are static descriptive models.

- Petri nets: Petri nets are powerful graphical and mathematical tools to represent and analyse discrete event dynamic systems exhibiting concurrency and synchronism (Murata, 1989). Various extensions of Petri nets, especially high-level Petri nets and object-oriented Petri nets can be used for enterprise modelling to deal with function, information and resource view aspects (DiCesare et al., 1993). Models produced are analytical models supporting qualitative and quantitative system analysis and are executable models.

- SA / RT (Ward and Mellor, 1985) is a semi-formal system analysis and design technique dedicated to real-time and reactive systems. It mostly addresses the function view but also the information view (in the form of data flow diagrams or DFDs) of an enterprise system with a special emphasis on behavioural aspects. Models produced are descriptive models of system behaviour, which can be executed.

- OOA and OMT: Object-oriented methods such as OOA (Booch, 1994) and OMT (Rumbaugh et al., 1991) are claimed to be potential tools for enterprise modelling, dealing with static and dynamic aspects of information. In terms of enterprise modelling, they can be applied at the requirements and design modelling levels but only cover the information view. Object-oriented languages can be used as implementation tools at the implementation level.

- CIMOSA (AMICE, 1993) has been proposed as one of the first reference architectures for enterprise modelling and integration for manufacturing applications. It includes a modelling framework, based on modelling principles stated in section 2.2, and has coined the concept of business process. It covers function, information, resource and organisation aspects of an enterprise at various levels thanks to its detailed process model (Vernadat, 1993). CIMOSA has heavily contributed to work in standardisation (CEN, ISO) and for GERAM genesis.

- IDEF3 (Mayer et al., 1992) is a graphical notation used to capture a process description. It has been developed to overcome the shortcomings of IDEF2 and to model business processes. It is made of a limited set of constructs to describe process steps (called units of behaviour) and their connections (junction types and links). Models produced are static descriptive models. However, they can be expanded and translated into timed Petri nets for analysis and simulation purposes. Tools for IDEF3 exist.

- IEM (Spurr et al., 1995) is another reference architecture for enterprise modelling. It mostly covers the function and information views of enterprises. It is based on an object-oriented modelling approach where the central construct is the IDEF0 ICOM box in which all inputs and outputs are object states of the three fundamental types: orders, products or resources.

- ARIS ToolSet (IDS, 1995) is a product from IDS Prof. Scheer GmbH. It is first of all a reference architecture for information system analysis made of a function view, a control view, a data view and an organisation view. The modelling language is organised around the concept of an event-driven process chain (EPC) which borrows a lot to the CIMOSA process model. Although originally developed as a software engineering workbench, ARIS can be used for enterprise modelling at the requirements, design and implementation levels and is currently one of the most advanced tools available on the marketplace.

The different methods mentioned in the previous section are evaluated in this section in terms of their suitability for enterprise modelling using requirements criteria defined in section 2. Results are presented in the form of two tables, Table 1 and Table 2.

One may argue that the comparison is like comparing pears and apples. These methods have not been developed to tackle the same goal. Indeed, the intention of these tables is not to compare these methods against each other but only to assess capabilities and application areas of each of them in the context of enterprise modelling.

Table 1 evaluates the modelling methods in terms of essential underlying modelling principles and coverage in terms of modelling views. Indication is also given concerning the nature of the modelling language (formal, semi-formal, not formal).

Table 2 evaluates methods against the modelling capability criteria, especially their suitability for each modelling level (requirements, design, implementation), object flow modelling (control, information, material) and control or non-determinism issues.

From Tables 1 and 2 it appears that CIMOSA, IEM, ARIS and to some extent IDEF3 are the tools which cover most of the requirements. This makes sense because each of them has been developed with enterprise modelling purpose, and especially business process modelling, in mind.

Table 1. Modelling principles and coverage

Table 2. Modelling capabilities

The methods analysed so far could be classified as either activity-based, process-based or entity / object-based methods. A more recent trend is to approach enterprise modelling from an ontological perspective.

An ontology is a formal description of entities and their properties for a given domain. It forms a shared terminology for the objects to be communicated in that domain, along with the definitions of the meaning of each of the terms employed (Gruber, 1993).

The use of ontologies and micro-theories for enterprise modelling has been suggested by Prof. Fox and his colleagues and is the focus of the TOVE (Toronto Virtual Enterprise) project (Fox et al., 1993; Grüninger and Fox, 1994). Ontologies define concepts used for enterprise modelling as object classes while micro-theories contain a necessary and sufficient set of axioms to define the semantics of concepts. Ontologies and micro-theories have been developed in the TOVE project for activities and states, time, resources, cost and quality.

The modelling language used is a first-order logic language so that specifications can be implemented using Prolog or similar logic programming languages. The advantage is that the enterprise model can be dynamically queried in various ways and new facts can be derived from its current extension.

According to this review, none of the modelling languages discussed covers all the requirements imposed by enterprise modelling. Most of them remain descriptive languages using a graphical notation. Many use a process-based approach but only describe business processes as a procedural chain of transformation activities, ignoring event-driven situations. Few of them are based on a formal syntax and semantics. Only a few explicitly include the time dimension. Very few deal with concurrent or communicating processes. Most of all concentrate on some enterprise modelling views (usually functional and information views), ignoring others and forcing the development of enterprise architectures based on several models, thus resulting in inconsistent and even redundant enterprise models.

More research efforts should be devoted to the development of a unified language for enterprise modelling, i.e. a language embracing all the various modelling views recommended by standardisation bodies for enterprise modelling reference architectures and able to represent the core model of an enterprise being developed in the deployment of an enterprise engineering methodology. This unified language must be supported by a graphical formalism for user-oriented representation and precise syntax and semantics for computer-based processing. Its definition should be elaborated on the basis on a commonly accepted enterprise ontology for enterprise modelling (which is still to be defined) to make enterprise model interoperability a reality among different enterprise engineering tools.