01 Enterprise Models For Enterprise Architecture

Annual Reviews in Control 27 (2003) 211–220

Enterprise models for enterprise architecture and ISO9000:2000 Peter Bernus School of Computing and Information Technology, Griffith University, Nathan, Qld 4111, Australia Received 1 August 2003; received in revised form 23 August 2003; accepted 9 September 2003

Abstract Due to the ISO9001:2000 requirement for modelling business processes and the need to share business process models in Enterprise Networks, many enterprises will be looking at sharing and reusing existing enterprise models. This article identifies measures to ensure that enterprise models are interpreted as intended, thereby controlling the quality of processes using and reusing enterprise models. A pragmatic definition of model completeness is given, based on situated interpretation of meaning and theory of communication. New requirements for Enterprise Modelling Tools are also discussed. © 2003 Published by Elsevier Ltd. Keywords: Enterprise modelling; Process modelling; Enterprise architecture; Enterprise integration; Theory of meaning

1. Introduction 1.1. Enterprise modelling for ISO9000:2000 and for creating Virtual Enterprises Enterprise architecture (EA) promotes the belief that an enterprise, as a complex system, can be designed or improved in an orderly fashion achieving better overall results than ad-hoc organisation and design. EA is a co-operative effort of designers, analysts and managers and uses enterprise models in the process. There are two important trends in enterprise architecture today that make the treatment of the meaning and sharing enterprise models timely. 1. Modelling of business processes has become a requirement for implementors of ISO9000:2000 quality management recommendations. Industry experience with previous quality certification efforts show (Kalpic & Bernus, 2002) that without an understanding of how enterprise models can be used to document business processes to the satisfaction of quality standards, and of the way the meaning of these models is shared among stakeholders, enterprise modelling may or may not deliver the required benefits (Kalpic, Bernus, & Mühlberger, 2004). The documentation of business processes for quality certification purposes, as prepared in the past, can easily fall E-mail address: [email protected] (P. Bernus). 1367-5788/$ – see front matter © 2003 Published by Elsevier Ltd. doi:10.1016/j.arcontrol.2003.09.004

short of the spirit of the quality requirements, because the documents have not been prepared on the level of completeness and consistency needed for their multiple uses. In other words, the existence of a Quality Manual does not necessarily mean that business processes will be carried out in the way the authors of the manual intended, because the documents may be interpreted in many ways by stakeholders who share the descriptions of the process. 2. The recent trend to improve the agility of enterprises by the formation of Enterprise Networks, and through it to make participants prepared to create demand-driven Virtual Enterprises (Virtual Organisations), mandates that partners in a Network should share the understanding of business processes in which they will take part. Sharing and uniform understanding of business process models has its difficulties within the walls of one company (see above). However, the potential for failure to successfully communicate (and potentially not even realise this failure) is much greater in the situation where business process models are shared and used by a geographically and culturally diverse community. The two trends are interconnected, because for companies to be able to participate in Enterprise Networks a certain level of maturity is necessary, and the implementation of a quality management systems is part of this. Enterprise modelling (EM) uses modelling languages, methods and tools chosen according to the life cycle phase (or life cycle activity) of the enterprise. For example, differ-

212

P. Bernus / Annual Reviews in Control 27 (2003) 211–220

ent modelling languages are used for requirements specification, architectural design, detailed design and implementation. These models are created and used by people with diverse technical and management roles, disciplinary background, expertise and experiences, etc.—which also influences the choice of modelling languages. (Note that the term ‘life cycle phase’ refers to a type of activity (such as user and systems requirements specification, architectural design, detailed design, etc.) and as such is not a temporal concept. The time dimension is separate—called ‘life history’ (ISO15704:2000)—and may be subdivided into ‘stages’.) The life cycle of an enterprise entity (EE) can be represented in ‘Enterprise Reference Architectures’ or ‘Architecture Frameworks’ (IFIP-IFAC Task Force, 1999). Several Architecture Frameworks exist today and they all have a Modelling Framework organising EMs that may have to be created during the life of an EE. Some examples of Architecture Frameworks with a Modelling Framework are: CIMOSA, GRAI-GIM, PERA, Zachman, ARIS, C4ISR/DoDAF and the generalisation of these, GERAM (IFIP-IFAC Task Force, 1999, 2003; Annex A, ISO15704:2000). For a comparison of these see (Noran, 2003). The GERA Modelling Framework of GERAM demonstrates the scope of enterprise modelling—what can and may have to be modelled by practitioners of enterprise architecture. EMs may be used for a variety of purposes: • To (re)design production, management and control processes, including their interactions (through events and information and material flow), and to design how processes use automated (manufacturing and IT) resources as well as human resources (i.e. to design the organisation); • To achieve common understanding and agreement between stakeholders (management, workers, owners, partners, etc.) about a number of aspects of the enterprise; • To control the processes based on the model (e.g. using Workflow Management Systems or Model-Based Process Control). 1.2. The structure of this article Section 2 presents arguments why new criteria need to be developed for being able to develop shareable enterprise models. Section 3 investigates the meaning of enterprise models. The analysis reveals that enterprise models are first of all a means of communication between people to ensure a common understanding of the present or planned enterprise. Only some EMs are used to directly control business processes, and even that executable part is made possible only because of the first essential function: mediating common understanding between those who design, engineer and operate the enterprise. From the same analysis a completeness criterion is derived, applicable to enterprise models. Section 4 draws the consequences for enterprise architecture practices, presents limitations of reuse, and suggests ways to

ensure successful model sharing and reuse. Section 5 deals with the implications for Enterprise Modelling Tools and environments (e.g. CASE tools).

2. Sharing and understanding EMs 2.1. Need to reuse models Although the returns from designing and implementing high quality enterprise models can be significant, model building from scratch may be unacceptably expensive for a large part of industry (especially small and medium enterprises), therefore there is a need to share and reuse models produced by others. Apart from the time and cost involved in producing EMs there is a need to use proven models rather then developing them through a costly learning process. There are two types of reusable models (also called ‘reference models’) in use today: generic models (with details to be filled in or parametrised by the user) and paradigmatic models (capturing a typical, particular case that must be modified to suit the new situation). Many enterprises will find themselves in search of reusable reference models: due to the new ISO9000:2000 requirement of modelling their processes, the need to follow industry best practice or the desire to achieve a higher level of process maturity. 2.2. Sharing models Given the need for reuse it is important to investigate the conditions that allow enterprise models to be shared with confidence. 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 models are correctly interpreted in a new context? Furthermore, enterprise models not only are the basis for the improvement of a single enterprise, they are necessary for partners in a supply chain to agree on interoperable business processes. The same is true of enterprises that want to develop a preparedness to participate in Enterprise Networks and Virtual Enterprises. 2.3. Completeness and consistency of enterprise models Those enterprises who acquire models for reuse would like to have guarantees that the models contain the information necessary for 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 a complete formal specification, like that of a computer algorithm. What then, is a useful definition of completeness and how can it be achieved? Electronic business (EDI—Electronic Data Interchange, Rosettanet, etc.) has been using shared models of busi-

P. Bernus / Annual Reviews in Control 27 (2003) 211–220

1. The range of phenomena addressed by enterprise modelling stretches multiple disciplines. Several modelling languages and practices are used, and one cannot always find a single person/profession that can guarantee the consistency of all models involved. 2. Models play various roles in the life cycle of the enterprise, and only some of them are machine-executable: most models need to be interpreted by humans (even some of those that are intended for machine interpretation, because humans must validate and verify these models). Models also tend to be large, hard to maintain, complex to analyse, and even worse (Nemes & Bernus, 1984)—from the often occuring formal incompleteness of enterprise models it follows that there is not always a formal way to decide whether the model is only incomplete or it is inconsistent. Thus to guarantee consistency (and completeness as it will later be defined), users need organisational measures (special functions built into the processes of enterprise engineering and operation to establish model consistency), or institutional guarantees (use of already commonly understood standard models).

3. Where is the meaning in an enterprise model? The meaning of a model can be defined in more then one legitimate way, thus confusion may arise when one talks about the meaning of a model. Three important meanings are investigated: the model theoretic, the denotational, and the situated meaning. It will be obvious to the reader that all of these contribute to the perception of what a model means, thus these theories of meaning are complementing one another. 3.1. Model theoretic meaning: an illustration In model theory meaning is a mathematical structure representing an interplay of syntax and semantics. This subsection gives an illustration of model theory (skipping some technical details with reference to the literature (Lloyd, 1984)). Fig. 1 presents an extended Entity Relationship

name (0,n)

part design

commits to

supplier

stipulates (1,1) (1,1)

promises to fulfill

ness processes—all of these being machine executable models—and it all seemingly stands to reason that the formal models of these processes completely define the involved interactions, therefore will be uniformly understood by all involved parties. However, for this uniform understanding to take place there are conditions. In fact the correct application of these standards involves a learning process during which more meaning seems to be acquired by stakeholders then expressed in the formal models themselves. The main purpose of this article is to give a practically applicable criterion for the completeness of enterprise models. To develop such a criterion, two important features of EMs need to be understood:

213

(1,1)

delivery contract

(0,n)

drawing-number quantity delivery-time

contract-number

(0,n)

part specification

specification-code

Fig. 1. Entity-relationship schema describing a sample universe of discourse.

(ER) schema typically used when enterprise data have to be modelled. Fig. 1 intends to say that (in the given universe of discourse, i.e. for the purposes of the data that need to be represented): “A part specification has a unique specification code, a supplier has a unique name and a part design has a unique drawing number. A delivery contract has a unique contract number, and it also specifies a quantity and a delivery time. A delivery contract promises to fulfil exactly one part specification and stipulates the use of exactly one part design. Furthermore, a delivery contract refers to exactly one supplier that is committed to satisfy the conditions of this contract.” The ER schema is expressed in a formal graphical language. To emphasize this point it is possible to translate what the ER schema says into a list of logical propositions (see Fig. 2b). However, for this set of propositions to make sense the meaning of the predicates ‘entity, relation, attribute and key’ used in Fig. 2b need to be defined. This can be achieved by defining the meaning of these predicates as shown in Fig. 2a. A complete definition of all enterprise modelling views—function (activity and behaviour), information, resource and organisation—in this way defines all enterprise modelling concepts, and can be called and Enterprise Ontology. Thus Fig. 2a defines the meaning of the Entity Relationship data model as a modelling language. (Note: Fig. 2a is a radically simplified version of such a translation and is presented only for illustration purposes.) For process modelling such ontology (PIF, or Process Interchange Format) has been defined (Lee et al., 1998) and recently merged with the PSL ontology. While PSL, the Process Specification Language (ISO18629:2000) includes a core ontology (ISO18629-11:2002) it is being continuously extended to cover a range of enterprise modelling needs. If such a formal representation is implemented as a database (as in Fig. 2), and the database stores both the

214

P. Bernus / Annual Reviews in Control 27 (2003) 211–220

Fig. 2. Translation of an ER schema into logical propositions and rules.

Formal software specifications have the same nature: the meaning of the specification is not altered if the names of symbols used in the specifications are changed. Such a ‘model’ is deemed complete, in the sense that no ambiguous interpretation is possible provided the formal specification

n (0,n)

p1

c2

s1

(0,n)

s3

d1

(1,1) q

(1,1) d2 (1,1)

d2

c1 p3

schema and true facts about individual entities (suppliers, part designs, etc.), then queries to this database should return answers that correspond to reality. In other words, the database is in fact like a theory that describes reality, and this theory has the predictive power to tell what would be the outcome of any question if tested on reality instead of testing it on the database! However, since Fig. 3 represents the same ER schema, it represents the same databases as well. This means that the theories embodied in the two diagrams have the same predictive power and they model reality to the same depth. The fact that entity and relationship types have meaningful names in Fig. 1 (as opposed to Fig. 3) does not influence the behaviour of the database derived from it. In the model theory of logic it is customary to define the meaning of a theory (i.e., here the meaning of the ER schema) as the simplest model of that theory. It follows that the first ER diagram does not actually capture more of reality than the second. This is because the structure and interpretation of both are the same. Even though in Fig. 1 ‘part specification’ intuitively refers to a part specification, the database cannot tell anything more about the nature of a part specification than an (identical) database derived from Fig. 3! It also follows, that all systems described by Fig. 1 are equally described by Fig. 3 provided that the mapping of symbols (‘tokens of the theory’) to reality is done in the intended way.

(0,n)

p2

s2

Fig. 3. Entity-relationship schema “equivalent” to that of Fig. 1.

P. Bernus / Annual Reviews in Control 27 (2003) 211–220

language is chosen with care and a correct token-mapping is available. It is ‘only’ to be ensured that the models so attributed to the specification (with suitable 1:1 mapping of language tokens to real world entities and relationships) is the same as the real word models. If one compares the use of the ‘models’ in Figs. 1 and 3, it is obvious that some other type of meaning should also be attached to our enterprise models to ensure the intended mapping of tokens. Note here that one of the reasons why meaningful names are needed is because users want guarantees that their universe of discourse (i.e. the relevant part of reality) is a model of the theory embodied in the ‘model’ (here the ER schema): without the agreed mapping of tokens there can be many unintended interpretations. 3.2. Denotational meaning As illustrated in Fig. 1, terms of a model refer to denotations which are concrete or mental entities or relationships. Symbols of a language have denotations through language conventions and therefore the denotations are common to a given language community. In the case of enterprise models, this community should be that of a profession in which the enterprise does business. Encyclopaedias, dictionaries, technical textbooks offer descriptions of many standard meanings. However, there are two ambiguities that spoil the simple denotational theory of meaning. First: denotations are often context dependent, thus a useful theory of meaning must take into account the contextual elements. Second: denotations are common to a language community rather then a language alone; the looser the connections in that community the less one can trust the denotational meaning. It is unfortunate that the community of persons who interact with enterprise models do not form a single language community, so enterprise architecture processes need built-in assurances to filter out the consequences due to false interpretations which arise from incorrect denotations. For example, the iterative procedure of the author–reviewer cycle of IDEF-0 is interspersed with figures for ‘demonstration only’ to establish this common interpretation of terminal symbols (Marca & McGowan, 1988). These ‘demonstrations only’ are intended as the bridge between language communities. Demonstrations can be pictures, drawings, movie frames, or even other models. The reader might conclude that the model theoretic meaning together with the denotational meaning of EMs sufficiently explains the nature of meaning communicated through EMs. By the combination of the two above theories of meaning many model theoretically possible models can be excluded from being possible interpretations. Users are not very interested in which other models may exist for the same theory if the symbols in the diagram were grounded in an unintended way. When using EMs users implicitly assume that this mapping back to reality of meaningful

215

symbols remains as intended. As the next subsection shows even less detail is tolerable without jeopardising uniform interpretation. 3.3. Situated meaning 3.3.1. Efficiency and completeness Seemingly, to create an all encompassing model of an enterprise is a daunting job, not only because of the complexity of the task, but more importantly, because the ever changing ‘organic’ nature of business makes the enterprise a moving target for the modeller. Any modelling tasks that is to be done in a particular enterprise integration project must be done in a short period of time. It is thus imperative to develop enterprise models in a manner that is as efficient as possible. To achieve this efficiency it is necessary to define what is the necessary level of completeness for enterprise models, because this criterion has major influence on efficiency. Furthermore, enterprise modelling is not practical if the size of models to be encountered by any one person is beyond the capacity (time, prerequisite knowledge, tool support, etc.) of the individual. Efficiency and completeness are defined here in the context of the use of these models: Definition 1 (Efficiency of enterprise models). An enterprise model is efficient if it conveys the intended meaning concisely between the parties producing or using the model. (Note the use of the word ‘conveys’ instead of ‘contains’.) Definition 2 (Completeness of enterprise models). An enterprise model is complete relative to a process using it if the resources performing the process can create (and behave according to) the intended interpretation of the model for the use of this process. Three important consequences of these definitions: • If there is no process that uses a model, there is no need for that model. For example, the quest for an integrated corporate database schema of the 1980s (Smith, 1981) was over-ambitious because there was no real need for the complete schema. Only those parts of database schemata (the federated schemata) were really necessary that integrated the data needed by some meaningful business process. These are usually processes involved in data exchange between business domains (Sheth & Larson, 1990). • It is not absolutely necessary that the EM be a true model (or even a theory) at all! The only requirement is that the EM should constrain its user in such a way that only the intended interpretation is created by the user. This point is explained in detail in Section 3.3.2. • Notice, that a complete interpretation of the model does not necessarily have to be made by any one user. The only pragmatic requirement is that when a ‘model’ is used

216

P. Bernus / Annual Reviews in Control 27 (2003) 211–220

the user should be able to create that part of the intended interpretation which is pragmatically useful for the user’s actions (processes). It is thus apparent that enterprise models need to maintain the efficiency of natural language (including written and spoken word, figures, etc.), while adding accuracy and formality. Efficiency is a key factor. How is this possible? Semantic theories of natural language (Barwise, 1988; Barwise & Perry, 1983) can be used to define a third meaning of enterprise models and to explain efficiency. 3.3.2. Situated theory of meaning Below is a short exposition of the situated theory of meaning, or ‘situation semantics’ for short. Situation semantics analyses meaning in the context of language use, such as a conversation or a co-operative action which involves language use. 3.3.2.1. Utterances and described situations. Participants of a conversation pass on pieces of information to other participants in form of spoken or written word, drawings, or other accepted modality of communication. Any such piece of information is called an ‘utterance’. Utterances are produced with the intention to add to, or modify, the recipient’s model of a topic (the ‘described situation’). Interpretation is the process by which the recipient uses the utterance to build or modify its own model of the described situation. Since normally the recipient already has an extensive set of models available about a range of situations (past experience, common models of a domain of expertise), the recipient might need only a small set of utterances to build (using already available models or elements thereof) the intended model of the described situation. At least the set of utterances can be small compared to the model to be built. 3.3.2.2. Utterance situation. Any utterance is uttered in an ‘utterance situation’, which includes the speaker, the listener, some agreement about the goal of the conversation, and possibly other circumstantial elements. This utterance situation is either directly perceived by the participants or is of some standard form (e.g. the producer of utterances can anticipate the situation in which the recipient will interpret the utterances). Note that the same utterance may be interpreted in very different ways if the utterance situation changes. 3.3.2.3. Meaning as a relation. The situated meaning of an utterance is the relationship that the utterance establishes between the utterance situation and the described situation. This relationship enables the recipient to restrict the set of possible described situations and thus helps build the internal model of the described situation. The conversation is successful if the recipient is able to re-create the intended interpretation.

It follows that there are three components (and the elements thereof) which can be controlled for the act of communication to succeed: • Utterances, • Utterance situation, and • Described situation. 3.3.3. Situated meaning of enterprise models An enterprise model will be thought of as a set of utterances intended to convey in a precise and efficient manner some information about the enterprise. The goal of enterprise modelling is to achieve a target situation (some new, improved state of the enterprise). This target situation is the described situation of EMs. EMs are interpreted in ‘enterprise architecting situations’ (which are the utterance situations in terms of situation semantics). This includes experts, with knowledge of reference materials (previous knowledge of paradigmatic cases, standard models, experience), and the methodology which is followed in the process of enterprise architecture. Without this situated knowledge EMs can be misinterpreted, as described by (Hysom, 2003)—e.g. a model describing a single user’s subjective perception of how things are in a given business process may be interpreted as an objective model of the current process, and consequently acted upon in an unintended way. When modelling-experts produce an enterprise model and communicate it to some recipient group, the intention of this communication is already fixed, the participants are known, and the supposed prerequisite knowledge of the participants may also be defined. All of the above elements form part of the utterance situation in which the EM is to be interpreted. EMs, as a collection of utterances, thus contain information only inasmuch as they constrain the user sufficiently so that the intended interpretation is created, and no unintended interpretation occurs. Interestingly therefore enterprise models do not necessarily contain all the information that they are usually supposed to carry! Definition 3. The situated meaning of enterprise models is the relationship between the situation in which the EM is communicated and the situation about which the EM is stating something. This pragmatic treatment of meaning allows for an increased efficiency in EM communication, and may be implemented as a new way of using enterprise models, provided one can have good control over the elements of the ‘utterance situations’ and over the initial state of the ‘described situations’. The same treatment also allows for completeness to be defined relative to the process using EMs rather then defining completeness as an intrinsic property of EMs. Definition 2 introduced completeness as a pragmatic property of enterprise models. It is now clear that this pragmatic completeness coincides with the EM unambiguously

P. Bernus / Annual Reviews in Control 27 (2003) 211–220

and sufficiently carrying its situated meanings. In contrast with Definition 2, an absolute measure of completeness is the extent to which enterprise models are theories (in the sense of model theory)—together with some denotational assignment—as opposed to being utterances allowing the recipient to create these theories. One would think that if an EM is complete in the absolute sense then it is also complete in the relativistic sense. However, this is not so: the recipient of the model may not possess the requisite abilities, or tools to correctly interpret a model which may be judged complete in the absolute sense by an omniscient external observer.

4. Limitations and possibilities of reuse 4.1. Possibilities of reuse Clearly the important condition of successful model reuse is that models be pragmatically complete (Definition 2). Fig. 4 shows at a glance the factors which together form the enterprise engineering situation. The ‘described situation’ here is the interpretation of EMs as perceived by stakeholders. For an EM to be (re)usable as intended, it is thus necessary to specify what is assumed about the use of the model in terms of all these factors (as listed in Fig. 4). These factors of successful reuse are to be reproduced in the ‘reusing’ process:

217

• Qualities of the ‘enterprise architects’ (skills, knowledge, as listed in Fig. 4); • Reference to the type of enterprise architecting situation in which the EM is to be used (e.g. by use of an enterprise Architecture Framework that stakeholders understand); • Ability to explicitly view the current model of the enterprise engineering process (what the process is and where stakeholder activities fit into the process), including the capture of design history and future plan; • Quick access to a wide range of encyclopaedic reference material which may have been used in the production of the EM (the use of multiple modalities is important to connect the conceptual and the visual aspects); • Links in the design database between the partial and particular models and the enterprise engineering process. The complexity of the enterprise architecting process (and the models produced in it) can be significantly reduced by standardising on some components, such as the utilised Enterprise Reference Architecture/Architecture Framework, modelling languages (with well defined ontology), and commonly used reference models. An Enterprise Reference Architecture/Architecture Framework it itself a model of the architecting process encompassing all activities during the life of the enterprise. They are usually accompanied by a methodology (or methodologies) that detail these activities as well as propose modelling tools and modelling languages to be used by the architecting process. 4.2. Limitations of reuse

Used enterprise architecture framework Common Reference Models

Particular EMs Encyclopaedic reference material (multi-modal) EM Tools incl. simulation capability

Model of the particular enterprise architecture process Interpretation of particular EMs Enterprise architecting activity using EMs Actions and communication based on the interpretation

Enterprise architects with role and motivation experience with given type of enterprise knowledge of architecture framework knowledge of modelling languages education in given discipline in-house (local) knowledge Fig. 4. Factors affecting the pragmatic interpretation of enterprise models of EMs as perceived by stakeholders (called ‘enterprise architects’ in the figure).

The lack of the same factors which enable the intended interpretation to take place can limit the possibility of reuse. To prevent problems it is necessary to review the prerequisites of successful interpretation at the planning stage of any enterprise architecture process that uses EMs. A typical example is the documentation of business processes in a Quality Manual as prepared by many companies when they aspire to obtain quality accreditation. Are these descriptions pragmatically complete models of business processes? Usually they are not. This is because quality accreditation is aimed at an audience (models are created according to the needs of this situation) which does not necessarily include all stakeholders that would need these models. For example, models can be used for analysis to improve business processes, analysis of the impacts of the change before it is introduced, management of the enterprise’s knowledge resources (share, improve and preserve them), training of new employees, etc. In certain circumstances it may not be the enterprise model that needs to be further detailed, rather it is employees who need training so that they can correctly interpret and use the existing models. The lack of adherence to an Enterprise Reference Architecture can have a negative effect on the success of reuse.

218

P. Bernus / Annual Reviews in Control 27 (2003) 211–220

When models are produced they tend to be precise with respect to the intended use and ignore details not necessary for that use. Failure to understand the original intended usage is a misuse of EMs and is a cause of misinterpretation. The lack of prompt access to adequate reference material (available particular models, reference models, encyclopaedic references, etc.). Both the availability and the promptness of access are important; since failure to use the reference when it would be needed introduces an undue backtracking point to the design process (this is a point where progress is only possible if assumptions are made). People might use the model with implicit assumptions and later, when assumptions prove to be false, incorrect interpretations need to be unlearnt. Enterprise Modelling Tools (EMTs) can alleviate denotational and some of the situational misinterpretations, and if the EMT includes simulation capability this can help investigate the implicit properties of (executable) specifications. Below a set of desirable EMT functions is outlined for helping participants of the enterprise architecting process to be in the situation where correct interpretation is possible.

5. Implications for Enterprise Modelling Tools Every engineering area produces a number of models to support the design process. Architects and civil engineers represent buildings, roads and bridges using a series of interrelated two or three dimensional graphical models, each model serving a particular task (activity) in the design process. Electrical and electronic engineers represent their artefacts using a list of models, ranging from block diagrams, through dc and dynamic models, to calculate the flow of electronic signals and of heat in their constructions, two and three dimensional models are created for the design of the electro-mechanical structure of circuits and to design the mechanical and chemical processes of manufacturing. Chemical engineering uses block diagrams to represent the processes of a chemical factory, and engineering companies who build the equipment and piping use models common in mechanical engineering. Software engineers use a series of models to capture the functional requirements, and the information flow within the software, and other diagrams to represent the software artefacts that implement the required functions. Control engineers use theoretical equations (models) to calculate the static and dynamic behaviour of the control system, and various models to demonstrate that the chosen implementation technology will indeed deliver the desired control function. Enterprise Architects use functional (activity and behaviour) and information models to specify business processes and their interactions and resource and organisational models to represent the implementation, as well as models to directly control some of the processes. All of these areas have respective design/modelling tools. However, when a model of an artefact or enterprise is developed it is hard to maintain the relationship between these

models, whether they are models used for the same life cycle phase or not. 5.1. Model interoperability When a model is developed using one selected language users often need to communicate these to someone who uses a different tool supporting a slightly different modelling language for the same purpose, i.e. to represent the same view of the enterprise. The task of model exchange/translation (interoperability) is often near impossible, or requires intensive human intervention and ad-hoc decisions. The reason for the lack of tool interoperability is mainly the lack of an agreed formal ontological theory that tool vendors could use for model translation for import or export. While for basic process modelling a standard ontology (PSL-Core) exist (ISO18629-11:2002), with currently 50 extensions, the scope of this formal definition is process modelling, and such formal ontology for the entire scope of enterprise modelling (for all life cycle phases and all modelling views) is still under development. Also, tool vendors need to make an effort to implement translators for their supported languages to make use of this standard ontology. Given that the formal definition of many currently used modelling languages is still not available, tool interoperability remains a future requirement, and tool vendor contribution to the PSL ontology extensions could speed up this process. 5.2. Mutually constraining models An even harder problem is the maintenance of relationships between models that belong to consecutive life cycle phases. While these models are mutually constrained (e.g. a change in the requirements specification mandates some change in the architectural design and vice-versa), there is no 1:1 relationship between the two models, reflecting the fact that design decisions are needed to turn a specification into a design. However, this does not mean that modelling tools should not be able to maintain a relationship, at least to the level of constraint checking and constraint propagation (Hughes, 1998). 5.3. Representation of design process and design history The design process is an iterative activity that includes down-stream and up-stream processes. It is hard to understand models in isolation, unless the links to other models are understood, and unless the design process itself is understood by all participants in the same way. The Intelligent CAD community has long argued (Tomiyama et al., 1992) that design tools must have a model of the design process itself so as to adequately support the design activity. Consequently (1) the design process must be represented as a process that interconnects life cycle activities of the artefact; and (2) the life history of the actual instance of this process needs also be represented, so that models can be inter-

P. Bernus / Annual Reviews in Control 27 (2003) 211–220

preted as results of a series of actual decisions in the design situation (cf. utterance situation in Section 3.3.2)—such as reflected in experimental systems that capture Design Rationale (Myers, Zumel, & Garcia, 2000; Ramesh & Dhar, 1992). 5.4. Support for uniformly understood communication and learning Traditional modelling tools offer functionality to help the designer create a model using a fixed set of modelling languages. They do not help other stakeholders to understand these models. What is usually offered by today’s tools is merely the ability to export the contents of models as web pages. Below is a shortlist of requirements that EMTs need to satisfy for successful communication using enterprise models. (Only those requirements are listed here which are not usually part of a state-of-the-art tool.) • Offer links to reference material and cross references to other EMs (the requirement of grounding). • Be permissive: allow multiple modelling languages to be used and offer translation between them (this is the same interoperability requirement that was discussed above, but translation into representations familiar to the reader of the model needs a more flexible function then mere model import–export—e.g. cross references to other models should also be translated). • If translation between models is not possible the user of the EMT is still to be provided with a common reference. For example, imagine that the tool stores a dynamic model of a part of an artefact and a two dimensional model of a working surface of the same artefact. The two models can practically not be related in terms of translation of their contents or even through constraints—the only relationship in this case is that they are about the same physical entity. However, the tool should allow the linking of these models to some common reference, such as by reference to a three dimensional picture of the artefact making it clear to the user that the two models are models of the same object. • Make the enterprise architecting process itself explicit and up-to-date (through reference models and the model of the particular process). This is the same requirement as the one above for design process and history representation, but apart from this representation the EMT should support all meaningful manipulation and analysis of these as well (e.g. “what if the same process is repeated but with different parameters?”). • EMs are to be communicated between people and mutual understanding is to be an observable occasion in this process (support negotiation, discussion, learning, and in general, co-operative group work). Regarding theoretical foundations model presentation should be based on a sound understanding of how people acquire and share knowledge. Technologically, multi-modal interfaces are

219

needed, where formal models (expressed in text or graphics) are mixed with visual representations (an approach well known in certain areas, such as in tools for architects, but not used in Enterprise Modelling Tools). Theories of conversation (Dorval, 1990; Pask, 1975) demonstrate that to achieve mutual understanding the participants need to have an agreement on what constitutes the present design situation, and have access to the same common references for denotational (e.g. experimental) purposes. Therefore it is necessary to allow access to visual, not only conceptual, representations from the same workbench, since design processes need both aspects of reality.

6. Conclusion Reasons of incompleteness of enterprise models were analysed and a definition of pragmatic completeness was given which can, and should, be achieved in enterprise modelling. It was demonstrated how enterprise models carry meaning. This resulted in requirements for the enterprise engineering process, which—if not met—can limit the viability of the process. The analysis of the same factors resulted in requirements for improved Enterprise Modelling Tools.

References Barwise, J. (1988). The situation in logic. Stanford, USA: CSLI. Barwise, J., & Perry, J. (1983). Situations and attitudes. Cambridge, MA: MIT Press. Dorval, B. (Ed.). (1990). Conversational organization and its development. Norwood, NJ: Ablex. Hughes, Sh. (1998). Achieving interoperability among Enterprise Modelling Tools. School of Computing and Information Technology Honours Dissertation. Nathan, Brisbane: Griffith University. Hysom, R. (2003). Enterprise modelling—The readiness of the organisation. In P. Bernus, L. Nemes, & G. Schmidt (Eds.), Handbook on enterprise architecture (pp. 373–416). Berlin: Springer. IFIP-IFAC Task Force. (1999). The generalised enterprise reference architecture and methodology (GERAM), v1.6.3. http://www.cit.gu.edu.au/∼bernus. IFIP-IFAC Task Force. (2003). The generalised enterprise reference architecture and methodology (GERAM). In P. Bernus, L. Nemes, & G. Schmidt (Eds.), Handbook on enterprise architecture (pp. 22–64). Berlin: Springer. ISO15704:2000. (2000). Requirements for generalised enterprise reference architectures and methodologies. ISO TC184/SC5/WG1. ISO18629:2000. (2000). Industrial systems and automation—Process Specification Language. JWG8 ISO TC184/SC4-SC5. ISO18629-11:2002. (2002). Industrial systems and automation—Process Specification Language—PSL-Core. JWG8 ISO TC184/SC4-SC5. ISO9000:2000. (2000). Quality management systems—Fundamentals and vocabulary. ISO/TC176/SC2. Kalpic, B., & Bernus, P. (2002). Business process modelling in industry—The powerful tool in enterprise management. International Journal of Computers in Industry, (3) 299–318. Kalpic, B, Bernus, P, & Mühlberger, R. (2004). Business process modelling and its applications in the business environment. In C. T. Leondes (Ed.), Business and technology of the new millennium. Norwell: Kluwer (to appear).

220

P. Bernus / Annual Reviews in Control 27 (2003) 211–220

Lee, J., Gruninger, M., Jin, Y., Malone, T., Tate, A., & Yost, G. (1998). The PIF process interchange format and framework. Knowledge Engineering Review, (2), 1–30. Lloyd, J. W. (1984). Foundations of logic programming. Berlin: Springer. Marca, D. A., & McGowan, C. L. (1988). SADT. New York: McGraw-Hills. Myers, K. L., Zumel, N. B., Garcia, P. (2000). Acquiring design rationale automatically. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 14(2), 115–135. Nemes, L., Bernus, P. (1984). An incomplete manufacturing model needs matching design tools. In Proceedings of 16th CIRP International Seminar on Manufacturing Systems (pp. 26–43), Tokyo. Noran, O. (2003). A mapping of individual architecture frameworks (GRAI, PERA, C4ISR, CIMOSA, ZACHMAN, ARIS) onto GERAM. In P. Bernus, L. Nemes, & G. Schmidt (Eds), Handbook on enterprise architecture (pp. 65–212). Berlin: Springer.

Pask, G. (1975). Conversation, cognition, and learning. Amsterdam: Elsevier. Ramesh, B., Dhar, V. (1992). Supporting systems development by capturing deliberations during requirements engineering. IEEE Transactions on Software Engineering, 18(6), 498–510. Sheth, A. P., Larson, J. A. (1990). Federated database systems for managing distributed, heterogeneous, and autonomous databases. ACM Computer Surveys, 223, 183–236. Smith, J. M. (1981). Multibase—Integrating heterogenous distributed database systems. Proceedings of AFIPS, 50(5), 487– 499. Tomiyama, T., Xue, D., Umeda, Y., Takeda, H., Kiriyama, T., & Yoshikawa, H. (1992). Systematizing design knowledge for Intelligent CAD systems. In G. Olling & F. Kimura (Eds.), Human aspects in computer integrated manufacturing (pp. 237–248). Amsterdam: North-Holland.