Inputs into Joint Meeting of ISO TC 184/SC5/WG1 and the IFAC/IFIP Task Force on Enterprise Integration - Paris, May 1998

Section 1: A Potential Future Activity of the IFAC/IFIP Task Force and ISO TC 184/SC5/WG1

R. H. Weston, J. D. Gascoigne and P. J. Gilders

Following preliminary discussion at Boulder this document seeks to lay groundwork for possible work items of the Task Force and SC5/WG1 on “capturing enterprise engineering requirements in support of the development of component-based systems”.

The case made is based on the following assumptions:

  1. Vested within the Task Force and SC5/WG1 is a ‘state-of-the-art’ understanding of general enterprise engineering requirements which can be developed and applied in more focussed ways. Much of this knowledge is embedded into the GERAM specification and its pre-existing reference methods and architectures, namely PERA, CIMOSA, GRAI and TOVE;
  2. Fuelled by developments in distributed systems design and construction, emerging software paradigms (including component-based software engineering paradigms) are projected to impact significantly on the development of next generation agile enterprises. It is widely reported that industry wishes to move towards distributed problem solving software environments which facilitate innovative and collaborating decision making rather than continue to use hand-crafted, stand-alone software applications which mitigate against organisational, process and technological change. Industrial enterprises need to perform in a stable, effective and scalable way in complex and changing environments. Apparently component-based systems engineering paradigms offer a means of realising targeted incremental change to enterprise systems.

To meet general requirements expressed under 2, the concepts and techniques deployed within emerging component-based software engineering paradigms must be developed and applied more generally as an integral part of component-based enterprise systems engineering paradigms.

Implicitly this will require ‘descriptions’ of

  • components (i.e. common and specialised software, machines and computer supported human system elements used in manufacturing enterprises)
  • architectures (e.g. frameworks, structures, infrastructures and controls used to structure the behaviour of groupings of components)
  • methods (e.g. procedures and associated rules which govern the way in which component-based systems are conceived, engineered and developed)

Despite an evident desire for there not to be so, there remains a significant gap between concepts and techniques advanced by the Enterprise Modelling and Integration (EM&I) community and those used by Software Paradigm Developers (SPD). Some may view many EM&I concepts as being top-down, ‘pie-in-the-sky’, others may view much of contemporary SPD to be directionless, bottom-up, ‘reinventing of the wheel’. Obviously however both views are important and should be consistent with each other. Arguably any significant and generally useful development of either view can only be realised in the light of understanding the other view.

Logically it follows that the ‘guardians’ of the EA&I view (namely ISO 184/SC5/WG1 and the IFAC/IFIP Task Force on Enterprise Integration) should, based on their work leading to GERAM, seek to develop and document a consensus view of enterprise engineering requirements for software paradigms, in particular component-based systems. The quid pro quo is that the guardians of the SPD view should also (possibly in parallel) develop multi-business and users views of what can be achieved by deploying alternative component-based paradigms. Also the SPD community should question and develop any EM&I position in the light of the capabilities of new enabling paradigms. Naturally the development of an EM&I consensus view of component-based enterprise system engineering requirements will require a focussed reassessment of the coverage of GERAM and its pre-existing architectural and methodological specifications. Initially it will also require key inputs from developers of the SPD view.

Bearing in mind the arguments outlined above, the authors produced section 2 of this document as an ‘Aunt Sally’ line of thinking which ‘connect’ enterprise engineering requirements to emergent properties of component-based systems. It does not represent views of other WG1 and Task Force members at this stage. Rather at this stage it is recommended that other complementary lines of thinking are developed leading towards a plan of how the joint working group might develop an agreed specification of component-based enterprise engineering system requirements.

Therefore the ‘Aunt Sally’ reported in section 2 should be seen as no more than one starting point for discussion. Sincere apologies are offered in respect to its voluminous (and at times rather parochial) nature. The authors and their fellow researchers in the MSI Research Institute include proponents of both EM&I and SPD views. Individuals in MSI have developed their own perspectives on such matters by applying, evaluating and developing the use of state-of-the-art concepts from both EM&I and SPD perspectives. By no means is it claimed that individual views have been developed into a consistent description of the problems and issues involved. However, section 2 has contents that are sufficiently neutral that apparently it does not overly upset any individual in MSI. Furthermore material included in section 2, thus far does not attempt to map current methods, frameworks, constructs and tools onto the component-based system requirements described in outline. Therefore no attempt is made to credit others (and particularly other WG and Task Force members) with known solutions to requirements. Where solutions are mentioned they are merely indicative of the type of problems involved.

It may be appropriate to point out certain ‘undertones’ (i.e. matters not explicitly mentioned in section 2) which are the issue of ‘prejudices’ held by the first author, namely his belief that

GERAM (and its predecessor frames and methods) are excellent in concept, and provide the most complete public domain documentation on EM&I issues, but with respect to their provision of a context for shaping component-based paradigms:

a)their scope requires extension to adequately cover issues connected with the engineering of business systems (as defined in section 2).

b)their current concepts and ‘interfaces’, which relate to software engineering paradigms, require more explicit definition.

c)their concepts and ‘interfaces’ related to the design, realisation and development of social systems requires advancement.

d)their concepts on resource and components models require development.

e)that without appropriate toolsets and reference models focussed on well defined requirements their use will remain limited.

Therefore the implied position taken when developing section 2 was that Task Force members are the guardians of the EM&I but that to provide a requirements specification for next generation software paradigms (including component-based systems) which would add value to industry at large they must

apply GERAM selectively and with empathy for the work of the developers
of component-based paradigms.

Recommendation

The joint meeting is invited to consider whether: (a) it sees the development of guides for developers of component-based paradigms as a useful and important role for it to assume; (b) if the answer to (a) is ‘yes’ , to consider how it might develop such guides and whether the ‘Aunt Sally’ decomposition developed in section 2 has a role to play; and (c) to assess and justify (or to decide how to assess and justify) what if any standards might be needed by industry to complement that development.

Inputs into Joint Meeting of ISO TC 184/SC5/WG1 and the IFAC/IFIP Task Force on Enterprise Integration - Paris, May 1998

Section 2: Enterprise Engineering Requirements Capture in Support of the Development of Component-Based Systems

R. H. Weston, J. D. Gascoigne and P. J. Gilders

PREAMBLE

This section of the document seeks to flesh out a coherent view of the future role of component based enterprise systems in developing reconfigurable business processes capable of operating competitively in complex and uncertain environments.

If WG1 and the Task Force so decide fragments of this paper could be developed as the basis of a case for a new mandate from ISO TC 184/SC5 aimed at capturing generic enterprise engineering requirements that can guide the ongoing development of component-based systems.

1.0 ENTERPRISE ENGINEERING IN SUPPORT OF THE ‘AGILE’ ENTERPRISE

Generally, industrial and commercial enterprises operate within complex environments that change frequently as a result of political, economic, social and technical (PEST) influences. Therefore an enterprise with a capability to manage change rapidly and effectively will have a competitive edge over others that do not. It follows that change management may be a key business process in many companies.

Enterprise Engineering is concerned with change management on a large scale. Its theories and supporting techniques recognise that the human brain is not capable of fully assimilating the levels of complexity typically involved. Consequently, contemporary enterprise engineering approaches use abstractions of the enterprise at a number of levels. Abstraction processes typically involve generalisation of information and therefore effectively valuable information may be lost if reference is only made to a single abstraction (or view of the enterprise). Therefore a good enterprise engineering approach will minimise any effect of information loss, by making good and consistent sets of abstractions that allow effective and timely decisions to be made by the various personnel responsible for managing change.

Normally an enterprise will have multi-purposes and multiple goals. Therefore different parts of the business are likely to operate under different environmental conditions, and are subject to different PEST influences. As these influences will change irregularly and unpredictably it follows that even if it were possible to determine and describe an ideal enterprise configuration this would have to be (1) a compromise configuration (with respect to different needs of its multi-purposes) and (2) modified continuously and possibly at a greater rate than could practically be followed by any change management business process. Indeed the change management process is further complicated by the fact that a change at one level of abstraction in an enterprise is likely to have knock-on effects at the same and other levels. Hence many personnel in an enterprise could be affected by a change and thereby may need to contribute to a related change initiative (i.e. an instance of the change management business process). Also it may be necessary to handle change at each level at a different frequency, implying the need for any change initiative to have a well-defined timeframe at each abstraction level. This re-emphasises the point that there will not be a single optimum enterprise configuration under conditions where environmental change cannot be predicted.

We conclude that no optimum enterprise configuration can exist and, as a consequence, that responses to changing requirements must be restricted and imperfect.

None the less, if properly applied enterprise engineering theories and techniques can help to (a) define compromise enterprise solutions (which may focus on particular initiatives that generate a high yield) and requirements for change at different levels by making good abstractions; (b) structure and co-ordinate change initiatives, and (c) facilitate the reuse of knowledge and information (in support of decisions made about change) so that better and faster change management can lead to improved environmental responses and thereby competitive behaviour.

Based on the above we can infer necessary attributes of an agile enterprise capable of responding competitively (i.e. rapidly and effectively) to changing conditions.

2.0 CHANGE AT DIFFERENT SYSTEM LEVELS

Figure 1 is a generalisation of levels of abstraction commonly embedded into public domain enterprise engineering frameworks and proprietary management consultancy methods. This system decomposition is not intended to be a definitive classification which assumes that all enterprises have systems which correspond neatly to the system levels depicted. It is based on the following assumptions.

1)There are real resources such as buildings, people, machines, software, money, energy, roads, etc. which can be deployed to build enterprises. People, machines and software resources can carry out the activities required to achieve the multi purposes of an enterprise. They can be hired, fired, acquired, installed, etc. and be assigned different roles and responsibilities. They are supplied by educational systems, machine builders and software companies as unitary component building blocks of operational systems. They may be large-grained, complex building blocks that may be considered to constitute a system (in this case a resource system)in their own right.

Figure 1:

2)Typically, operational systems meet process requirements by organising, planning, scheduling, co-ordinating, controlling and monitoring some collective application of a group of resources. Operational systems are themselves real resources, in as much that they comprise software, people or machines which organise, plan, schedule, co-ordinate, control or monitor ‘lower level’ people, machines and software resources. It follows that there may be a fuzzy dividing line between system levels as a particular operating system can be a resource system and vice versa. However, generally, operational systems will be distinguished by their need to be application specific, i.e. their operational behaviours should be continuously aligned to specific process requirements of an enterprise which change predictably (with planned job and product changes) or unpredictably (such as in response to environmental change). Commonly unitary resources are more generally applicable and enable ‘vendors’ to supply them into many different enterprise configurations and/or types of enterprise. It is known that significant change management constraints arise if operational systems are designed, implemented and changed in an ad hoc and/or proprietary way by external suppliers. High cost overheads and/or ineffective operational systems may result if responsibilities for the life-cycle engineering of operational systems are inappropriately assigned to internal business units.

3)A process system is a theoretical abstraction designed to represent a thread of value adding activities. These abstractions help to communicate business and production requirements in a meaningful and efficient way between the personnel concerned with that process. It is reported that typically the business purposes of an enterprise can be represented meaningfully by up to ten business process descriptions. Formal models of business processes and models of their interactions can facilitate analysis about the impact of possible changes on the performance of an enterprise. If this modelling is achieved with reference to a suitable enterprise engineering framework it can facilitate collective decision making and thereby the enactment of changes. If such an approach to change management is to be enabled on an ongoing basis it will be necessary to maintain consistency between theoretical descriptions of process systems and the operational systems and resource systems those descriptions represent. Appropriate organisation structures will also need to be used to ensure that conflicting requirements of business processes (and thence of the different business purposes) of an enterprise can be resolved. Hence these structures should enable different process systems to share operational systems and resource systems as required, and thereby to achieve effective but harmonious realisation of the business objectives and mission of the enterprise. Importantly, however, this organisation structure should not place unnecessary constraints on the change management process. Indeed it should promote innovation and knowledge acquisition.

4)The business system should frequently reassess the purposes of an enterprise in the light of changing environmental circumstances. It should therefore be concerned with strategic issues, seeking answers to questions like what should the enterprise be doing to be more competitive? It follows that the business system should generate the vision, strategy, business objectives and operating principles for the enterprise so as to maintain its viability and vitality.

Table 1 illustrates typical characteristics of each system level described above.

SYSTEM LEVEL / SCOPE / CHANGE FREQUENCY / INFORMATION CHARACTERISTICS / OUTPUT
Business System / Assessment of the business within its environment / Yearly / High level, aggregated and uncertain / Vision, mission, strategy, business objectives and principles.
Process System / Assessment of processes to support the business purposes and their requirements / 6 monthly / High level data – more precise specification of current processes / Description of process requirements (metrics) and their high level relationships
Operational System / Assessment of operational improvements needed / Monthly / Detailed operational performance data and operational rules. / Description of operational rules used to control and monitor processes.
Resource System / Assessment of the resources required / Weekly / Particular resource information and performance figures. / Description of resources (components) which are used to control or execute processes.

Table 1: System level characteristics

It is evident that the topmost two system levels in Figure 1and Table 1do not really exist. Rather they are models stored and processed in people’s heads, on paper or by a computer modelling facility. As such they allow those concerned with the life-cycle engineering of systems to develop and use complex abstract concepts to make decisions. The development and use of these virtual systems supports the generation and definition of what will be referred to in the rest of this document as a business solution. The business solution will be viewed as being the compromise enterprise configuration referred to earlier. The bottom two system levels are concerned with a physical manifestation of the business solution. Collectively they will be referred to as the physical solution. Clearly it will be possible to achieve the business solution in many ways using different physical solutions. However whatever physical operational systems and resource systems are deployed, if change management is to be achieved on a continuous (and possibly incremental) basis consistency must be maintained between corresponding virtual (business) and real (physical) solutions.

Many enterprise engineering activities involved in business solution development are naturally centred on the use of a process oriented approach to problem decomposition whereas commonly physical solution development is centred on the use of a function-based approach to decomposition. This reflects generic differences between requirements and aspirations of users of enterprise systems (possibly expressed as a set of abstract business and process systems)and those of their suppliers (of real operational and resource systems).

Evidently a focus on one or more business processes of an enterprise can improve the way in which groups of humans make decisions about an enterprise, such as: how can the enterprise respond to a new opportunity? how can it reposition itself in an established market? how can it focus on and develop its core competances? how can it improve its resource allocation processes? how can it change its human and IT systems to improve its responsiveness, improve product quality, reduce overheads costs, etc.? what cultural changes are required? should it develop new partnerships and customer supplier relationships? etc. Therefore a process-oriented approach to problem decomposition provides a basis for analytic enquiry and co-ordinated decision making which is better suited to user needs than is a traditional function-based decomposition approach.