These are requirements
that any enterprise reference architecture and methodology
should satisfy. References
to strong features of example architectures are also given.
The overview is primarily based on
the analysis which was carried out by the IFIP/IFAC Task Force on
Enterprise Reference Architectures[1].
It is proposed that a published definition of the Generic Reference Architecture and Methodology should contain its own detailed requirements definition and design decisions. The following list can form the basis of this requirements definition.
It is necessary that all activities which are involved either directly or indirectly in designing and operating or improving the enterprise should be covered by the architecture. Given that the goal is to provide methodologies (not an architecture alone) the architecture should be the backbone of the methodology. Thus the architecture should be based on the modelling of the enterprise engineering process, or life-cycle.
A prominent example of this is the PERA [3] architecture which most fully captures the enterprise life-cycle.
The modelling views offered should cover a minimal set (such as in CIM-OSA or TOVE), but this set should be expandable with new related views. Modelling views should be based on a common theory, or meta-model, through which views can be related.
The ideal modelling environment should be modular so that alternative methodologies could be based on it. I.e., there should not be any prejudice built into the modelling languages as to what the methodology will be.
The modelling environment should be extensible rather than be a closed set of models, and permissive - leaving space for alternative modelling methods [4].
CIM-OSA (after adopting GRAI's modelling of the decision aspect) has created a consistent set of modelling tools (with a common meta-model) which can support an enterprise engineering methodology. Since the architecture also covers the operation of the enterprise the requirement is strongly connected with the functionality of information integration infrastructures.
Other suites of modelling methods also exist
(e.g. the IDEFX set of languages [9]).
The TOVE [5] system of generic enterprise models
also define a consistent set of modelling
classes (as an enterprise ontology).
The Generic Enterprise Modelling Language and Tool set
should amalgamate the advantages of these.
In addition to the methodology being technically correct it must be understandable and usable by the communities targeted. Thus the methodology should be executable by real (as opposed to hypothetical) teams, guaranteeing a high quality result within acceptable cost, time, and resource constraints.
The methodology should identify the application circumstances which must hold, with particular attention to the size and maturity of the enterprise wishing to apply it. ISO 9000 series of relevant quality standards should be treated as a guideline for the enterprise engineering process resulting from the methodology.
The GIM methodology [8] of GRAI has been demonstrated on numerous industrial projects as effective while the Purdue Implementation Procedures Manual [10] has the widest coverage.
The ideal Enterprise Engineering Methodology should also be expandable, since new engineering methods will always come into existence and the framework needs to anticipate and accommodate those developments.
It should be possible for the methodology to be presented both in a generic fashion and in specialised forms. These specialised forms could better serve particular areas of industry. The Generic Enterprise Engineering Methodology should allow an entire family of methodologies to be defined on its basis.
It is important that the apparent complexity of the enterprise engineering process should be kept low. Intricate details of models should be encapsulated in reusable building blocks.
Enterprise integration and enterprise engineering is a complex design process carried out by a group of people. As such, the methodology should ideally be based on a sound design theory treating design as a collaborative activity of multiple agents. Such theoretical basis is meant to ensure that the methodology is not only practical but also is formulated in a durable way.
The development of the enterprise can also be considered as only one of the activities in the enterprise. Thus the architecture should tie and relate enterprise integration and enterprise engineering to the rest of activities in the enterprise. Especially important is the wish to support evolutionary paths to enterprise integration, although revolutionary processes can (and should) not be excluded.
The Generic Enterprise Reference Architecture and Methodology must clearly define how other efforts to integration relate to it. The architecture should make it simpler to grasp integration than it was before.
It is permissible, indeed desirable, to have multiple presentations of the architecture to facilitate understanding and acceptance by a variety of user and developer groups and to ease identification with it.
The SATT methodology [4] developed a recursive view of enterprise architecture where the end product of one architecture is the process creating the second. Using this principle the complexity of the methodology can be tackled by applying the reference architecture and methodology to its own development! The present article attempts to start this by a presentation that follows the anticipated architectural design.
The above list of requirements can be completed and organised
as functional, information, organisational, resource requirements, etc.
.