Generalised Enterprise Reference Architecture and Methodology: Difference between revisions

Revision as of 01:17, 10 January 2009

Latest revision as of 03:05, 12 August 2025

(43 intermediate revisions by 24 users not shown)

Line 1:

'''Generalised Enterprise Reference Architecture and Methodology''' (GERAM) is a generalised [[Enterprise Architecture framework]] for [[enterprise integration]] and [[business process]] [[engineering]]. It identifies the set of components recommended for use in [[enterprise engineering]].<ref name="Nell97"> J.G. Nell, NIST (1997). "[http://www.mel.nist.gov/workshop/iceimt97/ice-gera.htm An Overview of GERAM]" ICEIMT'97 International Conference on Enterprise Integration Modelling Technology 1997. Updated 30 January 1997</ref>

[[File:GERAM Framework.jpg|thumb|360px|Fig 1. GERAM Framework: This set of components is identified in the first image and briefly described in the following. Starting from defined concepts to be used in enterprise integration (GERA), GERAM distinguishes between the methodologies for enterprise integration (GEEM) and the languages used to describe structure, contents and behaviour of the enterprise (GEML).]]

'''Generalised Enterprise Reference Architecture and Methodology''' ('''GERAM''') is a generalised [[Enterpriseenterprise Architecturearchitecture framework]] for [[enterprise integration]] and [[business process]] [[engineering]]. It identifies the set of components recommended for use in [[enterprise engineering]].<ref name="Nell97"> [[J.G. Nell]], NIST (1997). "[https://web.archive.org/web/19990221190103/http://www.mel.nist.gov/workshop/iceimt97/ice-gera.htm An Overview of GERAM]" ICEIMT'97 International Conference on Enterprise Integration Modelling Technology 1997. Updated 30 January 1997</ref>

This framework iswas developed in the 1990s by ana joint task force of both the [[International Federation of Automatic Control|IFAC]]/ (IFAC) and the [[International Federation of Information Processing|IFIP]] Task Force(IFIP) on [[Enterpriseenterprise Architecture|Architecturesarchitecture]]s for [[Enterpriseenterprise Integration]]integration. StartingThe development started fromwith the evaluation of then-existing enterpriseframeworks integrationfor architectures[[enterprise theapplication Taskintegration]], Forcewhich haswas developed into an overall definition of a [[so-called "generalised architecture]]. This proposed framework was labelled as GERAM for "Generalised Enterprise Reference Architecture and Methodology".<ref name="BN94"> [[P. Bernus]], and L. Nemes (1994). "A Framework to Define a Generic Enterprise Reference Architecture and Methodology". In: ''Proceedings of the International Conference on Automation, Robotics and Computer Vision (ICARCV'94)'', Singapore, November 10–12, 1994.</ref>

== Overview ==

One of the basics of GERAM is that [[Enterpriseenterprise modelling]] iswas seen as the major itemissue in [[enterprise engineering]] and integration. ThereforeIt contained several of building blocks, bothin which the methodologies and the corresponding languages willhave bebeen implemented, insuch enterpriseas:
* Enterprise modelling tools (GEMT) which willto support the enterprise integration process.
* Ontological theories (OT),
* genericGeneric enterprise models (GEMs) and
* generic enterpriseGeneric modules (GMs)
The willbuilding blocks were designed to support the modelling process by providing means for more efficient modelling.<ref name="Nell97"/>

The modelling process will result in anresulting enterprise model (EM) which represents all or part of the [[enterprise operation]]. These models will allow simulation of operational alternatives and thereby their evaluation leading to the optimum structure, contents and behaviour of the enterprise operation. GERAM provides a generic description of all the elements recommended in enterprise engineering and integration.

Generalised Enterprise Reference Architecture and Methodology (GERAM) is an enterprise-reference architecture that models the whole life history of an enterprise integration project from its initial concept in the eyes of the entrepreneurs who initially developed it, through its definition, functional design or specification, detailed design, physical implementation or construction, and finally operation to obsolescence. The architecture aims to be a relatively simple framework upon which all the functions and activities involved in the aforementioned phases of the life of the enterprise-integration project can be mapped. It also will permit the tools used by the investigators or practitioners at each phase to be indicated. The architecture defined will apply to projects, products, and processes; as well as to enterprises.<ref name="Nell96"/>

== History ==

Generalised Enterprise Reference Architecture and Methodology (GERAM) iswas developed in the 1990s by an [[International Federation of Automatic Control|IFAC]]/[[International Federation of Information Processing|IFIP]] Task Force on [[Enterprise Architecture|Architectures]] for [[Enterprise Integration]], which consisted of [[Peter Bernus]], [[James G. Nell]] and others. The IFAC/IFIP Task Force on Architectures for Enterprise Integration was establishmentestablished in 1990 and hadhas studied enterprise-reference architectures ever since.<ref name="Nell96"> JG[[J.G. Nell]] (2006). "[http://www.mel.nist.gov/sc5wg1/np_geram.htm Requirements and Methodology for Enterprise-Reference Architectures: A New Work Item Proposal]". updated 20 May 1996.</ref>

InThe itstask work the Task Force hasforce established the requirements to be satisfied by candidate enterprise-reference architectures and their associated methodologies to fulfill the needs of [[Private industry|industry]] for such aids to [[enterprise integration]]. The result has been called GERAM, for "Generalized Enterprise-Reference Architecture and Methodology", by the Task Force. The Task Force has shown that such an architecture is feasible and that several architectures presently available in the literature can already or potentially can fulfilfulfill such requirements.<ref name="Nell96"/>

The devopmentdevelopment of enterprise-reference architecture has evolved from the developemtdevelopment of Design Methodology for Advanced Manufacturing Systems in the 1980s,<ref>[[Guy Doumeingts|Doumeingts, G.]], [[Bruno Vallespir|Vallespir]], B., Darracar, D., M., "Design Methodology for Advanced Manufacturing Systems", Computers in Industry, Vol. 9, pp. 271-296, December 1987.</ref> such as [[CIMOSA]], the Open System Architecture for CIM.<ref>[[AMICE Consortium,]] (1989). ''Open System Architecture for CIM, Research Report of ESPRIT Project 688'', Vol. 1, Springer-Verlag, 1989.</ref><ref>[[AMICE Consortium]] (1991), ''Open System Architecture, CIMOSA, AD 1.0, Architecture Description'', ESPRIT Consortium AMICE, Brussels, Belgium, 1991.</ref> The GERAM framework was first published by [[Peter BernusandBernus]] and Laszlo Nemes in 1994.<ref name="BN94"/>

== GERAM Topics ==

=== GERAM Components ===

The Generalised Enterprise Reference Architecture and Methodology (GERAM) consists of a series of eight main components, as shown in figure 1:

=== GERAM Components ===

* ''Generic Enterprise Reference Architecture (GERA)'' : Defines the enterprise related generic concepts recommended for use in enterprise integration projects. These concepts include enterprise systems life cycle; business process modelling; modelling languages for different users of the architecture (business users, system designers, IT modelling specialists, others); integrated model representation in different model views.

The eight main components, as shown in figure 1 are:

* ''Generic Enterprise EngineeringReference MethodologiesArchitecture (GEEMGERA)'' : DescribeDefines the enterprise related generic processesconcepts ofrecommended for use in enterprise integration projects. These methodologiesconcepts mayinclude beenterprise describedsystems inlife termscycle; ofbusiness process modelsmodeling; withmodeling detailed instructionlanguages for eachdifferent stepusers of the integrationarchitecture process.(business users, system designers, IT modeling specialists, others); integrated model representation in different model views.

* ''Generic Enterprise Engineering Methodologies (GEEM)'': Describe the generic processes of enterprise integration. These methodologies may be described in terms of process models with detailed instruction for each step of the integration process.

* ''Generic Enterprise ModellingModeling Languages (GEML)'' : Define the generic constructs (building blocks) for enterprise modellingmodeling adapted to the different needs of people creating and using enterprise models.

* ''Generic Enterprise Modeling Tools (GEMT)'': Define the generic implementation of enterprise-integration methodologies and modeling languages and other support for creation and use of enterprise models.

* ''Generic Enterprise Modelling ToolsModels (GEMTEM)'' : DefineRepresents the generic implementation of enterprise-integration methodologiesoperation. andThese modellingmodels languageswill andbe otherrepresented supportusing forgeneric creationmodeling andlanguage use of enterprise modelsconstructs.

* ''Ontological Theories (OT)'' : Formalise the most generic aspects of enterprise-related concepts in terms of essential properties and axioms.

* ''Generic Enterprise Models (EMGEMs)'' : RepresentsIdentify thereference enterprisemodels operation. These(partial models) which capture concepts common to many enterprises. GEMs will be representedused usingin genericenterprise modellingmodeling languageto constructs.increase modeling process efficiency.

* ''Generic Modules (GMs)'' : Identify generally applicable products to be employed in enterprise integration (e.g. tools, integrating infrastructures, others.).

* ''Ontological Theories (OT)'' : Formalise the most generic aspects of enterprise-related concepts in terms of essential properties and axioms.

* ''Generic Enterprise Models (GEMs)'' : Identify reference models (partial models) which capture concepts common to many enterprises. GEMs will be used in enterprise modelling to increase modelling process efficiency.

* ''Generic Modules (GMs)'' : Identify generally applicable products to be employed in enterprise integration (e.g. tools, integrating infrastructures, others.).

=== Generic Enterprise Reference Architecture ===

''Generic Enterprise Reference Architecture'' (GERA) defines the enterprise related generic concepts recommended for use in enterprise integration projects. These concepts include [[enterprise Life Cycle|life cycle]]; enterprise [[wikt:entity|entity typetypes]]s, [[enterprise modelling]] with [[business process modelling]]; integrated model representation in different [[view model|model viewviews]]s and [[modelling languages]] for different users of the [[enterprise architecture]] (business users, system designers, IT modelling specialists, among others).<ref name="Nell97"/>

[[File:GERA Life-Cycle Concept.jpg|thumb|180px|Fig 2. GERA Life-Cycle Concept.]]

[[File:GERA Life-Cycle Concept.jpg|thumb|180px|Fig 2. GERA Life-Cycle Concept.]]

==== Life-Cycle Concept ====

Provides for the identification of the life-cycle phases for any enterprise entity from entity conception to its final end. The Figure 2: GERA Life-Cycle Concept, shows the GERA life cycle phases of enterprise entities. A total of 9 life cycle phases has been defined.

* Identification phase allows the identification of the enterprise business or any part of it in terms of its relation to both its internal and external environment. This includes the definition general commitments of the integration or engineering activities to be carried out in relevant projects.

* Concept phase provides for the presentation of the management visions, missions, values, operational concepts (build/buy, etc.), policies, plus others.

* Requirement phase allows the description of operational processes and collection of all their functional, behavioural, informational and capability requirements.

* Design phase is the specification of operational system with all its components satisfying the above requirements. Process and resources alternatives may be specified which provide operational alternatives to be used during the operation.

* Implementation phase describes the real operational system which may deviate from the designed system due to enterprise preferences or availability of components.

* Build phase supports the system manifestation, physical implementation of resources, testing and validation for the designed processes and the subsequent release for operation.

* Operation phase employs the released operational processes and the provided resources to support the life cycle phases of the enterprise products.

* System Change/Re-Engineering phase allows to modify or re-engineer the operational processes according to newly identified needs or capabilities provided by new technologies.

* End of Life phase supports the recycling or disposal of the operational system at the ending of its use in the enterprise operation. This phase has to provide concepts for recycling and/or disposal of all or part of the system.

[[File:GERA Enterprise-Entity Concept.jpg|thumb|360px|left|Fig 3. GERA Enterprise-Entity Concept.]]

* Identification phase allows the identification of the enterprise business or any part of it in terms of its relation to both its internal and external environment. This includes the definition general commitments of the integration or engineering activities to be carried out in relevant projects.

* Concept phase provides for the presentation of the management visions, missions, values, operational concepts (build/buy, etc.), policies, plus others.

* Requirement phase allows the description of operational processes and collection of all their functional, behavioural, informational and capability requirements.

* Design phase is the specification of operational system with all its components satisfying the above requirements. Process and resources alternatives may be specified which provide operational alternatives to be used during the operation.

* Implementation phase describes the real operational system which may deviate from the designed system due to enterprise preferences or availability of components.

* Build phase supports the system manifestation, physical implementation of resources, testing and validation for the designed processes and the subsequent release for operation.

* Operation phase employs the released operational processes and the provided resources to support the life cycle phases of the enterprise products.

* System Change/Re-Engineering phase allows to modify or re-engineer the operational processes according to newly identified needs or capabilities provided by new technologies.

* End of Life phase supports the recycling or disposal of the operational system at the ending of its use in the enterprise operation. This phase has to provide concepts for recycling and/or disposal of all or part of the system.

[[File:GERA Enterprise-Entity Concept.jpg|thumb|360px|left|Fig 3. GERA Enterprise-Entity Concept.]]

==== Enterprise Entity Type Concept ====

Identifies entity types to be used in enterprise engineering and enterprise integration. Adopting a recursive view of integration altogether five entity types with their associated life-cycles can be identified. The recursiveness of the first four entity types can be demonstrated by identifying the role of the different entities, their products and the relations between them. Figure 3: GERA Enterprise Entity Concept, shows the GERA life cycle phases of enterprise entities. A total of 9 life cycle phases has been defined.

* Strategic Enterprise Management Entity (type 1): defines the necessity and the starting of any enterprise engineering effort.

* Strategic Enterprise ManagementEngineering/Integration Entity (type 12): definesprovides the necessitymeans to carry out the enterprise entity type 1. It employs methodologies (type 5 entity) to define, design, implement and build the startingoperation of anythe enterprise engineeringentity effort.(type 3 entity).

* Enterprise Engineering/Integration Entity (type 23): providesis the meansresult to carry outof the enterpriseoperation of entity type 12. It employsuses methodologies (entity type 5) and the operational system provided by entity) type 2 to define, design, implement and build the operationproducts (services) of the enterprise entity (type 34 entity).

* EnterpriseProduct Entity (type 34): is the result of the operation of entity type 23. It usesrepresents methodologies (entity type 5) and the operational system provided by entity type 2 to define, design, implement and build theall products (services) of the enterprise (type 4 entity).

* ProductMethodology Entity (type 45): isrepresents the resultmethodology ofto thebe operationemployed ofin any enterprise entity type 3. It represents all products (services) of the enterprise.

* Methodology Entity (type 5): represents the methodology to be employed in any enterprise entity type.

Figure 3 represents the chain of enterprise entity developments. The type 1 entity will always start creation of any lower level entity by identifying goal, scope and objectives for the particular entity. Development and implementation of a new enterprise entity (or new business unit) will then be done by a type 2 entity; whereas a type 3 entity will be responsible for developing and manufacturing a new product (type 4 entity). With the possible exception of the type 1 entity all enterprise entities will have an associated entity-life cycle. However, it is always the operational phase of the entity-life cycle in which the lower entity is defined, created, developed and built. The operation itself is supported by an associated methodology for enterprise engineering, enterprise operation, product development and production support

Line 72 ⟶ 68:

[[File:GERA Generic-Reference-Architecture Concept.jpg|thumb|left|240px|Fig 5. GERA Generic-Reference-Architecture Concept.]]

==== Enterprise Modelling concept ====

Enterprise Modelling concept provides process models of enterprise operations. Process oriented modelling allows to represent the operation of enterprise entities and entity types in all its aspects: functional, behaviour, information, resources and organisation. Models which can be used for decision support by evaluating operational alternatives or for model driven operation control and monitoring.

To hide complexity of the resulting model it will be presented to the user in different sub-sets (views). This view concept is shown in Figure 5 : GERA Generic Reference Architecture Concept. It is applicable during all phases of the life cycle. Please note that the views will be generated from the underlying integrated model and any model manipulation. That means any change being done in one particular view will be reflected in all relevant aspects of the model. The GERA life cycle model has defined four different views: function, information, decision/organisation and resource/structure. Other views may be defined if needed and supported by the modelling tool. In addition, the life cycle model of GERA provides for two different categories of modelling: operation control and customer-service related.

==== Modelling Language concept ====

Modelling languages increase the efficiency of enterprise modelling. In addition they allow a common representation of the enterprise operation. Modelling languages have to accommodate different users of enterprise models; for example, business users, system designers, and IT-modelling specialists.

Modelling languages have to support the modelling of all entity types across all phases of their respective life cycles. In addition, modelling languages have to provide generic constructs as well as macro constructs (GEMs) buildbuilt from generic ones. The latter will further enhance modelling productivity.

Figure 5 shows the reference architecture for those enterprise entity life cycle phases which require generic constructs. The partial level shows the place of the GEMs in the reference architecture. The particular level indicates the life cycle phases of the enterprise entity itself.

Line 86 ⟶ 83:

=== Generic Enterprise Engineering Methodologies ===

[[File:Enterprise Engineering and the Life-Cycle Concept.jpg|thumb|240px|Fig 6. Enterprise Engineering and the Life-Cycle Concept.]]

''Generic Enterprise engineering methodologies'' (GEEM) describe the process of [[enterprise integration]] and, according to the GERAM framework (Figure 1), will result in a model of the [[enterprise operation]]. The methodologies will guide the user in the engineering task of [[enterprise modelling]] and integration. Different methodologies may exist which will guide the user through the different tasks required in the integration process.<ref name="Nell97"/>

Enterprise-engineering methodologies should orient themselves on the life-cycle concept identified in GERA and should support the different life cycle phases shown in Figure 2. The enterprise integration process itself is usually directed towards the enterprise entity type 3 (see above) operation and carried out as an enterprise engineering task by an enterprise entity type 2 (Figures 2 and 4). The integration task may start at any relevant engineering phase (indicated in Figure 6: Enterprise Engineering and the Life-Cycle Concept.) of the entity life cycle and may employ any of those phases. Therefore, the processes relating to the different phases of enterprise engineering should be independent of each other to support different sequences of engineering tasks.

Enterprise engineering methodologies may be described in terms of process models with detailed instruction for each step of the integration process. This allows not only a very good representation of the methodology for its understanding, but provides for identification of information to be used and produced, resources needed and relevant responsibilities to be assigned for the integration process. Process representation of methodologies should employ the relevant modelling language discussed below.

=== Generic Enterprise-Modelling Language ===

''Generic enterprise modelling languages'' (GEML) define generic constructs (building blocks) for [[enterprise modelling]]. Generic constructs which represent the different elements of the operation improve both modelling efficiency and model understanding. These constructs have to be adapted to the different needs of people creating and using enterprise models. Therefore, different languages may exist which accommodate different users (e.g. business users, system designers, IT modelling specialists, others).<ref name="Nell97"/>

Modelling the enterprise operation means to describe its processes and the necessary information, resources and organisational aspects. Therefore, modelling languages have to provide constructs capable of capturing the semantics of enterprise operations. This is especially important if enterprise models are to support the enterprise operation itself.

Model-based decision support and model-driven operation control and monitoring require modelling constructs which are supporting the end users and which represent the operational processes according to the users perception.

Modelling languages increase the efficiency of enterprise modelling. In addition they allow a common representation of the enterprise operation. Modelling languages have to support the modelling of all entity types across all phases of their respective life cycles. In addition, modelling languages have to provide generic constructs as well as macro constructs (GEMs) build from generic ones. The latter will further enhance modelling productivity.

=== Generic Enterprise-Modelling Tool ===

''Generic enterprise modelling tools'' (GEMT) define the generic implementation of the [[enterprise integration]] methodologies and [[modelling language]]s and other support for creation and use of [[enterprise model]]s. Modelling tools should provide user guidance for both the modelling process itself and for the operational use of the models. Therefore, enterprise modelling tools designs have to encompass not only the modelling methodology, but should provide model enactment capability for simulation of operational processes as well. The latter should also include analysis and evaluation capabilities for the simulation results.<ref name="Nell97"/>

=== Enterprise Models ===

''Enterprise models'' (EMs) represent the enterprise operation mostly in the form of [[business process]]es. However, in certain cases other representations may be suitable as well. Business processes will be represented using the generic modelling-language constructs defined above for the relevant engineering methodology. Enterprise operations are usually rather complex and therefore difficult to understand if all relevant aspects of the operation are represented in a common model. To reduce the model complexity for the user, different views should be provided which allow the users only to see the aspect of concern.<ref name="Nell97"/>

=== Ontological Theories ===

''Ontological theories'' (OT) formalise the most generic aspects of enterprise related concepts in terms of essential properties and axioms. [[Ontological theories]] may be considered as '[[Metamodeling|meta-modelmodels]]s' since they consider facts and rules about the facts and rules of the enterprise and its models.<ref name="Nell97"/>

=== Generic Enterprise Models ===

''Generic enterprise models'' (GEMs) identify [[reference model]]s (partial models) which capture concepts common to many enterprises. GEMs will be used in enterprise modelling to increase modelling process efficiency.<ref name="Nell97"/>

=== Generic Modules ===

Line 120 ⟶ 117:

* [[CIMOSA]]

* [[Functional Software Architecture]]

* [[ISO 19439]]

== References ==

Line 126 ⟶ 124:

== Further reading ==

* [[François Vernadat|F.B. Vernadat]] (1996). "Enterprise Modeling and Integration: Principles and Applications", Chapman & Hall, London. {{ISBN|0-412-60550-3}}

* [[Theodore J. Williams|T.J. Williams]] and Hong Li, ''A Specification and Statement of Requirements for GERAM (The Generalised Enterprise Reference Architecture and Methodology) with all Requirements illustrated by Examples from the [[Purdue Enterprise Reference Architecture]] and Methodology PERA'', REPORT NUMBER 159 Purdue Laboratory for Applied Industrial Control November 1995, Version 1.1

* D. Shorter, Editor, "An evaluation of CIM modelling constructs - Evaluation report of constructs for views according to ENV 40 003", In: ''Computers in Industry'' - Vol. 24, Nrs 2-3

* [[Theodore J. Williams|T.J. Williams]], et al., "Architectures for integrating manufacturing activities and enterprises", In: ''Computers in Industry'' - Vol. 24, Nrs 2-3

* T.J. Williams, et al., "Architectures for integrating manufacturing activities and enterprises", In: ''Computers in Industry'' - Vol. 24, Nrs 2-3

* ''ENV 40 003 Computer Integrated Manufacturing'' - Systems Architecture - Framework for Enterprise Modelling CEN/CENELEC, 1990

* ''ENV 12 204 Advanced Manufacturing Technology'' - Systems Architecture - Constructs for Enterprise Modelling CEN TC 310/WG1, 1995

* Charles J. Petrie, Jr (1992). ''Enterprise Integration Modelling; ICEIMT Conference Proceedings'', The MIT Press,. 1992 ({{ISBN |0-262-66080-6).}}

* Charles J. Petrie, Jr (1992). ''Enterprise Integration Modelling; ICEIMT Conference Proceedings'', The MIT Press, 1992 (ISBN 0-262-66080-6).

== External links ==

{{CommonscatCommons category|GERAM}}

* [http://www.cit.gu.edu.au/~bernus/taskforce/geram/versions/geram1-6-3/v1.6.3.html GERAM: Generalised Enterprise Reference Architecture and Methodology Version 1.6.3] {{Webarchive|url=https://web.archive.org/web/20081010224903/http://www.cit.gu.edu.au/~bernus/taskforce/geram/versions/geram1-6-3/v1.6.3.html |date=2008-10-10 }}. by [[Peter Bernus]], March 1999.

[[Category:Enterprise modelling]]

[[Category:ReferenceEnterprise modelsarchitecture frameworks]]