ICEIMT GERAM
21 August, 1997
1
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
The Contribution of the Generalised
Enterprise Reference Architecture to
Consensus in the Area of Enterprise
Integration
Peter Bernus1, Laszlo Nemes2
1
2
School of Computing and Information Technology, Griffith University
Nathan (Brisbane) QLD 4111, Australia <[email protected]>
Division of Manufacturing Science and Technology, CSIRO, Locked
Bag No 9., Preston, VIC., 3072, Australia <[email protected]>
Abstract
An overview of the brief history and structure of the generalised enterprise reference architecture and methodology (GERAM) is given together with the discussion of its role to systematise the activities of the disciplines that contribute to enterprise integration, and its use as a shopping list of capabilities, or components
that individual enterprises need for small and large scale programmes of change.
Keywords
Generalised enterprise reference architecture and methodology, GERAM, enterprise integration, CIMOSA, PERA, GRAI-GIM
1 Introduction
Enterprise Integration (EI) as an interdisciplinary field of study, or discipline, collects and organises knowledge necessary to better implement change processes in
the enterprise - whether they are processes to improve, or perhaps completely
overhaul, a given enterprise, or change processes that create an entirely new one.
With such a wide scope, it is not likely that a single approach to enterprise integration will suffice, therefore EI must necessarily include a way of systematising
the contributions of disciplines and schools of thought to the area. Even the list of
contributing disciplines is long; below is an attempt to give a relatively complete
enumeration:
•
•
•
management science,
information technology,
computer science,
ICEIMT GERAM
21 August, 1997
2
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
• co-ordination science,
• information systems,
• artificial intelligence,
• control engineering,
• linguistics,
• economics,
• sociology,
• industrial engineering,
• manufacturing technology.
There is an inevitable danger in this state of affairs. The very wide background
needed to appreciate what is already available is an impediment to progress: ‘new’
approaches spring into existence based on ignorance or disregard of previous results rather than on genuine need.
The situation is similar to what happened when microprocessors appeared and
Lee gave the following advice for microprocessor programming:
“the engineer lists his instructions to the microprocessor on one or more
program-assembly forms, which combine the functions of a circuit schematic and an assembly print or wire list. Then he writes the instructions
into the microprocessor's control memory – at this stage a programmable
read-only memory, the equivalent of a circuit breadboard. Finally, he
tests the PROM, altering it and the program-assembly form in parallel,
until he can plug the fully debugged version into its socket in the overall
system prototype” (Lee, 1976)
– and this came in the year of Smalltalk 76, eight years after Algol 68, or Dijkstra’s
papers on structured programming (Dijkstra, 1968)!
Similarly, in Enterprise Integration, a long list of required ingredients have
been known to the theoreticians and practitioners, but the links between them have
never been made. We believe that the systematisation of EI knowledge is therefore
necessary for progress through directing attention to veritable needs, and helping
researchers and funding bodies to identify fruitful areas of investigation.
GERAM, the Generalised Enterprise Reference Architecture and Methodology
offers such a systematisation. Of course, with the large number of components a
mere list of what is available would be not very useful, since an inventory list does
not promote the mastering of the complexity of this field. GERAM therefore had
to define, by way of abstraction, such terms which commonly capture the constituents of enterprise integration..
It would have been tempting to equate enterprise integration and enterprise engineering, and we have considered doing so. However, we thought that this was
inappropriate, and would have promoted a technocratic viewpoint. It is worth
elaborating on this in the introduction, but before that a working definition of the
two terms is to be given.
Enterprise integration is the field of study, or discipline, which collects
knowledge that enables enterprises to achieve a very high level of maturity (called
integrated state). The integrated enterprise may be defined as a ‘planning agent’,
ICEIMT GERAM
21 August, 1997
3
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
ie. an entity that has a set of current objectives and carries out its activities so as to
successfully fulfil the objectives. As a consequence of this high level characterisation, an integrated enterprise is also an aware enterprise meaning that changes in
the internal or external environment will as soon as possible be reflected in the objectives and in its actions; making sure that activities of all the components contribute to the overall objective in a co-ordinated way. As a result the integrated
enterprise is agile, and has a highly dynamic information and material flow. Note
that there is no requirement that the enterprise’s behaviour must be based on planning, it is only required that the enterprise appear for the external observer as if it
did.
An enterprise may use various types of processes which have the objective to
achieve or sustain this state of affairs . Enterprise engineering is a type of process,
largely explicit in nature, which uses a combination of managerial and technical
methods to design or re-design and enterprise (eg. benchmarking, enterprise modelling, planning, etc.). At the same time, especially many small enterprises engage
in strategic behaviour which can not be termed enterprise engineering, because it is
neither explicit nor is a conscious application of enterprise engineering methods or
principles; nevertheless through managerial insight and instinct improve the enterprise in the same direction as the application of an enterprise engineering method
would.
2 A brief history of GERAM
The IFIP/IFAC Task Force on Architectures for Enterprise Integration , in its first
report (Williams et al, 1994; Bernus et al, 1996a) concluded that there were at
least two types of enterprise reference architectures noted in the literature, and
named these Type I and Type II architectures.
Type I architectures are Reference Models describing the typical structure of
an entire enterprise. In practice such reference models exist only for parts of the
enterprise, eg. its control-information system. Since various authors and companies have taken very different decisions as to what level of detail should be incorporated into their reference models, the available models are hard to compare.
The technical difference between these reference models has been well analysed in
(Goranson,1992) and has contributed significantly to the understanding of the
common elements and strategic decisions of the way to incorporate these elements
into hardware-software systems.
Type II Reference Architectures are, in contrast, life-cycle models, which describe the evolution of the enterprise, from its initial concept to its final decommissioning. The above Task Force report has reviewed in detail three of these reference architectures: PERA (Williams, 1994), CIMOSA (Vernadat, 1992) and
GRAI-GIM (Doumenigts et al, 1992), and after initial problems with trying to understand the relationship between them, concluded that neither of the architectures
investigated were at the time (1994) complete, each had something unique to contribute. For example, although all three identified the traditional ‘requirements, design, implement’ life-cycle phases, some were more detailed then others in the not
ICEIMT GERAM
21 August, 1997
4
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
so obvious initial phases of enterprise development and none included at the time
the coverage of the end of life for the enterprise. Some architectures explicitly
provided suitable languages for enterprise modelling, and some referred to existing modelling tools and languages to be used as required. At least two of the architectures had associated methodologies, ie. detailed instructions as to how management could tackle the enterprise engineering process, although the two methodologies seemed to disagree to a remarkable extent.
It became evident, that a finer analysis of what is provided by enterprise reference architectures could be of great use for management – to know what it is that
they get and what is it that they do not get when ‘buying into’ one or the other architecture.
Figure 1 – The GERAM Framework Components (several similar versions of
this diagram exist; the important message is in the identity of the
components)
Before the 1994 Singapore Task Force meeting F.Vernadat and T.J.Williams
proposed that a generalisation of the reference architectures formerly studied could
be used to gain joint benefits from the three architectures (this was called the ‘generic enterprise reference architecture and methodology’). (Bernus and Nemes,
1994) and later more detailed revised versions (Bernus and Nemes, 1996b) led to
the first definition of GERAM, which by the suggestion of Kurt Kosanke was renamed to ‘Generalised Reference Architecture and Methodology’. This further
ICEIMT GERAM
21 August, 1997
5
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
was followed by numerous discussions and revisions of GERAM the IFIP/IFAC
Task Force during 1995 and 1996. The first public release of the Task Force definition of GERAM Version 1.3 (IFIP IFAC Task Force, 1997. The document was
prepared with substantial contributions both in content and editing by a number of
people: Kurt Kosanke, François Vernadat, Ted Williams, Guy Doumeingts, David
Chen, Peter Bernus, Laszlo Nemes, Richard Weston, Jim Nell, Jakob Vlietstra,
David Shorter, Jean-Jacques Michel, Jim Nevins, Ljuba Vlacic and other members
of the Task Force and ISO TC184/SC5/WG1, and the GERAM requirements are
currently (1997) being standardised in this ISO Working Group.
3 The components of GERAM
GERAM organises the components necessary in EI into a framework (Fig 1). The
brief definition of the components is given below, more detail is available in
GERAM V1.2 (IFIP IFAC Task Force, 1997).
3.1 GERA Enterprise Reference Architecture
The following concepts are defined:
3.1.1 Life Cycle
The life cycle of an entity is the representation of main activity types that contribute to the life (creation, operation, and decommissioning) of that entity. Any entity
that is involved in enterprise integration has a life cycle of its own (Fig.2). Each
life cycle “phase” represents an activity type which contributes to the life of that
entity. The inverted commas refer to the fact that life cycle activities are almost
never following one another in a sequence. The reason why they may be called
phases is that the relationships between them constrain in what order the activities
in a change-, or life process can progress. Figure 2 represents life cycle phases applicable to any entity. Many similar subdivisions of life cycle phases exist and
Fig.2 tries to be as complete as possible, but we should not be dogmatic about the
naming or subdivision into phases, as long as the coverage extends to the entire life
of the entity.
ICEIMT GERAM
21 August, 1997
6
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
Figure 2 Life cycle phases
3.1.2 Life History
Any enterprise entity has a history of its own. The history captures the main
events, or milestones in the life of the entity. Change processes form part of the
history of an entity, with possibly many small and big change processes simultaneously happening. Some change processes conclude with implementation and the
result becomes part of the operation, but most processes are abandoned earlier.
Figure 3 represents the life history of an enterprise entity, and its relationship with
life cycle phases. Within the life history each change process has a history of its
own, shown on the diagram as continuous trajectories.
3.1.3 Enterprise Entity Types
Various entities need to be considered by those involved in enterprise design. The
most obvious entity is an enterprise which produces products or services. Two
useful types of enterprise entities are commonly differentiated: repetitive and oneof a kind enterprises. For the first, a manufacturing enterprise, for the second a
project enterprise would be representative examples. Further subdivisions may be
used to develop a useful typology of enterprises, through categorisation of enterprise Reference Models (partial models – see 3.6).
ICEIMT GERAM
21 August, 1997
7
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
Figure 3 Life history of an enterprise entity
We notice that an enterprise is in the business of implementing life cycle activities of its product (eg. the mission of an enterprise may be to implement the design, detailed design, manifestation, and maintenance activities of its product). For
this reason any enterprise integration effort must also have an intimate knowledge
of the life cycle phases of the products of the enterprise.
3.1.4 Modelling Framework (with modelling views)
Each life cycle phase has a special type of concern, ie. the activities normally carried out in that life cycle phase. For example, the identification phase of the entity
is preoccupied with the investigation of the identity of the enterprise business entity, and with the possible courses of action that this entity might undertake in order
to change. The design phase is preoccupied with defining the details of the structures which make up the entity; including the human and, machine components (eg.
manufacturing and computing equipment, software, etc). The modelling framework of GERA is the definition of a minimum set of views deemed necessary to be
considered in the life cycle phases of an enterprise entity. Each life cycle phase
may produce a number of models which support the given phase’s activities. To
hide complexity, these models may be produced or presented in subdivisions.
ICEIMT GERAM
21 August, 1997
8
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
Figure 4 GERAM Modelling Framework with various subdivisions, life cycle
phases and model categories
Various subdivisions of concerns are identified in the GERA modelling
framework. The subdivisions come from the respective modelling subdivisions of
CIMOSA, PERA and GRAI and are consistent with (can be mapped to) other
similar subdivisions found in modelling systems like ARIS (Scheer, A.-W. 1995),
IEM (Mertins et al., 1992), etc. Subdivisions are made according to modelling
view (function, information, organisation, resource – with the possibility of further
specialised or additional views identified as necessary, eg. decisional view which is
a special functional view introduced by GRAI); subdivision according to the purpose of modelled activity (mission fulfilment service and production, versus management and control); subdivision according to the means of implementation (human versus automated); and subdivision according to physical manifestation
(hardware versus software).
The modelling framework divides models into the generic, partial and particular categories (see enterprise models) in the same way CIMOSA does.
These subdivisions may also be used as indication of a minimal scope of enterprise modelling. Figure 4 presents in one the GERAM life cycle phases, the generic, partial and particular model categories, and the superposition of all defined
subdivisions of the modelling framework.
ICEIMT GERAM
21 August, 1997
9
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
Any particular GERAM-compliant reference architecture may decide to use
only some of these subdivisions, but must ensure the coverage, or scope implicit in
the above subdivisions.
3.2 Enterprise Engineering Methodologies
Enterprise engineering methodologies describe the processes of enterprise integration. Their scope extends to all life cycle activities (see GERA Life Cycles). An
enterprise engineering methodology will help the user in the process of managing
and carrying through change throughout the progression of the entity’s life-cycle
activities. The upper two sets of these activities (identification and concept) are
partly management and partly modelling tasks, while the requirements specification
and design activities are partly engineering and partly management tasks.
3.3 Enterprise Modelling Languages
Modelling languages, depending on their characteristics, are used for one or more
areas of the modelling framework. Their expressive power must be such that the
models created using them can be utilised to support the process of enterprise engineering and subsequent operation.
There are four important requirements that any given set of enterprise modelling languages must satisfy:
•
•
•
•
adequacy of expressive power,
completeness of the coverage of the modelling framework,
adequacy as a communication tool among the involved parties, and
sharing of a common ontological basis (ie. the language metamodels being
views of an integrated metamodel).
Extensibility of the set is a fifth requirement and is related to the requirement of
the extensibility of the generic enterprise models (see there).
3.4 Enterprise Engineering Tools (EET)
In the process of enterprise engineering numerous models are created, for the purpose of analysis and design. Enterprise Engineering Tools are those modelling
supports which can be utilised for the creation, analysis and management of those
models. The services of the tools must extend to all involved parties who need to
create or otherwise utilise enterprise models in the process. An EET therefore is
like an engineering workbench. The workbench may also incorporate a separate
tool which (as a kind of help- or teaching system) supports a particular enterprise
engineering methodology.
3.5 (Particular) Enterprise Models
The process of enterprise integration, based on enterprise engineering methodologies, and with the help of enterprise modelling tools, creates models of the par-
ICEIMT GERAM
10
21 August, 1997
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
ticular enterprise expressed in enterprise modelling languages. Depending on the
objective of the enterprise integration activity these models may be used for
•
•
•
•
Decision support (eg for the analysis of current operation to identify the need
for change, or for the design of new the operation to select among alternatives);
Communication of design decisions among involved parties;
Education and training of personnel, and in general explicit representation of
company knowledge;
Model-driven control of processes (eg. establishment of workflow based processes).
3.6 (Partial) Enterprise Models
This category covers a very broad and rich set – essentially all those models which
can be used and reused for the creation of high quality models for the individual
enterprise.
Reusable models can be created on any level or life cycle phase which gives
these models an additional dimension.
Requirements and design level models of service and production processes include standard requirements (eg. lists of ‘must have’ properties for the enterprise –
such as the ISO9000 series of standards), or capability models which allow one to
evaluate or benchmark present practices, set objectives for the enterprise engineering project, and subsequently help design quality processes.
Requirements- and design level models may exist for the decision system, ie.
paradigmatic management and control system models.
Design level models may include typical organisational designs, with proven
properties so that organisational design may become similar to large scale engineering projects, based on system design using proven components (Malone et al,
1993).
Requirements- and design level models may describe the services of a complete system of application programs to help design the enterprise’s information
system from such models, eg. the database schemata and functional models of the
SAP R3 suite of programs would qualify (Williams and Hart 1997). The models of
application program interfaces of common integration infrastructure services are
another useful set of partial enterprise models.
As mentioned in the beginning of this article, those partial enterprise models
which describe the structure of the enterprise as a whole, are also called Reference
Models (or Type I Reference Architectures). Reference Models can serve as blueprints for the enterprise as a whole.
3.7 Enterprise Modules
Enterprise Engineering processes must be of a relatively short life span to be relevant; or else the premises based on which the change process was started may loose
their validity by the time the process finishes. For feasible enterprise integration
ICEIMT GERAM
11
21 August, 1997
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
programmes there must be systems of products available on the marketplace which
embody the functionality of the partial models based on which the models of the
changed enterprise are built.
We call these products (or product families) ‘enterprise modules’ usually marketed as ‘enterprise computing solutions’.
However, in addition to the information technology products equally important
modules are human resources available on the job market (with specified skills and
knowledge), and technological resources (including infrastructure) available for
building the production and service processes.
3.8 Generic Enterprise Concept Definitions
This component of GERAM is the collection of concept definitions in increasing
order of formality. Each form has the same underlying intention: to define the
meaning (semantics) or the terminology of EI. The forms defined are the following:
•
•
Glossary (written definitions and explanatory illustrations),
Meta-model (conceptual schemata, using some form of semantic data model,
eg. the Extended Entity Relationship Model, IDEF1X, NIAM, ODMG93 etc.),
and
• Ontological theory (in first order logic or equivalent mathematical formalism,
eg. KIF (or Ontolingua) (Farquhar et al,1997), Conceptual Graph (Sowa,
1992), Telos (Mylopoulos et al, 1990), Z (Spivey, 1988), etc.).
No one of the above forms is sufficient alone because a) these representations are
utilised for different purposes in enterprise integration, and b) there is no automatic
translation between them (at least between the first and the second two). The metaschema (metamodel) representation is necessary, because although a metaschema
may be generated from the ontological theory, at any given time there may not be
an ontological theory available (we do not have suitable theories for all phenomena) whereas a metaschema could still be developed.
Note, the concepts used in enterprise modelling languages need the formal
definition of their semantics, to allow automated analysis or execution.
4 The use of GERAM to understand approaches to enterprise
integration
4.1 The life cycle versus life history clarification
Figures 3 demonstrated that life cycles are only a functional abstraction of any
change process, and as such they cover all possible sequences of progress, including top down, prototype based, spiral etc. methods. The myth that the ‘waterfall
diagram is not applicable’ (and therefore should be dismissed as a means to simplify the complex nature of change processes) is based on the misunderstanding of
ICEIMT GERAM
12
21 August, 1997
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
how functional abstraction works: namely that functional abstraction abstracts from
time and therefore does not suggest any temporal sequence whatsoever.
The use of the waterfall diagram, and similar life cycle architectures lies in
their ability to identify the types of processes and capabilities that must be available for handling change or new design processes as well as to identify constraints
operating between them. A functional model imposes constraints on the possible
ways to progress, the constraints being summarised by the requirement that ‘any
design fact can be considered final only if the underlying requirements also can be
considered final’.
It is, therefore the business of methodologies to propose a design progression
for an enterprise engineering project, or for the design and implementation of any
entity for that matter. For example, a concurrent engineering methodology is a possible implementation of the waterfall life cycle.
As a result, the life cycle and life history concepts together demonstrate the
relationship between project management and entity life cycle.
4.2 Presentation of methodologies for the end user
Enterprise engineering methodologies may be presented to the end user in two different ways. Functionally described methodologies allow the enterprise to build
change management capability. If, and only if, such capabilities are present time
based methodologies can be followed step by step but their nature limits the applicability to the typical case for which they were designed.
An end user wishing to select a particular enterprise engineering methodology
has to be aware of the type to which the selected methodology belongs.
4.2.1 Functional presentation
Functionally presented methodologies group and present processes, activities,
methods, and tools according to the respective life cycle ‘phases’. Functional presentation (eg in form of a text and accompanying functional model) is concise, and
avoids repetition, but a direct utilisation assumes that a good project manager will
manage the succession of enterprise engineering activities – according to the nature of the project sometimes progressing from the top down, sometimes acting
concurrently, yet another time progressing in a spiral succession and using rapid
prototyping.
A functionally presented methodology is also useful for training purposes; to
develop capabilities which may subsequently be used by more efficient temporally
presented methodologies. (Even functionally presented methodologies may give
recipies for progression on the sub-process level but they do not prescribe a sequence on higher levels.)
Note that the above mentioned bad name of the waterfall model is probably
due to poorly designed and falsely advertised functional methodologies which as a
result were implemented as temporal sequences (of the ‘don’t-think-of-designbefore-the-specification-is-complete’ type).
ICEIMT GERAM
13
21 August, 1997
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
An enterprise can acquire functional capabilities necessary to manage change
projects through mastering a suitably rich change methodology. Based on these capabilities each individual change process (or project) would be managed in a
unique way of progression – according to the individual project’s level of innovation, availability of proven solutions, availability of background knowledge and
personnel, and earlier expertise with similar projects.
4.2.2 Temporal presentation
A temporally presented methodology prescribes certain sequence of progression.
For example workbooks may be made available, complete with project templates.
Such a prescription may be obtrusive, but within the limits of applicability is very
efficient.
Eg. in a repetitive type of project where top down progression is possible, a
prescriptive top-down methodology may be the suitable choice. An innovative
project may use a methodology with prescribed spiral progression. Yet another
methodology may use highly concurrent activity-scheduling for the life cycle activities, to shorten time to market.
4.3 Product modelling and enterprise modelling
The two basic approaches to enterprise integration, the design of integrated process
models and the design of integrated product models are intimately connected
through the realisation that a fundamental understanding of product life-cycles is
necessary to design an enterprise. For this reason the life cycle of both products
and enterprises are modelled and described by GERA.
When the enterprise entity under consideration is the product (eg. if the product is a plant), the elements of GERAM are to be understood as follows: Enterprise
Modelling Languages are those suitable to model various views of the product (eg.
expressed as information view models using STEP / Express (Express,
1994;Trapp, 1993) in each product life cycle phase. Partial product models (reusable, standard models) are the standard solutions for various elements of the plant,
or earlier solutions of similar plants. STEP Application Requirements Models are
partial functional views or models of the production system of the enterprise, and
finally product ontologies are part of the generic enterprise concept definitions of
the plant.
If this last paragraph was too complicated, the reader may draw a life cycle
diagram for each involved entity (the engineering project, the plant and the product
of the plant), and ask:
•
•
•
•
what models are to be produced for each life cycle phase for each of these entities;
what language to use to produce these models; and
what ontological theories define the meaning of these languages;
what models could be re-used to build the just identified models, rather then
developing these from scratch?
ICEIMT GERAM
14
21 August, 1997
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
Figure 5 –
Example for several change processes simultaneously happening: an enterprise engineering project, an unsuccessful
change attempt, and a merger which continues after initial
negotiations as one project
4.4 Coexisting change processes
The life cycle – life history diagram may be re-drawn with multiple change processes represented as trajectories in that diagram (see Fig.5), allowing enterprise
management to visualise the cross relationships among simultaneous change processes. Several conclusions can be drawn from this figure.
•
•
All change processes should originate from the operation, ie. the enterprise
must have the capability to recognise the signals that point into the direction of
minor or major change. These signals then start change processes, many of
which may abort at various stages of the process or merge with other processes;
Change processes that started as independent in separate enterprise business
entities may come into contact and through interaction evolve into a joint process. This is typical of business transformation via mergers, acquisitions, or
consortium formation. Consequently, specialised methodological help is
needed (with the backing of the other necessary components as defined in
GERAM).
ICEIMT GERAM
15
21 August, 1997
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
•
Change processes are carried out while the entity operates, with implementation causing as little disruption to operation as possible.
4.5 The differentiation between methodology, modelling language,
and tool
Many writers do not differentiate between a modelling language and engineering
methodology which is a problem. Modelling languages should be is neutral as to
what course of action should be taken by the enterprise engineering process and the
engineering methodology provides either a functional model or a prescription for
the engineering process. Enterprise engineering methodologies would typically
have an enterprise modelling methodology component, and this component would
use enterprise modelling languages in a particular way. However, a modelling language may be used in conjunction with several different modelling methodologies,
and the same modelling methodologies may be adopted by one or mode enterprise
engineering methodologies.
An enterprise engineering tool need not be committed to a particular methodology, although it may have a plug in component that supports design progression
according to a given methodology. What a tool must give is a list of analysis, synthesis, and model management functions, useful to support a variety of methodologies. (For example the term ‘BPR Tool’ is an oxymoron; one hopes that the tool
does not force BPR on the unsuspecting enterprise modeller who may just want to
find out, through a model, whether to engineer an new process at all?)
As a consequence of these differentiation’s end users have a far greater choice
then advertising material lets them to believe – as long as the tool functions are
separately specified from the characterisation of the supported language and from
the possible methodological support end users may combine these three components to their advantage and liking.
4.6 The scope includes all human, technological and information
processing aspects
Any change process that ignores one or two of the three elements, has great chance
of failing. Through the definition of enterprise integration’s scope in GERAM any
set of components claiming to be complete relative to the requirements must address each of these three issues.
GERA view subdivisions ensure that the enterprise system is extending to the
human-implemented and machine-implemented processes, including the description of any management and control tasks, and service and production tasks carried
out by humans.
The subdivision into hardware and software extended to the production machinery as well as the human organisation ensures that
•
In production systems the actual machinery is separately treated from controllable machine configurations;
ICEIMT GERAM
16
21 August, 1997
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
•
In the human organisation the capabilities of the employees are separately
treated from task descriptions or instructions (such that these two match).
4.7 GERAM as a shopping list: pick and choose components and capabilities to tackle change
Enterprise management may use GERAM as a locator of required methods, tools,
methodologies which together may be used to develop a capability in the enterprise
for continuous change management.
Since GERAM is the result of a generalisation of existing frameworks (ie
CIMOSA, GRAI-GIM, PERA), the end user will utilise one of these, or one of
their more specialised versions.
However, the end user may combine elements of existing reference architectures, based on their specific strengths in one or another of the discussed components.
4.8
‘Stacks’ of solutions
Reusable enterprise models are most useful if accompanied with a suitable implementation background (enterprise modules). Inversely, modules (products) are not
very helpful unless they can be connected into a system of solutions.
A solution stack is such a system of reference models and corresponding modules which allows the modelling to progress with relative disregard of implementation, because implementations (modules) allow any useful, or meaningful, modellevel combination. In other words, feasibility is guaranteed as long as models are
built from the predefined model-building blocks.
There is a constant need for non-proprietary, standards based solution stacks,
this is the reason for open systems standards.
5 Conclusion
Enterprise integration as an area of interdisciplinary study requires the concerted
effort of its contributing disciplines, to develop all of the methodologies, languages, tools and the of all other components necessary for enterprises to continuously adapt themselves to change. Beyond the requirement that an enterprise must
change from time to time is the requirement that enterprises should build into
themselves the capability to initiate and carry out change, both in form of continuous improvement or comprehensive enterprise engineering efforts.
The success of enterprise integration as a whole very much depends on the
ability to make high quality reusable models available for the practitioner managers
and technical personnel. These models must exhibit the most important enterprise
properties, such as self similarity, agility, the ability to be implemented as a global
virtual enterprise, etc. The existence of such models will allow a ‘drag-and-drop
enterprise modelling’ approach to be used by business end-users (top level management and technical personnel).
ICEIMT GERAM
17
21 August, 1997
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
6 References
Bernus, P.; Nemes,L.; Williams, T.J. (Eds) (1996a) Architectures for Enterprise
Integration (IFIP-IFAC Task Force report), Chapman and Hall, London.
Bernus, P.; Nemes, L. (1994, 1996b) A framework to define a generic enterprise
reference architecture and methodology, Comp.-Integr. Manuf. Sys. 9(3), pp.
179-91 (Earlier shorter version appeared in Proc ICARV94, Singapore).
Dijkstra, E. W. (1968) Goto Statement Considered Harmful, Commun. ACM,
11(3) pp.147-149.
Dijkstra, E.W. (October 1969) Structured Programming, in Report of the NATO
Science Committee on Software Engineering Techniques, Rome, Italy
Doumeingts, G.; Chen, D.; Marcotte, F.(1992) Concepts, models and methods for
the design of production management systems, Comp in Ind, 19(1) pp89-111
Goranson, H.T. (1992) Dimensions of enterprise integration, Proc ICIEMT92,
Petrie, C.J., Jr. (Ed), MIT Press pp101-113
IFIP-IFAC Task Force (1997), GERAM, The Generalised Enterprise Reference
Architecture, Version 1.3
Lee, E. (1976) When programming microprocessors, use your hardware
background, Electronics, 49(14) pp. 93-100
Vernadat, F. (1992) CIMOSA - a European development for enterprise integration
2. Enterprise modelling, Proc ICIEMT92, Petrie, C.J., Jr. (Ed), MIT
Press,189-204
Williams, T.J. et al (1994) Architectures for Integrating Manufacturing Activities
and Enterprises, Comp. in Industry 24(2-3) Spec. Issue on CIM pp111-140.
Williams, T.J. (1994) The Purdue Enterprise Reference Architecture, Computers in
Industry, 24(2-3) pp141-158
Scheer, A.-W. (1995) ARIS Toolset: a software product is born, Information
Systems, 19(8) pp607-624
Mertins, K.; Sussenguth, W.; Jochem, R. (1992) An object oriented method for
integrated enterprise modeling as a basis for enterprise coordination, in Proc
ICIEMT92, Petrie, C.J., Jr. (Ed), MIT Press,pp249-258
Malone, T.W.; Crowston, K.; Jintae Lee; Pentland, B. (1993) Tools for inventing
organizations: toward a handbook of organizational processes, Proc. 2nd
Worksh. on Enabling Technologies Infrastructure for Collab. Enterp.pp.72-82
Williams, K.; Hart, J. (1997) SAP: Connecting the enterprise Management
Accounting 78(10) pp. 51-54
Farquhar, A.; Fikes, R.; Rice, J. (1997) The Ontolingua Server: a tool for
collaborative ontology construction Int J. H.Comp Studies, 46(6), pp.707-727
Sowa, John F. (1992) Conceptual graphs special issue, Knowledge-based systems
series 5(3) Butterworth-Heinemann, Oxford, UK
Mylopoulos, J.; Borgida, A.; Jarke, M. (1990) Telos: representing knowledge
about information systems, ACM Trans. on Inf.on Systems 8(4) pp. 325-362
Spivey, J. M. (1988) Understanding Z : a specification language and its formal
semantics Cambridge University Press
ICEIMT GERAM
18
21 August, 1997
A somewhat shorter version of this article appeared as Bernus,P., Nemes.L., The Contribution of the
Generalised Enterprise Reference Architecture to Consensus in the Area of Enterprise Integration, Proc
ICEIMT97, K.Kosanke, J.Nell (Eds) Springer Verlag, Berlin, pp. 175-189
[Express](1994) Product data exchange using STEP (PDES). Part 11, The Express
language reference manual., U.S. Product Data Association, Fairfax, Va.
Trapp, G. (1993) The emerging STEP standard for product-model data exchange
Computer 26(2) pp.85-87