Issue #8 [April 10-April 14, 2006]
Enterprise Architecture Apocalypse
Through the last few editions of MDA Radar, we journeyed across some of the major parts of MDA. Now that we have an idea about the promise of MDA and how enterprises can benefit from it, we will spend the next few weeks focusing on enterprise architecture. Our main objective is to suggest a model driven enterprise classification framework within the enterprise architecture context and solve some important puzzles of this enterprise Rubik cube.
Introduction
Through the last few editions of MDA Radar, we journeyed across some of the major parts of MDA. Now that we have an idea about the promise of MDA and how enterprises can benefit from it, we will spend the next few weeks focusing on enterprise architecture. Our main objective is to suggest a model driven enterprise classification framework within the enterprise architecture context and solve some important puzzles of this enterprise Rubik cube.
Enterprise Architecture is the art of creating an architectural foundation of loosely coupled collaborative communication between all participant components and modules within the enterprise. Model Driven Architecture is one of the approaches to derive a platform-independent modeling solution that approaches this iterative, dynamically evolving, scalable and interoperable enterprise problem of domain abstraction.
Through this new journey to the centre of the matrix enterprise architecture we will revisit our enterprise concepts from a slightly different point of view where in enterprises could be visualized as a modular matrix. In this week’s edition, we will set our objective to understand the nature of the enterprise, its master plan & vision, enterprise architecture, types of enterprise architectures and create a model driven enterprise classification framework.
Matrix Enterprise
In the current IT consulting age, people widely misinterpret the term 'Enterprise' and use the term in the way consulting works. People sometimes differentiate by using the term 'academic' to avoid the actual fact; however it is really not easy to define "Enterprise" in a simplistic way. I prefer the way GERAM introduces "Enterprise Engineering", which identifies some of its specific characteristics. Enterprise Engineering is a state-of-the art discipline, which can be defined, as "One of the most important characteristics of today's enterprises is that they are facing a rapidly changing environment and can no longer make predictable long term provisions. To adapt to this change enterprises themselves need to evolve and be reactive so that change and adaptation should be a natural dynamic state rather then something occasionally forced onto the enterprise. This necessitates the integration of the enterprise operation and the development of a discipline that organises all knowledge that is needed to identify the need for change in enterprises and to carry out that change expediently and professionally. This discipline is called Enterprise Engineering". [GERAM]
"A good definition of "enterprise" in this context is any collection of organizations that has a common set of goals and/or a single bottom line. In that sense, an enterprise can be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership." [TOGAF]
With the advancement of global economies, enterprises are extending and expanding organically, and as a result there is a big confusion in understanding the evolving nature of the term "enterprise". Enterprise includes partners, suppliers and customers as an extension to the family, collectively working as a large collaborative autonomous unit. Enterprise works as a complex network or as a chain in a collaborative environment.
However, enterprise is not limited to selling or offering services or products. Sometimes a product itself may act as an enterprise. Enterprise also follows natural laws and therefore without any exception it obeys Darwin’s “survival of the fittest" rule and its continuous metamorphosis process, causing an evolution of the agile enterprise.
Every program of enterprise system engineering or architecture development should initiate with a proper plan that outlines the long term business objectives including an ROI plan, project scope, deliverables, different risk factors, and timelines and so on. "Once the integration of all of the informational and customer product and service functions of an enterprise have been properly planned (the Master Plan), the actual implementation of such an integration may be broken into a series of coordinated projects." [PERA]
Enterprise Reference Architecture versus Enterprise Architecture
There are primarily three different types of Enterprise Reference Architecture, also known as Enterprise Architecture Framework, as shown below:
- Type 1: Specific Implementations in a specific industry at a specific phase
- Type 2: Generic Models, which apply to all Industries and enterprise phases
- Type 3: Partial Models, which apply to a few industries and/or enterprise phases
All three can provide appropriate guidelines to design or revamp an enterprise; however, only Type 2 (GERAM) provides a generalized model, which can be applied to all industries during all phases.
Type 1 - Enterprise Architectures & Models - Specific Implementations
This type of architecture can be summed up as very specific or as a concrete tactical implementation by the individual enterprises at a particular point of time. This type of enterprise architecture is the output of implementation of Generic Reference Architecture Framework.
In the case of Type 1 architecture, it is completely requirement driven and is mostly developed on the foundation of different functional concerns of involved stakeholders. Therefore each implementation produces a significantly different piece of architecture. However, there may be considerable commonality between similar applications in different industries or domains as a result of best practice and patterns based consideration. Domain models are the best examples of Type 1.
Type 2 - Generic Enterprise Reference Architectures & Model
These types of architectures are actually referred to as frameworks, which could be reused to define a specific enterprise architectures e.g. Type 1. GERAM is Type 2 enterprise reference architecture. These types of enterprise architectures provide guidelines with the objective to unify all these enterprise activities within a guided environment. GERAM defines the following process oriented concepts:
- Enterprise entity life cycle
- Enterprise life history: The timeline aspect of enterprise architecture
- Enterprise Methodology
- Enterprise entity types
- Enterprise modelling with integrated model representation, and Enterprise model views
Moreover GERA has introduced three important enterprise influencers:
- Human-oriented concepts
- Process oriented concepts
- Technology-oriented concepts
Type 3 - Partial Reference Architectures & Model
These Type 3 enterprise architectures are mostly a result of industry/Domain specific implementation of specific problems or implementation for specific phases of the Enterprise life cycle. Examples might include designing of security systems for a banking domain, Credit Card validation for online transaction, and so on.
Unfortunately numerous enterprise architect evangelists make us believe the existence of different enterprise architectures, which are in reality either type 1 or type 3. They have also injected the drug so that we are not in a position to differentiate between enterprise classification framework and enterprise architecture framework; we don’t distinguish between frameworks and implementation architecture, and so we have created a different hype-based enterprise architecture called SOA (Service oriented architecture). One of the other objectives of this enterprise apocalypse is the purification of our hype blood. “The ancient parable of the group of blind Indian philosophers who attempted to describe an elephant after each had felt only different separate parts, certainly applies here – Each of the proposed architectures is describing the same subject but from widely varied, and very incomplete viewpoints. Thus, the descriptions appear to be very different.” [GERAM Report 1995]. Our other objective is to clear up all these blindness in the next few weeks.
Enterprise: The Master Plan and Vision
To define enterprise architecture, we must not forget some of the great research that turned into the formation of a solid foundation of present agile enterprises. In fact, a brief summary of this research will really help us to properly understand the enterprise architecture. Previous research carried out by the AMICE Consortium on CIMOSA [CIMOSA], by the GRAI Laboratory on GRAI and GIM [GIM], and by the Purdue Consortium on PERA [PERA] is pioneering in nature and collectively produced a foundation of enterprise reference architectures. Each of these architectures had their own unique offering with their own pros and cons. For instance, CIMOSA viewed enterprise as one or more domain processes and/or business processes. GRAI-GIM emphasizes the two most important enterprise architectural principles: Introduction of the Decision View, and a two-stage design translation using User-Oriented Design and Technical-Oriented design.
The Purdue Enterprise Reference Architecture [PERA] introduces the key Concept of Master Planning. “The development of a Master Plan requires a comprehensive look at the business goals and critical success factors of an enterprise as well as a review and study of its processes, equipment, facilities, customer/market demands, personnel structure and roles, and the scheduling and control requirements (the enterprise integration component), among others” [PERA]. These result in a detailed plan, the Master Plan, to carry out the necessary coordination and integration actions to provide enterprise integration for the factory, plant or other business entities.
The master plan should be developed as outlined in steps 1-13 in figure 2. “The Master Plan gives Enterprise Management the fullest visibility of the proposed project. It helps the management to study different feasibilities before finalizing their investment and releasing the funding. The potential success of the development of the Master Plan can itself be enhanced by following the guidance of enterprise integration reference architecture and its associated methodology.”[PERA] Irrespective of our chosen enterprise architecture framework which may include, but is not limited to Zachman [Zachman], TOGAF [TOGAF], RM-ODP [RM-ODP] etc., master plan is one the basic requirements for any enterprise architectural foundation.
This process of development of the Mission, Vision and Values of the Enterprise is not envisioned from a technical point of view, but is one of the most important requirement considerations for any successful enterprise. The Enterprise master plan helps us understand different business principles and shows the right directions to digitize the enterprise. The master plan, as stated in [PERA page 52], says that rapid achievement of system integration and thus realization of the most significant enterprise integration benefits, allows for:
- Increased customer service and heightened awareness of customer and market demands
- Reduction and/or reorientation of indirect labor and overhead
- Improved responsiveness to technical, economic and environmental changes
- Improved product quality and robustness at a lower cost
- A total organizational understanding and commitment to the strategy
- Improved probability that a truly integrated information and control system is achieved
Enterprise architecture is a derivative of Enterprise reference architecture, which is a graphical representation or model of the potential life history of any systems’ engineering development program. It points out all essential steps or phases of the programs, identifies all tasks involved and shows their interrelationship. It also provides guidelines to choose the right type of tools or techniques that can help to carry out each of these tasks in turn. The accompanying methodology is a step-by-step detailed description of the process behind of each of the steps and their corresponding tasks in turn which will lead to the preparation of a proper and effective master Plan.
Now that we agree about the significance of a master plan within enterprise architecture, it is mandatory to have a good understanding of the master plan to define successful enterprise architecture. However, the master plan is not the only knowledge required to build our enterprise; we must understand how an enterprise is decomposed into different types of modules, which will enlighten the importance of modularization within enterprise architecture. The following section "Enterprise Modularization" looks at how this enterprise architecture can be decomposed into different levels of abstraction.
Enterprise Architecture
Enterprise architecture is the art of building enterprise systems and applying the set of fundamental principles within software engineering practice that is concerned with a description of all the vision and mission of the enterprise, designing and modeling the use-cases of the system, designing relationships between the modules and finally building the organizational software foundations. Enterprise architectural principles cover enterprise aspects ranging from the organizational structure, business processes, information systems, and infrastructure.
Enterprise architecture enables proper balance between organizational business innovation and relevant IT solutions. It allows each of the atomic elements of an enterprise to innovate and to adhere to the right IT strategy to synergize across the different business units to get the unique benefits of enterprise. Enterprise architectural practice helps us to convert technical innovation into business benefits, which includes:
- Establishment of an efficient controlling mechanism to address critical enterprise wide issues like security, transactions, systems management and so on
- Better ROI and accumulation of technical assets
- Better risk management strategy
- Faster, simpler, and cheaper procurement plan
An enterprise consists of multiple technologies and domains spreading across two different axes, which influence and collaborate with each other. Defining architectures for an enterprise aligns the business and technology.
Stakeholders are individuals, teams, or organizations who are playing key roles in, and have different set of concerns about, the system. e.g. end users, developers, business managers, acquirers and so on. Identifying appropriate stakeholders is one of the first criteria to build successful enterprise architectures.
Models play a vital role in all levels and approaches to enterprise architecture, and are the starting point for a more detailed level of system development. Models help to visualize the entire enterprise systems and are a very good way to express the interrelations among the different elements of an enterprise and understand the enterprise system from different stakeholders’ point of view.
“Views contain a subset of facts present in the integrated model allowing the user to concentrate on relevant questions that the respective stakeholders may wish to consider using enterprise modelling. Different views may be made available highlighting certain aspects of the model and hiding all others. The concept of view is applicable for models of all entity types across their entire life-cycle. Modelling views are generated from the underlying integrated model. Any model manipulation (any change of the contents of a particular view), will be reflected in all relevant views and aspects of the model.” [GERAM]. A view is what we view in the system and is always very much architecture specific. A viewpoint is where your view is pointing from and very much generic, and therefore reusable. Every view has an implicit or explicit viewpoint associated with it. ANSI/IEEE Std 1471-2000 [IEEE], TOGAF [TOGAF], RM-ODP [RM-ODP] encourages architects to define viewpoints explicitly. ANSI/IEEE Std 1471-2000 [IEEE] defined architecture may be mapped with the modern enterprise architecture and could be depicted as below:
Enterprise domains and enterprise environments influence an enterprise. Each enterprise has its own enterprise architecture that is an aggregation of multiple models. On the other hand, enterprises have different set of stakeholders, who further have different types of enterprise concerns. Enterprise architecture is rightly described by an enterprise architectural description, which is organized by a set of views expressed in different architectural frameworks. Each of these views conforms to specific viewpoints and is expressed in enterprise models. Moreover, these enterprise viewpoints are used to cover a different set of enterprise concerns expressed by a different set of enterprise stakeholders.
Conclusion
In this edition, we have understood the role of views, viewpoints, models and concerns. Enterprise architecture results in specific views and is built on solid foundations of identification of viewpoints, designing appropriate models, and realizing concerns in appropriate models. Therefore the success of any enterprise representation is very much dependent on how we express the enterprise architecture in a visual way, so that it is easy to understand from every stakeholders’ point of view. Modelling is the only way to express the architect’s brainchild. Modelling is a tremendously powerful way to visually express the business in terms of technology.
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.
- [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.
- [Catalysis] Catalysis-Objects, Components, and Frameworks with UML by Desmond D’Souza and Alan Cameron Wills
- [TOGAF] TOGAF (The Open Group Architecture Framework) Version 8.1 "Enterprise Edition". Available from http://www.opengroup.org
- [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)
- [GRAI-GIM] [GRAI-GIM] A Specification and Statement of Requirement for GERAM, Report Number 159, Purdue Laboratory for applied Industrial Control, Compiled and Edited by Theodore J. Williams and Hong Li, November 1995, Version 1.1
- [CIMOSA]http://www.pera.net/Methodologies/Cimosa/CIMOSA.html
- http://www.cimosa.de
- [IEEE] IEEE Recommended Practice for Architectural Description of Software- Intensive systems. Institute of Electrical and Electronics Engineering Std 1471-2000
- [Zachman] Extending and Formalising the framework for information systems architecture by J.A.Zachman and J.F.Sowa Published in IBM Systems Journal, 31(3): p 590-616, 1992
- http://www.pera.net/Pera/Wha_mast.html
- http://www.enterpriseunifiedprocess.com/essays/phases.html
- http://www.omg.org/mda/specs.htm
- [ISO 9126] Software Quality: The Elusive Target by Barbara Kitchenham and Shari Lawrence Pfleeger, The Software, IEEE, January 1996 (Vol. 13, No. 1) pp. 12-21
- 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
- Components and Viewpoints as Integrated Separations of Concerns in System Designing by Zoran Stojanovic, Ajantha Dahanayake, ISA Department, Faculty of Information Technology and Systems, Delft University of Technology, Mekelweg 4, 2628 CD Delft, The Netherlands
- [GERAM Report 1995] A SPECIFICATION AND STATEMENT OF REQUIREMENTS FOR GERAM by THEODORE J. WILLIAMS and HONG LI, November 1995
