Doi:10.1016/j.arcontrol.2003.09.004

Annual Reviews in Control 27 (2003) 211–220 Enterprise models for enterprise architecture and ISO9000:2000 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 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 thatenterprise models are interpreted as intended, thereby controlling the quality of processes using and reusing enterprise models. A pragmaticdefinition of model completeness is given, based on situated interpretation of meaning and theory of communication. New requirements forEnterprise Modelling Tools are also discussed.
2003 Published by Elsevier Ltd.
Keywords: Enterprise modelling; Process modelling; Enterprise architecture; Enterprise integration; Theory of meaning short of the spirit of the quality requirements, becausethe documents have not been prepared on the level of 1.1. Enterprise modelling for ISO9000:2000 and for completeness and consistency needed for their multiple creating Virtual Enterprises uses. In other words, the existence of a Quality Manualdoes not necessarily mean that business processes will be Enterprise architecture (EA) promotes the belief that an carried out in the way the authors of the manual intended, enterprise, as a complex system, can be designed or im- because the documents may be interpreted in many ways proved in an orderly fashion achieving better overall results by stakeholders who share the descriptions of the process.
than ad-hoc organisation and design. EA is a co-operative 2. The recent trend to improve the agility of enterprises by effort of designers, analysts and managers and uses enter- the formation of Enterprise Networks, and through it to prise models in the process.
make participants prepared to create demand-driven Vir- There are two important trends in enterprise architecture tual Enterprises (Virtual Organisations), mandates that today that make the treatment of the meaning and sharing partners in a Network should share the understanding of enterprise models timely.
business processes in which they will take part. Sharingand uniform understanding of business process models 1. Modelling of business processes has become a require- has its difficulties within the walls of one company (see ment for implementors of man- above). However, the potential for failure to success- agement recommendations. Industry experience with fully communicate (and potentially not even realise this previous quality certification efforts show ( failure) is much greater in the situation where business that without an understanding of how process models are shared and used by a geographically enterprise models can be used to document business pro- and culturally diverse community.
cesses to the satisfaction of quality standards, and of theway the meaning of these models is shared among stake- The two trends are interconnected, because for companies holders, enterprise modelling may or may not deliver the to be able to participate in Enterprise Networks a certain required benefits level of maturity is necessary, and the implementation of a The documentation of business processes for quality cer- quality management systems is part of this.
tification purposes, as prepared in the past, can easily fall Enterprise modelling (EM) uses modelling languages, methods and tools chosen according to the life cycle phase E-mail address: [email protected] (P. Bernus).
(or life cycle activity) of the enterprise. For example, differ- 1367-5788/$ – see front matter 2003 Published by Elsevier Ltd.
doi:10.1016/j.arcontrol.2003.09.004 P. Bernus / Annual Reviews in Control 27 (2003) 211–220 ent modelling languages are used for requirements specifi- ensure successful model sharing and reuse. cation, architectural design, detailed design and implemen- with the implications for Enterprise Modelling Tools and tation. These models are created and used by people with environments (e.g. CASE tools).
diverse technical and management roles, disciplinary back-ground, expertise and experiences, etc.—which also influ-ences the choice of modelling languages. (Note that the term 2. Sharing and understanding EMs
‘life cycle phase' refers to a type of activity (such as user andsystems requirements specification, architectural design, 2.1. Need to reuse models detailed design, etc.) and as such is not a temporal con-cept. The time dimension is separate—called ‘life history' Although the returns from designing and implementing (may be subdivided into ‘stages'.) high quality enterprise models can be significant, model The life cycle of an enterprise entity (EE) can be rep- building from scratch may be unacceptably expensive for a resented in ‘Enterprise Reference Architectures' or ‘Ar- large part of industry (especially small and medium enter- chitecture Frameworks' ().
prises), therefore there is a need to share and reuse models Several Architecture Frameworks exist today and they all produced by others. Apart from the time and cost involved in have a Modelling Framework organising EMs that may producing EMs there is a need to use proven models rather have to be created during the life of an EE. Some ex- then developing them through a costly learning process.
amples of Architecture Frameworks with a Modelling There are two types of reusable models (also called ‘ref- Framework are: CIMOSA, GRAI-GIM, PERA, Zachman, erence models') in use today: generic models (with details ARIS, C4ISR/DoDAF and the generalisation of these, to be filled in or parametrised by the user) and paradig- matic models (capturing a typical, particular case that must For a comparison of these see be modified to suit the new situation).
The GERA Modelling Framework of GERAM Many enterprises will find themselves in search of demonstrates the scope of enterprise modelling—what can reusable reference models: due to the new and may have to be modelled by practitioners of enterprise requirement of modelling their processes, the need to fol- low industry best practice or the desire to achieve a higher EMs may be used for a variety of purposes: level of process maturity.
• To (re)design production, management and control pro- 2.2. Sharing models cesses, including their interactions (through events andinformation and material flow), and to design how pro- Given the need for reuse it is important to investigate the cesses use automated (manufacturing and IT) resources as conditions that allow enterprise models to be shared with well as human resources (i.e. to design the organisation); confidence. And, if they can, to what extent. Notably, what • To achieve common understanding and agreement be- is it that ensures that the information a model was intended tween stakeholders (management, workers, owners, part- to carry is not distorted in the process of reuse? Are there ners, etc.) about a number of aspects of the enterprise; any guarantees that models are correctly interpreted in a new • To control the processes based on the model (e.g. using Workflow Management Systems or Model-Based Process Furthermore, enterprise models not only are the basis for the improvement of a single enterprise, they are necessaryfor partners in a supply chain to agree on interoperable busi- 1.2. The structure of this article ness processes. The same is true of enterprises that want todevelop a preparedness to participate in Enterprise Networks arguments why new criteria need to and Virtual Enterprises.
be developed for being able to develop shareable enterprisemodels. investigates the meaning of enterprise 2.3. Completeness and consistency of enterprise models models. The analysis reveals that enterprise models are firstof all a means of communication between people to ensure Those enterprises who acquire models for reuse would a common understanding of the present or planned enter- like to have guarantees that the models contain the infor- prise. Only some EMs are used to directly control business mation necessary for successful reuse. This need is in stark processes, and even that executable part is made possible contrast with reality: it is known to practitioners that EMs only because of the first essential function: mediating com- are almost never complete in the sense of a complete for- mon understanding between those who design, engineer and mal specification, like that of a computer algorithm. What operate the enterprise. From the same analysis a complete- then, is a useful definition of completeness and how can it ness criterion is derived, applicable to enterprise models.
ws the consequences for enterprise architecture Electronic business (EDI—Electronic Data Interchange, practices, presents limitations of reuse, and suggests ways to Rosettanet, etc.) has been using shared models of busi- P. Bernus / Annual Reviews in Control 27 (2003) 211–220 ness processes—all of these being machine executable models—and it all seemingly stands to reason that the formalmodels of these processes completely define the involved interactions, therefore will be uniformly understood by all involved parties. However, for this uniform understandingto take place there are conditions. In fact the correct appli- cation of these standards involves a learning process during commits to
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 mod- els. To develop such a criterion, two important features of EMs need to be understood: 1. The range of phenomena addressed by enterprise mod- elling stretches multiple disciplines. Several modelling promises to (0,n)
languages and practices are used, and one cannot alwaysfind a single person/profession that can guarantee the Fig. 1. Entity-relationship schema describing a sample universe of dis- consistency of all models involved.
2. Models play various roles in the life cycle of the enter- prise, and only some of them are machine-executable: (ER) schema typically used when enterprise data have to most models need to be interpreted by humans (even be modelled.
some of those that are intended for machine interpre- to say that (in the given universe of dis- tation, because humans must validate and verify these course, i.e. for the purposes of the data that need to be rep- resented): "A part specification has a unique specification Models also tend to be large, hard to maintain, complex code, a supplier has a unique name and a part design has to analyse, and even worse ( a unique drawing number. A delivery contract has a unique the often occuring formal incompleteness of enterprise mod- contract number, and it also specifies a quantity and a deliv- els it follows that there is not always a formal way to decide ery time. A delivery contract promises to fulfil exactly one whether the model is only incomplete or it is inconsistent.
part specification and stipulates the use of exactly one part Thus to guarantee consistency (and completeness as it will design. Furthermore, a delivery contract refers to exactly later be defined), users need organisational measures (spe- one supplier that is committed to satisfy the conditions of cial functions built into the processes of enterprise engineer- ing and operation to establish model consistency), or insti- The ER schema is expressed in a formal graphical lan- tutional guarantees (use of already commonly understood guage. To emphasize this point it is possible to translate standard models).
what the ER schema says into a list of logical propositions
(see However, for this set of propositions to make
sense the meaning of the predicates ‘entity, relation, at-
3. Where is the meaning in an enterprise model?
tribute and key' used in to be defined. This
can be achieved by defining the meaning of these predicates
The meaning of a model can be defined in more then one as shown in A complete definition of all enterprise legitimate way, thus confusion may arise when one talks modelling views—function (activity and behaviour), infor- about the meaning of a model.
mation, resource and organisation—in this way defines all Three important meanings are investigated: the model the- enterprise modelling concepts, and can be called and Enter- oretic, the denotational, and the situated meaning.
prise Ontology. Thus the meaning of the En- It will be obvious to the reader that all of these contribute tity Relationship data model as a modelling language. (Note: to the perception of what a model means, thus these theories a radically simplified version of such a translation of meaning are complementing one another.
and is presented only for illustration purposes.) For processmodelling such ontology (PIF, or Process Interchange For- 3.1. Model theoretic meaning: an illustration mat) has been defined (recently mergedwith the PSL ontology. While PSL, the Process Specifica- In model theory meaning is a mathematical structure tion Language includes a core ontology representing an interplay of syntax and semantics. This sub- (it is being continuously extended to section gives an illustration of model theory (skipping some cover a range of enterprise modelling needs.
technical details with reference to the literature ( If such a formal representation is implemented as a presents an extended Entity Relationship database (as in and the database stores both the P. Bernus / Annual Reviews in Control 27 (2003) 211–220 Fig. 2. Translation of an ER schema into logical propositions and rules.
schema and true facts about individual entities (suppliers, Formal software specifications have the same nature: the part designs, etc.), then queries to this database should re- meaning of the specification is not altered if the names turn answers that correspond to reality. In other words, the of symbols used in the specifications are changed. Such a database is in fact like a theory that describes reality, and ‘model' is deemed complete, in the sense that no ambiguous this theory has the predictive power to tell what would be interpretation is possible provided the formal specification the outcome of any question if tested on reality instead oftesting it on the database! However, since the same ER schema, it represents the same databases as well. This means that the theories embodied in the two diagrams have the samepredictive power and they model reality to the same depth.
The fact that entity and relationship types have meaningful names in opposed to does not influencethe 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 followsthat 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 ‘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 It also follows, that all systems described by are equally described by vided that the mappingof symbols (‘tokens of the theory') to reality is done in theintended way.
Fig. 3. Entity-relationship schema "equivalent" to that of P. Bernus / Annual Reviews in Control 27 (2003) 211–220 language is chosen with care and a correct token-mapping symbols remains as intended. As the next subsection shows is available.
even less detail is tolerable without jeopardising uniform It is ‘only' to be ensured that the models so attributed to the specification (with suitable 1:1 mapping of languagetokens to real world entities and relationships) is the same 3.3. Situated meaning as the real word models. If one compares the use of the‘models' in t is obvious that some other type 3.3.1. Efficiency and completeness of meaning should also be attached to our enterprise mod- Seemingly, to create an all encompassing model of an els to ensure the intended mapping of tokens. Note here that enterprise is a daunting job, not only because of the com- one of the reasons why meaningful names are needed is be- plexity of the task, but more importantly, because the ever cause users want guarantees that their universe of discourse changing ‘organic' nature of business makes the enterprise (i.e. the relevant part of reality) is a model of the theory a moving target for the modeller. Any modelling tasks that embodied in the ‘model' (here the ER schema): without the is to be done in a particular enterprise integration project agreed mapping of tokens there can be many unintended in- must be done in a short period of time. It is thus imperative to develop enterprise models in a manner that is as efficientas possible. To achieve this efficiency it is necessary to de- 3.2. Denotational meaning fine what is the necessary level of completeness for enter-prise models, because this criterion has major influence on As illustrated in terms of a model refer to denota- tions which are concrete or mental entities or relationships.
Furthermore, enterprise modelling is not practical if the Symbols of a language have denotations through language size of models to be encountered by any one person is be- conventions and therefore the denotations are common to a yond the capacity (time, prerequisite knowledge, tool sup- given language community. In the case of enterprise models, port, etc.) of the individual. Efficiency and completeness are this community should be that of a profession in which the defined here in the context of the use of these models: enterprise does business. Encyclopaedias, dictionaries, tech-nical textbooks offer descriptions of many standard mean- Definition 1 (Efficiency of enterprise models). An enter-
ings. However, there are two ambiguities that spoil the sim- prise model is efficient if it conveys the intended meaning ple denotational theory of meaning.
concisely between the parties producing or using the model.
First: denotations are often context dependent, thus a use- (Note the use of the word ‘conveys' instead of ‘contains'.) ful theory of meaning must take into account the contextualelements.
Definition 2 (Completeness of enterprise models). An en-
Second: denotations are common to a language commu- terprise model is complete relative to a process using it if nity rather then a language alone; the looser the connections the resources performing the process can create (and behave in that community the less one can trust the denotational according to) the intended interpretation of the model for meaning. It is unfortunate that the community of persons the use of this process.
who interact with enterprise models do not form a singlelanguage community, so enterprise architecture processes Three important consequences of these definitions: need built-in assurances to filter out the consequences due tofalse interpretations which arise from incorrect denotations.
• If there is no process that uses a model, there is no For example, the iterative procedure of the author–reviewer need for that model. For example, the quest for an inte- cycle of IDEF-0 is interspersed with figures for ‘demon- grated corporate database schema of the 1980s stration only' to establish this common interpretation of was over-ambitious because there was no real need terminal symbols ). These for the complete schema. Only those parts of database ‘demonstrations only' are intended as the bridge between schemata (the federated schemata) were really necessary language communities. Demonstrations can be pictures, that integrated the data needed by some meaningful busi- drawings, movie frames, or even other models.
ness process. These are usually processes involved in data The reader might conclude that the model theoretic exchange between business domains ( meaning together with the denotational meaning of EMs sufficiently explains the nature of meaning communicated • It is not absolutely necessary that the EM be a true model through EMs. By the combination of the two above theories (or even a theory) at all! The only requirement is that the of meaning many model theoretically possible models can EM should constrain its user in such a way that only the be excluded from being possible interpretations. Users are intended interpretation is created by the user. This point not very interested in which other models may exist for the is explained in detail in same theory if the symbols in the diagram were grounded • Notice, that a complete interpretation of the model does in an unintended way. When using EMs users implicitly not necessarily have to be made by any one user. The assume that this mapping back to reality of meaningful only pragmatic requirement is that when a ‘model' is used P. Bernus / Annual Reviews in Control 27 (2003) 211–220 the user should be able to create that part of the intended It follows that there are three components (and the ele- interpretation which is pragmatically useful for the user's ments thereof) which can be controlled for the act of com- munication to succeed: It is thus apparent that enterprise models need to main- tain the efficiency of natural language (including written and • Utterance situation, and spoken word, figures, etc.), while adding accuracy and for- • Described situation.
mality. Efficiency is a key factor.
How is this possible? Semantic theories of natural lan- 3.3.3. Situated meaning of enterprise models guage can be used An enterprise model will be thought of as a set of utter- to define a third meaning of enterprise models and to explain ances intended to convey in a precise and efficient manner some information about the enterprise. The goal of enter-prise modelling is to achieve a target situation (some new, 3.3.2. Situated theory of meaning improved state of the enterprise). This target situation is the Below is a short exposition of the situated theory of mean- described situation of EMs.
ing, or ‘situation semantics' for short.
EMs are interpreted in ‘enterprise architecting situations' Situation semantics analyses meaning in the context of (which are the utterance situations in terms of situation se- language use, such as a conversation or a co-operative action mantics). This includes experts, with knowledge of refer- which involves language use.
ence materials (previous knowledge of paradigmatic cases,standard models, experience), and the methodology which 3.3.2.1. Utterances and described situations. is followed in the process of enterprise architecture. With- of a conversation pass on pieces of information to other par- out this situated knowledge EMs can be misinterpreted, as ticipants in form of spoken or written word, drawings, or described by (a model describing a sin- other accepted modality of communication. Any such piece gle user's subjective perception of how things are in a given of information is called an ‘utterance'. Utterances are pro- business process may be interpreted as an objective model duced with the intention to add to, or modify, the recipient's of the current process, and consequently acted upon in an model of a topic (the ‘described situation'). Interpretation is unintended way.
the process by which the recipient uses the utterance to build When modelling-experts produce an enterprise model and or modify its own model of the described situation. Since communicate it to some recipient group, the intention of this normally the recipient already has an extensive set of models communication is already fixed, the participants are known, available about a range of situations (past experience, com- and the supposed prerequisite knowledge of the participants mon models of a domain of expertise), the recipient might may also be defined. All of the above elements form part of need only a small set of utterances to build (using already the utterance situation in which the EM is to be interpreted.
available models or elements thereof) the intended model of EMs, as a collection of utterances, thus contain informa- the described situation. At least the set of utterances can be tion only inasmuch as they constrain the user sufficiently so small compared to the model to be built.
that the intended interpretation is created, and no unintendedinterpretation occurs. Interestingly therefore enterprise mod- 3.3.2.2. Utterance situation. Any utterance is uttered in els do not necessarily contain all the information that they an ‘utterance situation', which includes the speaker, the lis- are usually supposed to carry! tener, some agreement about the goal of the conversation,and possibly other circumstantial elements. This utterance Definition 3. The situated meaning of enterprise models
situation is either directly perceived by the participants or is the relationship between the situation in which the EM is of some standard form (e.g. the producer of utterances is communicated and the situation about which the EM is can anticipate the situation in which the recipient will in- stating something.
terpret the utterances). Note that the same utterance may beinterpreted in very different ways if the utterance situation This pragmatic treatment of meaning allows for an in- creased efficiency in EM communication, and may be imple-mented as a new way of using enterprise models, provided 3.3.2.3. Meaning as a relation. The situated meaning of one can have good control over the elements of the ‘utter- an utterance is the relationship that the utterance establishes ance situations' and over the initial state of the ‘described between the utterance situation and the described situation.
situations'. The same treatment also allows for complete- This relationship enables the recipient to restrict the set of ness to be defined relative to the process using EMs rather possible described situations and thus helps build the inter- then defining completeness as an intrinsic property of EMs.
nal model of the described situation. The conversation is introduced completeness as a pragmatic successful if the recipient is able to re-create the intended property of enterprise models. It is now clear that this prag- matic completeness coincides with the EM unambiguously P. Bernus / Annual Reviews in Control 27 (2003) 211–220 and sufficiently carrying its situated meanings. In contrast • Qualities of the ‘enterprise architects' (skills, knowledge, with an absolute measure of completeness is the extent to which enterprise models are theories (in the • Reference to the type of enterprise architecting situation sense of model theory)—together with some denotational in which the EM is to be used (e.g. by use of an enterprise assignment—as opposed to being utterances allowing the Architecture Framework that stakeholders understand); recipient to create these theories.
• Ability to explicitly view the current model of the enter- One would think that if an EM is complete in the abso- prise engineering process (what the process is and where lute sense then it is also complete in the relativistic sense.
stakeholder activities fit into the process), including the However, this is not so: the recipient of the model may not capture of design history and future plan; possess the requisite abilities, or tools to correctly interpret a • Quick access to a wide range of encyclopaedic reference model which may be judged complete in the absolute sense material which may have been used in the production of by an omniscient external observer.
the EM (the use of multiple modalities is important toconnect the conceptual and the visual aspects); • Links in the design database between the partial and par- 4. Limitations and possibilities of reuse
ticular models and the enterprise engineering process.
The complexity of the enterprise architecting process (and 4.1. Possibilities of reuse the models produced in it) can be significantly reducedby standardising on some components, such as the utilised Clearly the important condition of successful model reuse Enterprise Reference Architecture/Architecture Framework, is that models be pragmatically complete modelling languages (with well defined ontology), and com- shows at a glance the factors which together monly used reference models.
form the enterprise engineering situation. The ‘described situation' here is the interpretation of EMs as perceived by Framework it itself a model of the architecting process encompassing all activities during the life of the enter- For an EM to be (re)usable as intended, it is thus necessary prise. They are usually accompanied by a methodology (or to specify what is assumed about the use of the model in methodologies) that detail these activities as well as pro- terms of all these factors (as listed in These factors pose modelling tools and modelling languages to be used of successful reuse are to be reproduced in the ‘reusing' by the architecting process.
4.2. Limitations of reuse Used enterprisearchitecture framework The lack of the same factors which enable the intended Common Reference Models interpretation to take place can limit the possibility of reuse.
To prevent problems it is necessary to review the prerequi- Model of the particularenterprise architecture sites 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 com- panies 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 Actions andcommunication does not necessarily include all stakeholders that would EM Tools incl.
need these models. For example, models can be used for analysis to improve business processes, analysis of the im-pacts of the change before it is introduced, management of Enterprise architects with the enterprise's knowledge resources (share, improve and role and motivationexperience with given type of enterprise preserve them), training of new employees, etc. In certain knowledge of architecture framework circumstances it may not be the enterprise model that needs knowledge of modelling languageseducation in given discipline to be further detailed, rather it is employees who need train- in-house (local) knowledge ing so that they can correctly interpret and use the existingmodels.
Fig. 4. Factors affecting the pragmatic interpretation of enterprise modelsof EMs as perceived by stakeholders (called ‘enterprise architects' in the The lack of adherence to an Enterprise Reference Archi- tecture can have a negative effect on the success of reuse.
P. Bernus / Annual Reviews in Control 27 (2003) 211–220 When models are produced they tend to be precise with re- models, whether they are models used for the same life cy- spect to the intended use and ignore details not necessary for cle phase or not.
that use. Failure to understand the original intended usageis a misuse of EMs and is a cause of misinterpretation.
5.1. Model interoperability The lack of prompt access to adequate reference mate- rial (available particular models, reference models, ency- When a model is developed using one selected language clopaedic references, etc.). Both the availability and the users often need to communicate these to someone who uses promptness of access are important; since failure to use a different tool supporting a slightly different modelling lan- the reference when it would be needed introduces an un- guage for the same purpose, i.e. to represent the same view due backtracking point to the design process (this is a point of the enterprise. The task of model exchange/translation where progress is only possible if assumptions are made).
(interoperability) is often near impossible, or requires inten- People might use the model with implicit assumptions and sive human intervention and ad-hoc decisions. The reason later, when assumptions prove to be false, incorrect inter- for the lack of tool interoperability is mainly the lack of pretations need to be unlearnt.
an agreed formal ontological theory that tool vendors could Enterprise Modelling Tools (EMTs) can alleviate denota- use for model translation for import or export. While for ba- tional and some of the situational misinterpretations, and if sic process modelling a standard ontology (PSL-Core) ex- the EMT includes simulation capability this can help inves- ist with currently 50 extensions, the tigate the implicit properties of (executable) specifications.
scope of this formal definition is process modelling, and Below a set of desirable EMT functions is outlined for help- such formal ontology for the entire scope of enterprise mod- ing participants of the enterprise architecting process to be elling (for all life cycle phases and all modelling views) is in the situation where correct interpretation is possible.
still under development. Also, tool vendors need to makean effort to implement translators for their supported lan-guages to make use of this standard ontology. Given that 5. Implications for Enterprise Modelling Tools
the formal definition of many currently used modelling lan-guages is still not available, tool interoperability remains a Every engineering area produces a number of models future requirement, and tool vendor contribution to the PSL to support the design process. Architects and civil engi- ontology extensions could speed up this process.
neers represent buildings, roads and bridges using a seriesof interrelated two or three dimensional graphical models, 5.2. Mutually constraining models each model serving a particular task (activity) in the de-sign process. Electrical and electronic engineers represent An even harder problem is the maintenance of relation- their artefacts using a list of models, ranging from block ships between models that belong to consecutive life cycle diagrams, through dc and dynamic models, to calculate the phases. While these models are mutually constrained (e.g.
flow of electronic signals and of heat in their constructions, a change in the requirements specification mandates some two and three dimensional models are created for the design change in the architectural design and vice-versa), there is of the electro-mechanical structure of circuits and to design no 1:1 relationship between the two models, reflecting the the mechanical and chemical processes of manufacturing.
fact that design decisions are needed to turn a specification Chemical engineering uses block diagrams to represent the into a design. However, this does not mean that modelling processes of a chemical factory, and engineering companies tools should not be able to maintain a relationship, at least to who build the equipment and piping use models common the level of constraint checking and constraint propagation in mechanical engineering. Software engineers use a series of models to capture the functional requirements, and theinformation flow within the software, and other diagrams to 5.3. Representation of design process and design history represent the software artefacts that implement the requiredfunctions. Control engineers use theoretical equations (mod- The design process is an iterative activity that includes els) to calculate the static and dynamic behaviour of the down-stream and up-stream processes. It is hard to under- control system, and various models to demonstrate that the stand models in isolation, unless the links to other models chosen implementation technology will indeed deliver the are understood, and unless the design process itself is un- desired control function. Enterprise Architects use functional derstood by all participants in the same way. The Intelligent (activity and behaviour) and information models to specify CAD community has long argued ( business processes and their interactions and resource and that design tools must have a model of the design process organisational models to represent the implementation, as itself so as to adequately support the design activity. Con- well as models to directly control some of the processes.
sequently (1) the design process must be represented as a All of these areas have respective design/modelling tools.
process that interconnects life cycle activities of the artefact; However, when a model of an artefact or enterprise is de- and (2) the life history of the actual instance of this pro- veloped it is hard to maintain the relationship between these cess 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 needed, where formal models (expressed in text or graph- situation (cf. utterance situation in as ics) are mixed with visual representations (an approach reflected in experimental systems that capture Design Ra- well known in certain areas, such as in tools for architects, but not used in Enterprise Modelling Tools). Theories of conversation (thatto achieve mutual understanding the participants need to 5.4. Support for uniformly understood communication and have an agreement on what constitutes the present design situation, and have access to the same common referencesfor denotational (e.g. experimental) purposes. Therefore Traditional modelling tools offer functionality to help the it is necessary to allow access to visual, not only con- designer create a model using a fixed set of modelling lan- ceptual, representations from the same workbench, since guages. They do not help other stakeholders to understand design processes need both aspects of reality.
these models. What is usually offered by today's tools ismerely the ability to export the contents of models as webpages. Below is a shortlist of requirements that EMTs need to satisfy for successful communication using enterprise mod-els. (Only those requirements are listed here which are not Reasons of incompleteness of enterprise models were usually part of a state-of-the-art tool.) analysed and a definition of pragmatic completeness wasgiven which can, and should, be achieved in enterprise mod- • Offer links to reference material and cross references to elling. It was demonstrated how enterprise models carry other EMs (the requirement of grounding).
meaning. This resulted in requirements for the enterprise en- • Be permissive: allow multiple modelling languages to be gineering process, which—if not met—can limit the viability used and offer translation between them (this is the same of the process. The analysis of the same factors resulted in interoperability requirement that was discussed above, requirements for improved Enterprise Modelling Tools.
but translation into representations familiar to the readerof the model needs a more flexible function then meremodel import–export—e.g. cross references to other mod- els should also be translated).
• If translation between models is not possible the user of Barwise, J. (1988). The situation in logic. Stanford, USA: CSLI.
the EMT is still to be provided with a common reference.
Barwise, J., & Perry, J. (1983). Situations and attitudes. Cambridge, MA: For example, imagine that the tool stores a dynamic model of a part of an artefact and a two dimensional model of a Dorval, B. (Ed.). (1990). Conversational organization and its development.
working surface of the same artefact. The two models can Norwood, NJ: Ablex.
Hughes, Sh. (1998). Achieving interoperability among Enterprise Mod- practically not be related in terms of translation of their elling Tools. School of Computing and Information Technology Hon- contents or even through constraints—the only relation- ours Dissertation. Nathan, Brisbane: Griffith University.
ship in this case is that they are about the same physical Hysom, R. (2003). Enterprise modelling—The readiness of the organi- entity. However, the tool should allow the linking of these sation. In P. Bernus, L. Nemes, & G. Schmidt (Eds.), Handbook on models to some common reference, such as by reference enterprise architecture (pp. 373–416). Berlin: Springer.
to a three dimensional picture of the artefact making it clear to the user that the two models are models of the same object.
IFIP-IFAC Task Force. (2003). The generalised enterprise reference ar- • Make the enterprise architecting process itself explicit and chitecture and methodology (GERAM). In P. Bernus, L. Nemes, & up-to-date (through reference models and the model of the G. Schmidt (Eds.), Handbook on enterprise architecture (pp. 22–64).
Berlin: Springer.
particular process). This is the same requirement as the ISO15704:2000. (2000). Requirements for generalised enterprise reference one above for design process and history representation, architectures and methodologies. ISO TC184/SC5/WG1.
but apart from this representation the EMT should sup- ISO18629:2000. (2000). Industrial systems and automation—Process port all meaningful manipulation and analysis of these as Specification Language. JWG8 ISO TC184/SC4-SC5.
well (e.g. "what if the same process is repeated but with 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 • EMs are to be communicated between people and mu- tual understanding is to be an observable occasion in this Kalpic, B., & Bernus, P. (2002). Business process modelling in process (support negotiation, discussion, learning, and in industry—The powerful tool in enterprise management. International general, co-operative group work). Regarding theoreti- Journal of Computers in Industry, (3) 299–318.
Kalpic, B, Bernus, P, & Mühlberger, R. (2004). Business process mod- cal foundations model presentation should be based on elling and its applications in the business environment. In C. T. Leon- a sound understanding of how people acquire and share des (Ed.), Business and technology of the new millennium. Norwell: knowledge. Technologically, multi-modal interfaces are Kluwer (to appear).
P. Bernus / Annual Reviews in Control 27 (2003) 211–220 Lee, J., Gruninger, M., Jin, Y., Malone, T., Tate, A., & Yost, G. (1998).
Pask, G. (1975). Conversation, cognition, and learning. Amsterdam: El- The PIF process interchange format and framework. Knowledge En- gineering Review, (2), 1–30.
Ramesh, B., Dhar, V. (1992). Supporting systems development by captur- Lloyd, J. W. (1984). Foundations of logic programming. Berlin: Springer.
ing deliberations during requirements engineering. IEEE Transactions Marca, D. A., & McGowan, C. L. (1988). SADT. New York: on Software Engineering, 18(6), 498–510.
Sheth, A. P., Larson, J. A. (1990). Federated database systems for man- Myers, K. L., Zumel, N. B., Garcia, P. (2000). Acquiring design rationale aging distributed, heterogeneous, and autonomous databases. ACM automatically. Artificial Intelligence for Engineering Design, Analysis Computer Surveys, 223, 183–236.
and Manufacturing, 14(2), 115–135.
Nemes, L., Bernus, P. (1984). An incomplete manufacturing model needs tributed database systems. Proceedings of AFIPS, 50(5), 487– matching design tools. In Proceedings of 16th CIRP International Seminar on Manufacturing Systems (pp. 26–43), Tokyo.
Tomiyama, T., Xue, D., Umeda, Y., Takeda, H., Kiriyama, T., & Noran, O. (2003). A mapping of individual architecture frameworks Yoshikawa, H. (1992). Systematizing design knowledge for Intelli- (GRAI, PERA, C4ISR, CIMOSA, ZACHMAN, ARIS) onto GERAM.
gent CAD systems. In G. Olling & F. Kimura (Eds.), Human aspects In P. Bernus, L. Nemes, & G. Schmidt (Eds), Handbook on enterprise in computer integrated manufacturing (pp. 237–248). Amsterdam: architecture (pp. 65–212). Berlin: Springer.

Source: http://www.cit.gu.edu.au/~bernus/publications/pdfs/Enterprise_models_for_enterprise_architecture.pdf