Note that the lifecycles referred to here are all of a virtual design nature, i.e., not descriptive of the time- based order of events (relating to the discussion on a entity‟s life history – Section 1.3.1.2). Any initiative that is newly undertaken, in progress or nearing finalisation, may be mapped onto the Innovation Solution Space. At any given time (although time is not depicted in the three dimensional space), an initiative may be described in terms of the Enterprise-, Technology-, and Product Lifecycles. Note that progress does not necessarily propagate linearly along the axes as lifecycles are of a virtual nature. A planned progression may be plotted in the solution space for a proposed initiative, highlighting the necessary convergences in terms of the enterprise, its products and technologies. Thus, this approach may be used as a mechanism for planning and controlling the coordination of enterprise entities during the executing of an initiative.
It is clear that the Innovation Solution Space stimulates greater understanding for the interrelatedness of the three lifecycles and for the management thereof. For this reason, and for its ability to visually describe the relations between the Enterprise-, Product-, and Technology Lifecycles, this concept has been discussed.
Tec hn ol og y Li fe cy cl e Product Lifecycle Innovation Project
1.3.3 The generic nature of the lifecycle
According to Williams et al. (1998), “any entity that experiences a change in state, exhibits a lifecycle that is comparable with others and independent of both content and detail”. Van der Ven and Poole (1995) are of the same opinion. This independence of content and detail renders the lifecycle a generic tool for comparing different entities that exhibit a change in state and provides a fundamental basis from which to view and evaluate organisational activities and the methodologies tasked with guiding and improving those activities. This nature of the lifecycle will prove vital for the furtherance of this thesis (see Chapter 2).
1.3.4 Enterprise Reference Architectures
An architecture is a means of describing the structure or framework of a system, showing the interrelationships of all parts and/or functions of that system (Bernus, Nemes and Williams 1996).
A reference architecture is a collection of the generic parts, functions, descriptions, or behaviours of a system and the associated structures or frameworks (Bernus et al., 1996). It serves as an intellectual paradigm, facilitating the accurate analysis, discussion, and specification of a given area of discourse, i.e., a manner of viewing, conceiving, and discussing a matter of concern (Vernadat, 1996).
Finally, an Enterprise Reference Architecture is defined as:
… the body of classified knowledge for designing, building, operating, and modeling enterprises. The architecture contains guidelines and rules for the representation of the enterprise framework, systems, organisation, resources, products, and processes.
Bernus et al. 1996
The different levels of aggregation and the varied scope of application of an enterprise engineering effort requires the definition of 3 types of Enterprise Reference Architecture, each pertaining to a different level of functional applicability. They are (Williams and Li 1998):
Type 1 – Specific implementations in a specific industry at a specific lifecycle phase.
Type 2 – Generic Models, applying to all industries and enterprise lifecycle phases.
Type 3 – Partial Models, applying to a few industries and/or enterprise lifecycle phases.
Of the abovementioned types, only Type 2 architectures provide the generic approach necessary for this project. Type 2 models include: GRAI-GIM (GRAI Integrated Methodology), GERAM (Generalised Enterprise Reference Architecture and Methodology) and PERA (Purdue Enterprise Reference Architecture). Of these models, PERA is the most generic in the sense that it provides a lifecycle-based framework for enterprise design without prescribing specific tools, techniques and methodologies for each of the specific lifecycle phases. The PERA user is thus free to utilise those tools with which the enterprise is familiar and in which it is competent. PERA is, thereof, the preferred Enterprise Reference Architecture for this dissertation.
PERA was developed by the Institute of Interdisciplinary Engineering Science, Purdue University. An extension of this architecture, known simply as the Extended PERA, is the specific model for application in this project. This adapted reference architecture, developed by the GCC (Global Centre for Competitiveness) at Stellenbosch University, provides a straightforward yet comprehensive, lifecycle-based approach to enterprise design.
1.3.4.1
Purdue Enterprise Reference Architecture (PERA)
Because PERA is a Type 2 reference architecture, it is suitable as a reference framework for modelling any enterprise (Williams and Li 1998). It depicts the steps and structure necessary for the analysis, design and development of an enterprise integration initiative (Williams et al. 1996). The structure is lifecycle based and incorporates the necessary lifecycle concepts inherent in any developing enterprise-related entity. PERA describes the following three major components (sub-architectures) to be the basis of any enterprise (Williams and Li 1998)
:
Manufacturing Equipment Architecture – equipment performing physical manufacturing functions or tasks.
Information Systems Architecture – equipment performing information functions or tasks.
Organisation and Human Architecture – human execution of functions or tasks in either or both cases.
The Extended PERA furthers on these components to include a fourth, namely: the Decision Architecture – pertaining to decision-making protocol (Katz 2005). The concepts of the Manufacturing Equipment Architecture are also applicable to the creation of intangible products, i.e. services, in the Extended PERA.
The lifecycle phases of the architecture are: concept, function analysis, implementation, operation, and recycle and disposal. These are similar to those mentioned in Section 1.3.1 (GERAM), with only slight differences at certain phases. For example, Implementation in PERA includes the detailed design activities, which is separate in the case of GERAM. Figure 12 provides a graphical representation of the Extended PERA.