ã
ISO 1999 – All rights reserved(Web version: WG1 N431)
ISO/TC 184/SC 5
Date: 1999-08-20
ISO/FDIS 15704
ISO/TC 184/SC 5/WG 1
Secretariat: ANSI/NEMA (USA)
Industrial automation systems — Requirements for enterprise-reference architectures and methodologies
Type of document: International Standard
Sub-type of document: Not applicable
Stage of document: (50) Approval
Language of document: E
This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as permitted under the applicable laws of the user's country, neither this ISO draft nor any extract from it may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, photocopying, recording or otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to ISO at the address below or ISO's member body in the country of the requester:
ISO copyright office
Case Postale 56
ž CH-1211 Geneva 20Tel. +41 22 749 01 11
Fax +41 22 734 10 79
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.Contents
Foreword vi
0 Introduction vii
0.1 Rationale for enterprise-reference architectures and methodologies vii
0.2 Key principles of enterprise integration viii
0.2.1 Applicability to any enterprise viii
0.2.2 Enterprise identification and mission definition viii
0.2.3 Separation of mission-fulfilment functions from mission-control functions viii
0.2.4 Identification of process structures ix
0.2.5 Identification of process contents ix
0.2.6 Recognition of life-cycle phases ix
0.2.7 Evolutionary approach to enterprise integration ix
0.2.8 Modularity x
0.3 Aim and benefits of deploying enterprise-reference architecture and methodologies x
0.4 Benefits of this standard x
1 Scope 1
2 Normative References 1
3 Definitions 1
4 Requirements for enterprise-reference architectures and methodologies 4
4.1 Applicability and coverage of enterprise-entity types 4
4.1.1 Generality 4
4.1.2 Enterprise design 4
4.1.3 Enterprise operation 4
4.2 Concepts 4
4.2.1 General 4
4.2.2 Human-oriented 4
4.2.3 Process-oriented 5
4.2.4 Technology-oriented 5
4.2.5 Mission-fulfillment oriented 5
4.2.6 Mission-control oriented 5
4.2.7 Framework for enterprise modeling 5
4.2.8 Life cycle 5
4.2.9 Life history 5
4.2.10 Modelling views 6
4.2.11 Genericity 6
4.3 Components of enterprise-reference architectures and methodologies 6
4.3.1 Engineering methodologies 6
4.3.2 Modelling languages for model-based methodologies 6
4.3.3 Generic elements 6
4.3.4 Partial models 7
4.3.5 Particular models 7
4.3.6 Tools 7
4.3.7 Modules 7
4.3.8 Enterprise-operational systems 7
4.4 Representation 7
4.5 Glossary 8
5 Completeness and compliance 8
Annex A (informative) GERAM: Generalised enterprise-reference architecture and methodologies 9
A.1 Introduction 9
A.1.1 Background 9
A.1.2 Scope 9
A.2 The framework for enterprise engineering and enterprise integration 10
A.2.1 General 10
A.2.2 Definition of GERAM framework components 11
A.2.2.1 GERA – Generic Enterprise Reference Architecture 11
A.2.2.2 EEMs – Enterprise engineering methodologies 12
A.2.2.3 EMLs – Enterprise modelling languages 12
A.2.2.4 GEMCs – Generic enterprise modelling concepts 12
A.2.2.5 PEMs – Partial enterprise models 12
A.2.2.6 EETs – Enterprise engineering tools 13
A.2.2.7 EMs – (Particular) enterprise models 13
A.2.2.8 EMOs – Enterprise modules 13
A.2.2.9 EOSs – (Particular) enterprise operational systems 13
A.3 Description of GERAM framework components 13
A.3.1 GERA – Generalised Enterprise Reference Architecture 13
A.3.1.1 General 13
A.3.1.2 Human oriented concepts 14
A.3.1.3 Process oriented concepts 16
A.3.1.3.1 General 16
A.3.1.3.2 Life cycle 17
A.3.1.3.2.1 General 17
A.3.1.3.2.2 Entity identification 17
A.3.1.3.2.3 Entity concept 17
A.3.1.3.2.4 Entity requirement 17
A.3.1.3.2.5 Entity design 17
A.3.1.3.2.6 Entity implementation 18
A.3.1.3.2.7 Entity operation 18
A.3.1.3.2.8 Entity decommissioning 18
A.3.1.3.3 Life history 18
A.3.1.3.4 Entity types in enterprise integration 20
A.3.1.3.4.1 General 20
A.3.1.3.4.2 Operation oriented entity types 20
A.3.1.3.4.2.1 Project Enterprise Entity (Type A) 20
A.3.1.3.4.2.2 Repetitive Service- and Manufacturing Enterprise Entity (Type B) 20
A.3.1.3.4.2.3 Product Entity (Type C) 20
A.3.1.3.4.3 Recursive enterprise entity types 21
A.3.1.3.5 Process modelling 22
A.3.1.4 Technology oriented concepts 22
A.3.1.4.1 General 22
A.3.1.4.2 IT support for enterprise engineering and enterprise integration 23
A.3.1.4.3 Enterprise Model Execution and Integration Services (EMEIS) 24
A.3.1.5 Modelling framework of GERA 24
A.3.1.5.1 General 24
A.3.1.5.2 Enterprise modelling 25
A.3.1.5.3 View concepts 26
A.3.1.5.3.1 General 26
A.3.1.5.3.2 Entity model content views 27
A.3.1.5.3.3 Entity purpose views 27
A.3.1.5.3.4 Entity implementation views 28
A.3.1.5.3.5 Entity physical manifestation views 28
A.3.2 EEMs – Enterprise engineering methodologies 28
A.3.2.1 General 28
A.3.2.2 Human factor 31
A.3.2.3 Project management 32
A.3.2.4 Economic aspects 33
A.3.3 EMLs – Enterprise modelling languages 33
A.3.4 GEMCs – Generic enterprise modelling concepts 34
A.3.4.1 General 34
A.3.4.2 Glossary 35
A.3.4.3 Meta-models 35
A.3.4.4 Ontological theories 35
A.3.5 PEMs – Partial enterprise models 36
A.3.5.1 General 36
A.3.5.2 Partial human role models 36
A.3.5.3 Partial process models 36
A.3.5.4 Partial technology models 37
A.3.5.4.1 General 37
A.3.5.4.2 Partial models of IT systems 37
A.3.6 EETs – Enterprise engineering tools 37
A.3.7 EMOs – Enterprise modules 38
A.3.8 EMs – Enterprise models 38
A.3.9 EOSs – Enterprise operational systems 39
A.4 Glossary of references 39
A.4.1 General references 39
A.4.2 Standards 40
Annex B (informative) Bibliography 41
B.1 CIMOSA references 41
B.2 GRAI-GIM references 41
B.3 PERA references 42
B.4 GERAM references 42
B.5 References on the work of the IFAC/IFIP Task Force 43
B.6 Other important references in the field of enterprise integration 43
Foreword
ISO (the International Organisation for Standardisation) is a worldwide federation of national standards bodies (ISO-member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75% of the member bodies casting a vote.
International Standard ISO 15704 was prepared by Technical Committee ISO/TC 184, Industrial automation systems and integration, Subcommittee SC 5, Architecture, communications, and integration frameworks, Working Group WG 1, Modelling and architecture. In preparing this document, substantive contributions were received from groups involved with enterprise-reference architectures such as the Purdue Enterprise-Reference Architecture (PERA), the Graphes et Résultats et Activités Interreliés GRAI Integrated Methodology (GRAI GIM), the Computer Integrated Manufacturing Open System Architecture (CIMOSA), and the Generalised Enterprise-Reference Architecture and Methodology (GERAM).
Annexes A and B are informative. Annex A is based on version 1.6.2 of GERAM developed by the IFIP/IFAC Task Force on Architectures for Enterprise Integration who granted permission for its inclusion in ISO 15704.
0 Introduction
0.1 Rationale for enterprise-reference architectures and methodologies
Industrial enterprises create and modify manufacturing and business operations to improve performance in local and global markets. In the operational phase, they deploy a variety of resources such as people, information systems, and automated machinery. Individually and collectively these resources provide the functional capabilities required to expedite business processes and their constituent activities. The inter-working of resources needs to be organised and targeted to accomplish the mission. This requires suitable business rules and organisational structures to enable the enterprise to provide products and services to its customers in conformance with agreed upon criteria.
Enterprises operate under uncertain market and environmental conditions so that enterprise engineering may need to be ongoing. It follows that enterprise personnel have a variety of roles to play in the conception and ongoing development of the mission, business rules, business processes, organisational structures, and supporting resources and services. Because of the high levels of complexity involved in enterprise engineering, invariably it is necessary to deploy means of assessing, structuring, coordinating and supporting these engineering activities.
Enterprise-reference architectures underpinned by reference methodologies provide generally applicable means of organising and coordinating engineering projects. By adopting, and as required adapting, a reference methodology and architecture, enterprise personnel can cooperate in progressing enterprise-engineering projects, improving the enterprise and utilisation of resources. By adopting a reference methodology, architecture, and a supporting tool set, it becomes practical for personnel to reuse explicit enterprise designs and models to achieve enterprise engineering on an ongoing basis to realise further improvements in enterprise operation.
Therefore, a vital need is an enterprise engineering and integration reference base providing methodologies and supporting technologies that can realistically treat the problem of enterprise integration.
The work of the IFAC/IFIP (International Federation of Automatic Control/ International Federation for Information Processing) Task Force on Architectures for Enterprise Integration and of many other similar organisations around the world have recently focused their work on this problem in hopes of achieving the generic solution needed. Their work has shown that such a reference base can be devised, and must be underpinned by an enterprise-reference architecture that:
a) Can model the whole life history of an enterprise-integration project from its initial concept through definition, functional design or specification, detailed design, physical implementation or construction, operation to decommissioning or obsolescence;
b) Encompasses the people, processes, and equipment involved in performing, managing, and controlling the enterprise mission.
It is important to note that enterprise-reference architectures deal with the structural arrangement (organisation) of the development and implementation of a project or programme such as an enterprise-integration or other enterprise-development programme. In contrast to these enterprise-reference architectures, system architectures deal with the structural arrangement (design) of a system; for example, the computer-control-system part of an overall enterprise-integration system.
The IFAC/IFIP Task Force on Architectures for Enterprise Integration has developed the definition of a complete, generalised enterprise-reference architecture and methodology and has called it GERAM, described in annex A. GERAM will be used as the example reference for the requirements set forth in this document.
0.2 Key principles of enterprise integration
Several concepts that describe the nature of enterprise-reference architectures and methodologies have emerged from the studies of the IFAC/IFIP Task Force on Architectures for Enterprise Integration that can greatly simplify, integrate, and extend the work of enterprise engineering. This work has led to the development of GERAM, which is capable of supporting those who plan, design, and implement complex enterprise-integration projects.
Key principles of an enterprise-reference architecture are described below to provide a basis for the requirements of clause 4.
0.2.1 Applicability to any enterprise
The early work in CIM (computer-integrated manufacturing) and enterprise integration was confined largely to the field of discrete-parts manufacturing, and to computers and information handling. However, the basic principles involved in enterprise integration apply to any enterprise, regardless of its size and mission or any other such attributes involved and to all aspects of the enterprise. In addition, it has been a mistake to confine the integration discussions to information and control systems alone. Often there are problems within the mission system, manufacturing or other customer product and service operations, or in the associated human and organisational area whose solution would greatly ease the overall system problem, that is, a total solution must involve information, culture, and mission.
The reference architecture can be extended to cover all possible types of enterprise by considering manufacturing as a type of customer service, providing concept, development, design, modification, production, and supply of goods to the customer. Thus the mission-execution area of the architecture would represent the customer service rendered by any enterprise even if that service involved the supply of information-type products to the customer.
0.2.2 Enterprise identification and mission definition
No enterprise can exist in the long term without a business or mission, that is, it must produce products or services desired by its customers. It usually produces these products or services in competition with other enterprises. Therefore the enterprise identification and mission definition are essential parts of any enterprise-integration project.
0.2.3 Separation of mission-fulfillment functions from mission-control functions
There are only two basic classes of functions involved in operating any enterprise. These are described below.
a) One class comprises functions involved in fulfilling the mission, i.e. operating the processes that produce the product or service. In the manufacturing plant these would include all material and energy transformation tasks and the movement and storage of materials, energy, goods-in-process, and products; and services.
b) The other class comprises functions involved that manage and control the mission-fulfillment to achieve the desired economic or other gains that assure the viability or continued successful existence of the enterprise. These include the collection, storage, and use (transformations) of information to control the business processes, that is, to develop and apply necessary changes to the business processes to achieve and maintain their desired operation. Control includes all planning, scheduling, control, data management, and related functions.
0.2.4 Identification of process structures
Enterprise operation consists of many transformations of material, energy, and information that can be categorised into two distinct classes: one for information transformations and the other for material and energy transformations. These transformations will be carried out by many separate activities that can be executed both concurrently and sequentially to constitute processes of an equivalent class. Processes of both classes interface with each other in those activities that request and report status, and in those activities that deliver operational commands. In combination these transformations define the total functionality of the enterprise being considered.
0.2.5 Identification of process contents
For many technical, economic, and social reasons, humans are involved in the implementation and execution of many business processes of all types in both classes mentioned in clause 1.2.4. Other processes may be automated or mechanised. There are only three classes of implemented tasks or business processes, which are as follows:
a) Information and control activities that can be automated by computers or other control devices;
b) Mission activities that can be automated by the mission-fulfillment equipment;
c) Activities carried out by humans, whether of the information and control or mission-fulfillment class.
It is desirable to have a simple way of showing where and how the human fits in the enterprise and how the distribution of functions between humans and machines is accomplished.
0.2.6 Recognition of enterprise life-cycle phases
All enterprises, of whatever type, follow a life cycle from their initial concept in the mind of an entrepreneur through a series of stages comprising their development, design, construction, operation and maintenance, refurbishment or obsolescence, and final disposal.
Not only does this life cycle apply to the enterprise but also to the enterprise products as well. Carried further, one enterprise can be the product of another. For example, a construction enterprise could build a manufacturing plant (enterprise) as its product. The manufacturing plant would then produce its own product, such as an automobile. The automobile also has its own life cycle that goes through similar steps to those discussed here (see 0.2.1).
A particular distinction can be made between those life-cycle phases which are concerned with the creation and modification of enterprise entities (its development, design, construction, etc.) and their use (operation). This distinction enables the orderly move (release) from the engineering environment to the operation environment, providing for validation, testing and release of engineering results prior to operation.
0.2.7 Evolutionary approach to enterprise integration
The integration of all of the informational and customer-product and service functions of an enterprise may be a part of a master plan. The actual implementation of such integration may be broken up into a series of co-ordinated projects that are within the financial, physical, and technical capabilities of the enterprise. These projects can be carried out individually or collectively, as these resources allow, as long as the master plan is followed.
0.2.8 Modularity
Because of the massive nature of all enterprise integration projects, modularity should be enforced whenever possible. Thus it would be helpful if all activities were defined in a modular fashion, along with their required interconnections, so they may later be interchanged with other activities that carry out similar functions but in a different manner should this be desirable. Likewise, these replacement activities would also be best implemented in a modular fashion, permitting their later substitution by still other different methods of carrying out the same function. The choice of these implementation methods can be governed by independent design and optimisation techniques as long as the activity specifications are honoured.
Provided the modular implementation just stated is used, the interconnections between these modules can be considered interfaces. If these interfaces are specified and implemented using company, industry, national and/or internationally agreed upon standards, the interchange and substitution noted above will be greatly facilitated.
0.3 Aim and benefits of deploying enterprise-reference architectures and methodologies
An enterprise-reference architecture with its associated methodology and related enterprise-engineering technologies that fulfills the requirements of this standard will enable an enterprise-integration-planning team to determine and develop a course of action that is complete, accurate, properly oriented to future business developments, and carried out with the minimum of resources, personnel, and capital. That is, to:
a) Describe the tasks required;
b) Define the necessary quantity of information;
c) Specify relationships among humans, processes, and equipment in the integration considered;
d) Address management concerns;
e) Address relevant economic, cultural, and technological factors;
f) Detail the extent of computer-support required;
g) Support process-oriented modelling that can model the whole life history of an enterprise.
0.4 Benefits of this standard
The enterprise-reference architecture and methodology requirements in this standard will allow a specific enterprise-reference architecture and methodology to be checked for completeness with respect to its current and future purpose. This standard will help guide their development.
This benefit will be most relevant to any group charged with improving an enterprise infrastructure or its processes. Such a group will find it necessary to either select or create a reference architecture of its own with a terminology that pertains specifically to the company, industry, and culture involved. This standard will help guide that selection or creation.
1 Scope
This International Standard defines the requirements for enterprise-reference architectures and methodologies, as well as the requirements that such architectures and methodologies must satisfy to be considered a complete enterprise reference architecture and methodologies.
The scope of these enterprise-reference architectures and methodologies covers those constituents deemed necessary to carry out all types of enterprise creation projects as well as any incremental change projects required by the enterprise throughout the whole life of the enterprise, including
a) Enterprise creation,
b) Major enterprise restructuring efforts, and
c) Incremental changes affecting only parts of the enterprise-life cycle.
2 Normative References
The following normative document contains provisions which, through reference in this text, constitute provisions of ISO 15704. As an undated reference, the latest edition of the normative document applies. Members of ISO and IEC maintain registers of currently valid International Standards.
ISO 14258, Industrial automation systems — Concepts and rules for enterprise models
ISO 14258, Industrial automation systems — Concepts and rules for enterprise models: Technical Corrigendum 1
3 Definitions
For the purposes of ISO 15704, the following terms and definitions apply.
3.1
activity
NOTE Enterprise activity consists of elementary tasks performed in the enterprise that consume inputs and allocate time and resources to produce outputs.
3.2
architecture
NOTE There are two, and only two, types of architectures that deal with enterprise integration. These are:
a) System architectures (sometimes referred to as "type 1" architectures) that that deal with the design of a system, e.g. the computer control system part of an overall enterprise integration system;
b) Enterprise-reference projects (sometimes referred to as "type 2" architectures) that deal with the organisation of the development and implementation of a project such as an enterprise integration or other enterprise development programme.
3.3
attribute
NOTE An attribute models an intrinsic property of something, for example, the geometry of a part, the condition of a tool, or the qualifications of a worker.
3.4
behaviour
3.5
business process
3.6
enterprise
NOTE This term includes related concepts such as extended enterprise or virtual enterprise.
3.7
enterprise engineering
3.8
enterprise model
NOTE An enterprise model, which is used to improve the effectiveness and efficiency of the enterprise, identifies the basic elements and their decomposition to any necessary degree. It also specifies the information, resources and organisational requirements of these elements, and provides the information needed to define the requirements for integrated information systems.
3.9
framework
NOTE Neither the structure involved nor the relationship of the parts to each other have a life cycle or time relationship in contrast to the enterprise-reference ("type 2") architecture.
3.10
genericity
3.11
life cycle
3.12
life history
3.13
master plan
NOTE The master plan is based on management goals for the project and uses functional and economic analysis techniques for the preliminary engineering of the project to achieve an initial design specification and prove economic feasibility.
3. 14
methodology
NOTE In carrying out needed aspects of the life cycle of the entity integration project, the methodology prescribes or describes the processes of enterprise engineering and integration. A methodology may take account of any involved social, political and economic aspects.
3.15
mission
3.16
model
NOTE A model can be used to describe the enterprise activities or the different phases of the life cycle of the enterprise (see 3.8).
3.17
organisation
3.18
resource
3.19
structure
3.20
system
NOTE A system is characterised by its structure and its behaviour.
4 Requirements for enterprise-reference architectures and methodologies
4.1 Applicability and coverage of enterprise-entity types
4.1.1 Generality
Enterprise-reference architectures and methodologies shall be capable of assisting and structuring the description, development, operation, and organisation of any conceivable enterprise entity, system, organisation, product, process, and their supporting technology. There may be reference architectures that cover a sub-set and therefore are confined to a specific class or type of enterprise or systems (such as discrete parts manufacturing, process industries, and information systems). However, the area covered by these reference architectures and methodologies shall be clearly identified.
The methodology associated with a reference architecture shall provide the necessary guidelines and management techniques for the initiation and pursuit of a project or program of development and operation of an enterprise or entity. Such a methodology may or may not be model-based. That is, the enterprise engineering process may or may not result in a specific enterprise model.
Enterprise-reference architectures and methodologies need not be based on any one single methodology and its accompanying architecture or framework. There are potentially many different methodologies and/or frameworks that might be used for it. The primary consideration shall be applicability and capability in relation to these requirements.
Enterprise-reference architectures and methodologies shall identify concepts and components as described in 4.2 and 4.3.
4.1.2 Enterprise design
Enterprise-reference architectures and methodologies shall identify the activities needed to manage, conceive/define, describe, design, implement, maintain, and decommission any enterprise entity. See 3.2.3 and 3.4 of ISO 14258.
4.1.3 Enterprise operation
Enterprise-reference architectures and methodologies shall identify the activities needed to use the results of enterprise engineering in the operation itself. Such use may include model-based decision support and model-driven operation monitoring and control.
4.2 Concepts
4.2.1 General
The enterprise-reference architectures and methodologies shall address the role of humans, the description of processes (function and behaviour) and the representation of all supporting technologies throughout the life cycle of the enterprise.
4.2.2 Human oriented
Enterprise-reference architectures and methodologies shall exhibit the capability to represent human aspects, such as organisational and operational roles, capabilities, skills, know-how, competencies, responsibilities, authorisation, and relations to the organisation.
4.2.3 Process oriented
Enterprise-reference architectures and methodologies shall exhibit the capability to represent the enterprise operation. Such representations shall cover both the functionality and behaviour of the operation. The representations shall recognise the life cycle and life-history concepts of enterprise-entity types and shall support process-oriented operations.
4.2.4 Technology oriented
Enterprise-reference architectures and methodologies shall exhibit the capability of representing all technologies employed in the enterprise operation.
NOTE Such representation of 4.2.2, 4.2.3, and 4.2.4 shall provide for integration-technology infrastructures used to support enterprise engineering and operation of business processes, models of enterprise resource (information technology, manufacturing technology, office automation and others), facility layout models, information-system models, communication-system models and logistics models.
4.2.5 Mission-fulfillment oriented
Enterprise-reference architectures and methodologies shall exhibit the capability to represent any process and its constituent activities involved in performing the established mission of the enterprise in terms of providing the enterprise products and services to its customers.
4.2.6 Mission-control oriented
Enterprise-reference architectures and methodologies shall exhibit the capability to represent any process and its constituent activities of the accomplishment of the management and control of the established mission of the enterprise according to the criteria established by enterprise management.
4.2.7 Framework for enterprise modeling
Enterprise-reference architectures and methodologies that are model-based shall exhibit the capability to model entities within the conceptual space defined by the dimensions of life cycle, genericity, and modelling views.
NOTE These dimensions are discussed further in ISO 14258.
4.2.8 Life cycle
Enterprise-reference architectures and methodologies shall identify and represent the life-cycle phases that are pertinent during the life of any enterprise entity.
NOTE Life-cycle phases encompass all activities from inception to decommissioning (or end of life) of the enterprise entity which might be characterised. There is no presumption that these phases are necessarily sequential.
4.2.9 Life history
An enterprise-reference architecture and methodology shall be capable of representing the life history of any enterprise entity; that is, the representation in time of activities carried out on any enterprise entity.
NOTE Using the life-cycle concept of 4.2.8, the user can identify these activities as life-cycle-activity types while the life history allows the same user to identify the corresponding time element. This demonstrates the iterative nature of the life-cycle concept compared with the time sequence of life history. These iterations identify different change processes required on the operational processes and/or the product or customer services.
4.2.10 Modelling views
The enterprise-reference architectures and methodologies that are model-based shall provide concepts for representing different views (see 3.7 of ISO 14258) of an enterprise model to allow it to be described as an integrated model but to be presented to the user in different subsets. Views contain a subset of facts present in the integrated model in order to concentrate on relevant questions that the respective stakeholders may wish to consider using enterprise modelling. Different views may be made available highlighting certain aspects of the model and hiding others. The concept of view is applicable to models of all entity types across their entire life cycle.
Enterprise-reference architectures and methodologies that are model-based shall include these four model-content views: function, information, resource, and organisation.
4.2.11 Genericity
Those reference architectures and methodologies that are model-based shall provide the capability for representing generic-enterprise elements (4.3.3), partial-enterprise models (4.3.4), and particular-enterprise models (4.3.5).
4.3 Components of enterprise-reference architectures
4.3.1 Engineering methodologies
Enterprise-reference architectures and methodologies shall provide enterprise-engineering methodologies that guide the user in the process of management of change and provide methods of progression for every type of life-cycle activity for any enterprise-entity type.
Enterprise-engineering methodologies shall describe the process of enterprise integration and enterprise modelling. Different methodologies can exist that will cover different aspects of the enterprise-change processes. These can be complete integration processes, or incremental changes as experienced in a continuous improvement process.
4.3.2 Modelling languages
Enterprise-reference architectures and methodologies that are model-based shall identify enterprise modelling languages or modelling constructs that allow the enterprise operation to be described. See 3.2 and 3.6 of ISO 14258.
Modelling constructs shall allow users to represent the different elements of the modelled-enterprise entity and thereby improve both modelling efficiency and model understanding. The form (representation) of modelling constructs shall be adapted to the needs of people creating and using enterprise models. Therefore, different languages may exist to accommodate the aspects of different users (e.g. business users, system designers, information-technology modelling specialists, and others). In addition, modelling languages may allow the formation of higher level constructs out of more basic constructs (macro constructs) to enhance modelling productivity.
Enterprise modelling languages shall be expressive enough to model human roles, operational processes and their functional contents as well as the supporting information, office and production technologies.
Their semantics can be described in terms of ontological theories. This is especially important if enterprise models are to support the enterprise operation itself, because such models must be executable. However, the definition of the formal semantics shall be supported by natural language explanations of the concepts as well.
4.3.3 Generic Elements
Enterprise-reference architectures and methodologies can be based on generic elements of enterprise design and modelling. Such generic elements are, in increasing order of formality, glossaries, meta-models, and ontological theories. These elements provide for consistency of enterprise representations.
4.3.4 Partial models
Enterprise-reference architectures and methodologies that are model-based shall support the concept of partial-enterprise models (reusable reference models). This allows the user to capture and reuse concepts common to many enterprises and thereby to increase modelling efficiency. Partial models still need adaptation to the requirements of the specific enterprise. Partial models can cover one or all concepts identified in 4.2.
4.3.5 Particular models
Enterprise-reference architectures and methodologies that are model-based shall support the creation of particular-enterprise models that describe part or all of any enterprise entity.
Enterprise models may be expressed in enterprise modelling languages and may be maintained, created, analysed, stored, and distributed using enterprise-engineering tools. Both model creation and model use may be supported by integrating-information-technology services. The use of such services will ensure access to real-time information in the engineering and operational environments of the enterprise.
4.3.6 Tools
Enterprise-reference architectures and methodologies shall be supported by computer based tools that aid the user in enterprise engineering and integration projects. Such tools shall be based on one or more enterprise-engineering methodologies and may have implemented one or more modelling language.
Such tools shall provide analysis and simulation capabilities for the creation, manipulation, use, and management of enterprise designs and models, as well as their analysis, description, and evaluation. These functions are needed for decision making in the course of enterprise engineering. In addition, such tools may support collaborative work across organisation boundaries.
Engineering tools can enable the user to connect enterprise designs and models with the real business process, so as to keep the designs and models up-to-date.
4.3.7 Modules
Enterprise-reference architectures and methodologies shall provide the capability for representing the concept of enterprise modules or implemented building blocks or systems (products, or families of products) that are utilised as common resources in enterprise engineering and enterprise integration.
One set of enterprise modules important to enterprise engineering and integration is the integrating infrastructure or the set of integration-technology services required for enterprise engineering and operation in heterogeneous environments.
4.3.8 Enterprise-operational systems
One result of the enterprise-engineering process shall be a design or model for the enterprise-operational system. The enterprise operational system shall consist of the hardware and software needed to fulfil the enterprise objectives and goals. The content of the operating system is derived from enterprise requirements.
4.4 Representation
Enterprise-reference architectures and methodologies shall provide a mechanism to guide users in the use of the associated components of 4.3, e.g. a framework or high-level, graphical interpretation. The framework or graphical form should show the applicability of, and relations between, the different components.
4.5 Glossary
To promote understanding about projects and other co-operative efforts, enterprise-reference architectures and methodologies shall provide a
a) Consistent glossary and a semantics and syntax for use in enterprise-engineering and integration efforts, or
b) Reference to other suitable glossaries.
5 Completeness and compliance
The degree of completeness of a candidate architecture and methodology shall be determined by their limits of applicability as defined by 4.1 and the extent to which they employ the concepts and components of 4.2 and 4.3. Consequently the degree of completeness from this point of view shall be measured by any restrictions to a particular class or type of enterprise.
Any assessment of the degree of compliance of a candidate architecture and methodology shall be qualified by the following:
a) A preliminary statement as to whether or not they are model based;
b) A statement of the degree to which they then conform partially or totally to the appropriate requirements of 4.2 to 4.5.
In the event of partial compliance, areas of non-conformance shall be explicitly identified.