Strategic Workshop on Enterprise Integration and Enterprise Computing
(Systems and Software Engineering Standards in the Context of Enterprise Integration)

19-20 November 1998, Sanctuary Cove
(Brisbane's Gold Coast, Queensland Australia)

Position Statement - GERAM and its possible implications to System and Software Engineering application

Peter Bernus,
Chair, IFIP-IFAC Task Force on Enterprise Integration

Enterprise Integration Group
School of Computing and Information Technology (Faculty of ICT)
Griffith University, Australia

Background

In 1990 Jim Nevins made a proposal to the International Federation of Automatic Control (IFAC) to establish a Task Force with the mandate to write a report on the state of the art in Reference Architectures for Computer Integrated Manufacturing (CIM) Systems.

The question was: 'what architectures are available and how is it possible to use them to help in the design and construction of CIM systems?'

It was obvious that such report would have to be developed in conjunction with Information Technology experts, and therefore the Task Force was jointly formed with the International Federation for Information Processing (IFIP) - under IFIP TC5, the Technical Committee on Computer Applications in Technology, with Ted Williams as chair. Since 1996 Peter Bernus chairs the group and Ted Williams is vice chair. The IFIP arm since that time became IFIP Working Group 5.12 (Enterprise Integration) and the IFAC arm became the Technical Committee on Enterprise Integration. The membership counts almost 50 experts from 16 countries, ranging from IT director to software engineer and control engineer, from academic to consultant, and various industry experts.

Today the group is called the IFIP-IFAC Task Force on Enterprise Integration.

The aim of the Task Force is to define, foster and develop the field of Enterprise Integration in its broadest sense, and thus its scope extends to many application areas, such as manufacturing, information and service industries, as well as government.

First Triennium Findings: Life Cycle Architectures for Enterprises

The findings of the first triennium of the Task Force were reported in (Williams et al. 1994) and (Bernus, Nemes and Williams, 1996). This report had two important messages:

1. The most important reference architectures in the field are those which describe the life-cycle of enterprises, because they help management to carry our enterprise integration programmes. For distinction these were called Reference Architecture of Type II. (While Type I Architectures being reference models of enterprise or of certain parts of enterprise).
2. A detailed investigation of three important architectures (Purdue Enterprise Reference Architecture, CIMOSA, and GRAI-GIM) was undertaken, and it was concluded that
   • None were complete at the time - in the sense that each had some important element not yet developed in the others;
   • It was desirable to develop a generalisation of life-cycle architectures, which does not compete with the exiting ones, but which describes or characterises them and can be utilised to guide the process of development and standardisation of reference architecture-related items.

It was expected that such a generalisation should be able to characterise, on the widest possible scale, all life cycle architectures in general, not only the three which were investigated in depth.

Second Triennium Developments: The First Version of GERAM and the Maturing of the Individual Enterprise Reference Architectures

The second triennium of the Task Force was devoted to the development of this Generalised Enterprise Reference Architecture and Methodology (GERAM) (Bernus, Nemes, 1994, 1996).

The major contributing groups developed reports to demonstrate how their own architectures covered the scope as defined at the time in GERAM.

These reports and the present state of GERAM have been reported at a special session of the IFAC World Congress in 1996.

The original version (Bernus, Nemes, 1994) had to be thoroughly discussed, extended and agreed on by active members he Task Force, which became the task of the third triennium.

ISO at this point appointed the Task Force as a Category A liaison and work began with ISO TC184/SC5/WG1 Industrial Automation Systems and Integration/ Architecture and Communications/ Modelling and Architecture.

Third triennium: Development of the Task Force Definition of GERAM (version 1.6.2) and the ISO WD15704 "Requirements for enterprise-reference architectures and methodologies" by TC184/SC5/WG1 jointly with the Task Force. Extension to any enterprise entity including products

As a result three developments happened simultaneously:

1. Each of the three reference architectures underwent a work of completion, or extension, to cover more of the scope as jointly defined in GERAM
2. Application of these architectures, using GERAM as an ordering principle. The Globeman 21 Consortium undertook an application in the large scale systems engineering which a) gave valuable experience of the applicability of GERAM to a complex 'virtua'l engineering enterprise, and b) resulted extensions to GERAM, in two areas:

   -- Recognition of the life-cycle life-history differentiation, allowing the representation of multiple change processes, and allowing the representation and characterisation of various methodolgies, according to their typical life-history patterns (such as top-down, bottom-up, inside-out, spiral, total re-engineering, incremental change - kaizen, concurrent engineering etc.);

   This development then allowed the common elements of these seemingly different approaches to be identified by their mapping on the common life-cycle dimension.

   -- Recognition of modelling language classes in the modelling framework, thus the GERAM modelling framework allowed to be populated with various sets of modelling languages, thus removing the prescriptive nature of GERAM in the area of enterprise modelling. This is represented in the GERA modelling framework of GERAM.

3. The Globeman consortium, consisting of over 40 companies and research institutions accepted GERAM as the common concept of this multi year project.
4. A concerted effort by active members of the Task Force was undertaken to
   • Develop the Task Force Definition of GERAM (as released in Version 1.6.2) with substantial contributions both in editing, writing and face to face discussions by active members of the Task Force and ISO TC184.SC5/WG1
   • Develop the ISO WD15704 "Requirements for enterprise-reference architectures and methodologies" which has GERAM 1.6.2. as an Annex.

Some major improvements took place, which are significant to this workshop. These include

• The definition of the nine components of GERAM and their role in managing the life cycle of any engineering entity or enterprise;
• The definition of Enterprise Entity Types, such that GERAM now covers the life cycle of any
  • manufactured, information or service products,
  • one of a kind, or repetitive enterprises,
  • incorporated or virtual enterprises or any other strategic management entities;
  • The demonstration of relationships among the life cycles of enterprise entities
  • The clear representation of the place of the human in the enterprise and the representation of the human organisation on equal footing with the other components of the enterprise

What GERAM Is and Isn't

GERAM allows management and technical personnel to identify the necessary elements, or capabilities to cover the life cycle of any enterprise entity.

GERAM does not contain any reference model as to what an enterprise (such as a company, or project) or other enterprise entity (such as complex engineering system, or a software, or an automotive product) should look like. GERAM defines (as inherited from CIMOSA) the concept of generic and partial models, which then are developed in the respective fields.

In terms of Enterprise Modelling GERAM allows the identification of areas of concern that need to be covered by enterprise modelling languages, but these areas of concern define classes of languages rather then one single language.

Therefore GERAM does not prescribe the actual selection of modelling languages, it leaves the identification of a relevant set of modelling languages to the enterprise engineering methodology geared to the engineering / enterprise engineering problem at hand.

GERAM can be utilised as a 'periodic table' of enterprise integration, providing an order of the complex list of constituents, identifying them, or identifying places which could, should, but are not yet covered by any known element.

In particular GERAM has at least the following two roles to play:

1. Use it as a road-map to define areas for research, for standards and for proprietary development in enterprise integration, including any engineering entity or enterprise;
2. Use it as a pattern for characterising existing architectures, their components and capabilities for easier comparison between these, ultimately with the benefit of being able to mix and match components.

GERAM allows all stakeholders to clearly view both the production and service delivery and the management and control portions of the enterprise. It also represents the place of the human as well as automated (hardware, software) resources and the relationships among these.

Finally, GERAM is meant to serve the purpose of harmonisation among various areas of enterprise integration and enterprise engineering.

The use of GERAM in systems and software engineering

The engineering of software and hardware systems has become a mature field and has its own reference architectures and reference models, which serve a useful purpose in today's practice.

Engineers have long recognised the need for reference architectures (both Type I and Type II) and developed these for specific areas. Also the history of hardware and software development is full with examples where problems arose because of the narrow consideration of the actual engineering object itself, instead of the system in the context, including the entire enterprise.

There is a certain reluctance on behalf of technical experts to go beyond their own field of expertise to tackle the context; One - because of the lack of authority to deal with the contextual elements, and Two - because of the skills needed for these elements are different from the skills needed to consider the technical part.

New enterprise integration methodologies may alleviate both of the above two problems: a) through methodological orchestration of involved technical and management personnel and all other stakeholders, and their co-operation, to create authority to decide upon each element - (from the point of view of systems engineering) technical or contextual; b) through the involvement of suitable skills and corresponding models, tools, etc. in the process of enterprise and systems engineering.

This tension allowed only slow progress in the area, adding to the scope of systems engineering only half hearteadly what was needed.

Obviously technically excellent solutions have been developed in the technically defined scopes of software engineering and hardware systems engineering, however the success rates of their applications was not as high as their technical excellence lead us to believe!

One of the reasons for the mixed result is the 'unknown component' which is not 'under control', including the human - organisational element, and the processes which are beyond these systems.

At the same time management science and enterprise integration has developed results which can take into account the full context, but obviously can not go to the level of detail necessary to make technical decisions in the respective systems engineering areas.

There is an opportunity to create a synergy by the combination of these elements, i.e. systems and software engineering methodologies, reference models, modelling facilities, etc. with enterprise integration methodologies, reference models, etc.

I expect that the Strategic Workshop should be able to identify the concrete opportunities, for example by proposing th edevelopment of joint standards in the area, or creating suitable adaptations of each others' standards to allow for their best fit.

References:

Bernus,P., Nemes,L. (1994, 1996) "A Framework to Define a Generic Enterprise Reference Architecture and Methodology," invited session ICARV'94, Singapore, November 1994 pp88-92. also Computer Integrated Manufacturing Systems 9(3) pp 179-191

Williams,T.J. Bernus,P., Brosvic,J., Chen,D., Doumeingts,G., Nemes,L., Nevins,J., Vallespir,B., Vlietstra,J., Zoetekouw (1994) ``Architectures for Integrating Manufacturing Activities and Enterprises,'' Computers in Industry Vol 24, No 2-3, Special Issue on CIM (1994) pp111-140.

P Bernus, L Nemes, T J Williams (Eds)(1996) Architectures for Enterprise Integration, Chapman and Hall, London (1996)
ISBN 04 12 731 401.

CIMOSA - Open System Architecture for CIM (1996) Technical Baseline; Version 3.2 CIMOSA Association, private publication

F.B. Vernadat, (1998) The CIMOSA Languages, in P.Bernus, K.Mertins and G.Schmidt, Handbook on Architectures of Information Systems, Springer-Verlag.. pp243-264

G.Doumeingts, B.Vallespir, D.Chen (1998) Decisional Modelling using the GRAI Grid, in P.Bernus, K.Mertins and G.Schmidt, Handbook on Architectures of Information Systems, Springer-Verlag. pp313-338

K.Kosanke, J,Nell (Eds) (1997) Proceedings of the International Conference on Enterprise Integration and Modelling Technology, Springer-Verlag

T.J. Williams and Hong Li (1995) 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, Research Report 159, Purdue Laboratory for Applied Industrial Control, November 1995, Version 1.1.

Williams, T.J. (1994) The Purdue Enterprise Reference Architecture, Computers in Industry, 24(2-3) pp 141-158