Issue #10 [April 24-April 28, 2006]
Enterprise Reference Architecture Framework
So far we have got a clear understanding of the matrix nature of the enterprise. We have acknowledged enterprise as a complex adaptive system. As a complex adaptive system enterprise organisations must be able to respond to a multi-dimensional formidable array of challenges to survive within this adaptive ecology. Today’s enterprise leaders are scratching their hair in an attempt to survive the emergence nature of the enterprise, maintain the requisite variety of nested systems in a sub-optimal level with the right level of iterative co-evolution. One of the most important challenges is to manage on the edge of chaos of ever changing new business models and unpredictable nature of customer demand. On the other hand enterprise is still struggling to find out a simple equation between outsourcing, service oriented digitalised globalisation, international competition, mergers & acquisitions of companies, technological innovation and information exchange flow. This complex adaptive system needs a complete solution to meet the challenges and create enterprise architecture with the recommendation of enterprise architecture framework, which in turn is created under the foundational recommendation of reference architecture.
Introduction
So far we have got a clear understanding of the matrix nature of the enterprise. We have acknowledged enterprise as a complex adaptive system. As a complex adaptive system enterprise organisations must be able to respond to a multi-dimensional formidable array of challenges to survive within this adaptive ecology. Today’s enterprise leaders are scratching their hair in an attempt to survive the emergence nature of the enterprise, maintain the requisite variety of nested systems in a sub-optimal level with the right level of iterative co-evolution. One of the most important challenges is to manage on the edge of chaos of ever changing new business models and unpredictable nature of customer demand. On the other hand enterprise is still struggling to find out a simple equation between outsourcing, service oriented digitalised globalisation, international competition, mergers & acquisitions of companies, technological innovation and information exchange flow. This complex adaptive system needs a complete solution to meet the challenges and create enterprise architecture with the recommendation of enterprise architecture framework, which in turn is created under the foundational recommendation of reference architecture.
Enterprise Architectural Framework Stack
It is a common symptom across the industry to use concept of permutation and combination with two different terms “Enterprise” and “Architecture” concatenated with the other terms like “Information”, “Technology”, “Business”, “Information” and so on interchangeably. Moreover, another very common tendency among the people is use “Enterprise Reference Architecture Framework”, “Enterprise Architecture Framework”, “Enterprise Classification Framework “ and “Enterprise Architecture” synonymously, which is completely incorrect. However, if we try to find the reason behind this incorrect perception, we will probably be able to find a common answer that different leaders, evangelists and authors have successfully made us believe this incorrect perception. Following diagram will give you very high level characteristics of the enterprise architectural framework stack members:
In our next few week discussions we will try to give you a clear picture to resolve your enterprise puzzles.
Generalised Enterprise Reference Architecture and Methodology (GERAM)
Well-planned enterprise architecture ensures all possible business benefits through technology innovation. Moreover the use of established reference architecture as a framework for the process descriptions provides several demonstrable benefits. Organisations embracing changes on their strategic plan usually prefer to use one of the available reference architectures to speed up implementation and take advantage of collated best practices. However, “GERAM is not yet-another-proposal for enterprise reference architecture, but is meant to organise existing enterprise integration knowledge. The framework has the potential for application to all types of enterprise. Previously published reference architectures can keep their own identity, while identifying through GERAM they overlap and complement benefits compared to others” [GERAM].
GERAM / ISO IS 15704: 2000 provides a generalised set of recommendations which may be considered as common baseline requirements that constitute enterprise architecture and engineering. Such a baseline allows enterprises and architects to assess various candidate reference architectures and choose the most appropriate one based on their specific business needs. This makes the rationale for choosing a specific architecture reasonable and rational. “The main aim of Generalised Enterprise Reference Architecture and Methodology is to generalise the contributions of various existing and emerging Enterprise Architecture Frameworks and Enterprise Reference Architecture in order to define a complete collection of tools, methods, and models to be employed by any enterprise engineering and integration effort. As such, GERAM assists in the choice of tools and methodologies by providing criteria that needs to be satisfied rather than trying to enforce particular options. Used as a generalisation of frameworks, GERAM may also assist in establishing the completeness and suitability of frameworks proposed to form the basis to a particular change process.” [Ovidu Noran].
The following diagram represents GERAM recommendations:
Table 1 briefly describes each of the elements of GERAM [GERAM]:
GERA Enterprise Life Cycle Aspect
GERA defines seven life-cycle activities (refer figure 3) for any enterprise or any of its entities that are pertinent during the life of the entity. These activities may be subdivided further into several lower level types of activities (based on the customary subdivision in many industries of design into preliminary- and detailed design activities). The life-cycle diagram used in the description of the life-cycle of an entity is itself a model of the enterprise engineering methodology.
Table 2 summarizes the seven life-cycle steps of recommended by GERAM:
In reality all these steps may be evolved in an iterative way. All these life-cycle steps are really very crucial for any entity. Therefore, any enterprise process should be able to support us with all the GERAM recommended steps.
GERA Life History Aspects: The Timeline Aspect of Methodologies
Life history is the actual sequence of steps (also known as activity types), an entity that evolves over its lifetime. Any enterprise entity has its own history that captures the main events, or milestones in the life of the entity. Change processes that may happen simultaneously and may need to be captured as parts of the operational processes are inevitable within the history of an entity. Figure 1 shows the life history aspect of an entity within the enterprise, life history representing a simple case with a total of seven processes: three engineering processes (in blue colour), three operational processes (in green colour), and one decommissioning process (in red colour).
One entity may go through several events based behavioral states to perform its functionality during its entire life history.
Enterprise deals with the cross-system issues more occasionally which are not easy to capture with enterprise life cycle only. The critical difference between life cycle phases and timeline aspect is that the evolution of the enterprise entity through time is not covered in the life cycle phases. Life history of any entity describes its evolution and adaptability towards any change in business environment. This demonstrates that any event in the life history of the entity may affect the life history state of other entities which may be described as follows in figure 2. This life history diagram points to the need for managing systems and projects at an enterprise level. One entity may go through several events based behavioral states to perform its functionality during its entire life history. Each of the cells may be updated with the value C (Create), R (Retrieve), U (Update) or D (Delete).
Enterprise Modeling with Integrated Model Representation and Model Views
GERA divides enterprise into multiple views to reduce model complexity and cover the viewpoints of different stakeholders. GERA identifies the following model views:
- Model Content Views: Function, Information, Resource, Organization
- Purpose Views: Customer Service, Management & Control
- Implementation Views: Human (Manual) and Machine (Automated Tasks)
- Physical Manifestation Views: Software, Hardware
The Primary focus of Model Content Views is user oriented process representation of enterprise entities whereas Physical Manifestation Views addresses software and hardware. On the other hand Entity Implementation Views distinguishes between automated task and task needed manual intervention. Purpose Views with focus on mission of the enterprise entity and products & services need to support enterprise objectives.
Enterprise Entity Types
As already mentioned GERAM prefers identifying entity as an essential activity in enterprise life-cycle and relationship between them. An entity is a logical/virtual organisation, which could be a department, division or an entire organisation, with a life history (Refer to Y-axis in figure 2). This entity classification helps any organisation build up more structured enterprise foundations. GERA introduces the concept of five most important entity types as follows:
- Strategic enterprise management entity
- Enterprise engineering entity
- Enterprise entity
- Product entity
- Methodology entity
GERA also identifies the concept of Recursivity of entity types, where Recursivity is defined as the direct and active influence of one entity in the development of another entity.
So far we have described GERA and its process oriented concepts applicable to all enterprises. As mentioned earlier, the main objective of this paper is to provide enterprise decision makers, architects and engineers revisiting the enterprise viewpoints, with an understanding of GERA specified recommendations. This foundation knowledge would further help us assessing any enterprise frameworks to justify whether it is adequately equipped with all necessary enterprise recommendations. Following diagram represents the master key of this modern enterprise, which enable us to build the GERAM recommendation based enterprise architecture framework to successfully build the enterprise operational systems:
Conclusion
Now we have identified the required elements of any enterprise reference architecture framework. We have also understood the enterprise architecture framework stack. With these all knowledge bases we are now ready to set on a new journey plan to reveal the unfold mystery of Enterprise Architecture Classification Frameworks, Enterprise Architecture, Master Plan and Finally Model Driven Enterprise.
References
- GERAM: Generalised Enterprise Reference Architecture and Methodology. Version 1.6.3 Also in P.Bernus, L.Nemes and G. Schmidt (Eds) Handbook on Enterprise Architecture, Berlin : Springer (2003) pp 22-64: http://www.cit.gu.edu.au/~bernus/taskforce/geram
- [GERAM] GERAM: Generalised Enterprise Reference Architecture and Methodology. Version 1.6.3 ( http://www.cit.gu.edu.au/~bernus/taskforce/geram ) also in P.Bernus, L.Nemes and G. Schmidt (Eds) Handbook on Enterprise Architecture, Berlin : Springer (2003) pp 22-64.
- PERA AND GERAM--ENTERPRISE REFERENCE ARCHITECTURES IN ENTERPRISE INTEGRATION by Theodore J. Williams, Institute for Interdisciplinary Engineering Studies, Purdue University and and Hong Li, Senior Consultant, Claremont Technology Group, Inc
- [GERAM Report 1995] A SPECIFICATION AND STATEMENT OF REQUIREMENTS FOR GERAM by THEODORE J. WILLIAMS and HONG LI, November 1995
- [PERA] A HANDBOOK ON MASTER PLANNING AND IMPLEMENTATION FOR ENTERPRISE INTEGRATION PROGRAMS Based On The Purdue Enterprise Reference Architecture and the Purdue Methodology Purdue Laboratory for Applied Industrial Control Edited by Theodore J. Williams, Gary A. Rathwell, Hong Li. February 2001 (Revised from July 1999 PERA website version)
- http://www.pera.net/Pera/Wha_mast.html
