integrated business and IT systems which results in improved project success rate. Keywords: .... number of technologies, which together enable the model.
An MDA-Based Generic Framework to Address Various Aspects of Enterprise Architecture S. Shervin Ostadzadeh
Fereidoon Shams Aliee
S. Arash Ostadzadeh
Computer Engineering Department, Faculty of Engineering, Science & Research Branch of Islamic Azad University, Tehran, Iran
Computer Engineering Department, Faculty of Electrical & Computer Eng., Shahid Beheshti University, Tehran, Iran
Computer Engineering Laboratory, Microelectronics and CE Department, Delft University of Technology, Delft, The Netherlands
Abstract - With a trend toward becoming more and more information based, enterprises constantly attempt to surpass the accomplishments of each other by improving their information activities. Building an Enterprise Architecture (EA) undoubtedly serves as a fundamental concept to accomplish this goal. EA typically encompasses an overview of the entire information system in an enterprise, including the software, hardware, and information architectures. Here, we aim the use of Model Driven Architecture (MDA) in order to cover different aspects of Enterprise Architecture. MDA, the most recent de facto standard for software development, has been selected to address EA across multiple hierarchical levels spanned from business to IT. Despite the fact that MDA is not intended to contribute in this respect, we plan to enhance its initial scope to take advantage of the facilities provided by this innovative architecture. The presented framework helps developers to design and justify completely integrated business and IT systems which results in improved project success rate. Keywords: Enterprise Architecture, Model Information Technology, Enterprise Framework.
Driven
Architecture,
I. INTRODUCTION
Business and Information Technology (IT) integration is essential for enterprises to achieve their goals. In recent decades, there have been considerable investments in this field. Unfortunately, many IT investments yield disappointing results. According to [1], 85% of IT departments in the U.S. fail to meet their organizations’ strategic business needs. Some projects result in failure, while others go so far over their budgets that managements eventually kill them (another form of failure). Some projects that initially seemed to be successful proved to be unstable or inflexible over time. Enterprise Architecture (EA) addresses this issue. EA integrates business resources, such as people, machines, facilities, etc., with IT resources, e.g. applications, networks, and clusters, in order to produce efficient business processes. Over time, the expectations of the degree of automation that could be achieved by computing continued to increase. It was no longer satisfying to have islands of automation within the enterprise. The various islands had overlapping functionalities that duplicate information and made interference in automation. As a result, it is necessary to integrate the islands across the enterprise. Applications in such an enterprise can’t be designed using traditional analysis and design methods. We need architecture to address this problem. By using
architecture in IT industry, we have more control over the IT projects in order to prevent their failures. OMG is trying to improve software development by introducing MDA. MDA is “an approach to system specification that separates the specification of system functionality from the specification of the implementation of that functionality on a specific technology platform” [2]. Although, MDA is limited to the software development, it is not clear yet whether or not it can be used to describe systems found in business and IT. In this paper, we investigate the use of MDA in Enterprise Architecture across multiple hierarchical levels ranging from business to IT. Out goal is to propose a generic framework to address various aspects of EA. However, this seems as an extension of the initial scope of MDA, in accordance with our belief that MDA can play a pivotal role in EA. The rest of this paper is organized as follows. In section 2, we introduce some basic concepts and principles. We describe MDA in section 3. Applying MDA to Enterprise Architecture via a generic framework is discussed in section 4. In section 5, our proposed method is compared to traditional methods and the achievements are highlighted. Finally, some concluding remarks and suggestions for future works are stated. II.
BASIC CONCEPTS
In this section, we briefly introduce some basic concepts and principles. We believe these concepts can help readers to clearly understand what we mean by the subsequent ideas presented later in this work. A. Enterprise An enterprise consists of people, information, and technologies; performs business functions; has a defined organizational structure that is commonly distributed in multiple locations; responds to internal and external events; has a purpose for its activities; provides specific services and products to its customers [3]. An IT-related enterprise is an enterprise in which IT plays an important role in its activities. In this paper, we refer to an IT-related enterprise as an enterprise. B. Architecture Architecture has emerged as a crucial part of design process. Generically, architecture is the description of a set of
T. Sobh (ed.), Advances in Computer and Information Sciences and Engineering, 455–460. © Springer Science+Business Media B.V. 2008
456
OSTADZADEH ET AL.
components and the relationships between them. In computer science, there are software architectures [4], hardware architectures, network architectures, information architectures, and enterprise architectures. Software architecture describes the layout of the software modules and the connections and relationships among them. Hardware architecture can describe how the hardware components are organized. However, both of these definitions can apply to a single computer, a single information system, or a family of information systems. Thus “architecture” can have a range of meanings, goals, and abstraction levels, depending on the speaker. C. Enterprise Architecture Enterprise Architecture (EA) is a comprehensive view of an enterprise. EA shows the primary components of an enterprise and depicts how these components interact with or relate to each other. EA typically encompasses an overview of the entire information system in an enterprise; including the software, hardware, and information architectures. In this sense, the EA is a meta-architecture. In summary, EA contains views of an enterprise, including work, function, process, and information, it is at the highest level in the architecture pyramid. For details refer to [5]. III.
MODEL DRIVEN ARCHIECTURE
Here, we briefly summarize MDA’s key models, and show how they can be utilized. More details can be found in [6-8]. A. Models in the MDA MDA separates certain key models of a system, and brings a consistent structure to these models: Computation Independent Model (CIM): A computation independent model is a view of a system from the computation independent viewpoint. A CIM does not show details of the structure of systems. A CIM is sometimes called a domain model and a vocabulary that is familiar to practitioners of the domain in question is used in its specification. Platform Independent Model (PIM): A platform independent model is a view of a system from the platform independent viewpoint. A PIM exhibits a specified degree of platform independence so as to be suitable for use with a number of different platforms of the similar type. Platform Specific Model (PSM): A platform specific model is a view of a system from the platform specific viewpoint. A PSM combines the specifications in the PIM with the details that specify how that system uses a particular type of platform. Platform Specific Implementation (PSI): A PSI is an implementation of PSM. It is the execution code that is run on machine. B. MDA Development Process This section describes how the MDA models relate to each other and how they are used by a development group. A short
description of the MDA development process follows. Initially, the CIM requirements for the system are modeled with the computation independent model. CIM describes the CIM to PIM mapping situation in which the system will be used. It may hide much or all of the information about the employment of automated data processing systems. PIM Typically, such a model is independent of system implementation. The model is created by business analysts. Architects PIM to PSM mapping and designers subsequently create Platform Independent Models (PIM) to illustrate the enterprise’s architecture, PSM with no reference to any specific implementation or platform. A PIM is suitable for a particular architectural PSM to code mapping style, or even several styles. The architect will then choose a (or several) platform(s) that enables the system PSI implementation with the desired (Code) architectural qualities. An MDA mapping provides Fig. 1. specifications for transformation of a MDA Process PIM into a PSM regarding a particular platform. The platform model determines the nature of the mapping. In model instance mapping, the architect marks elements of the PIM in order to indicate the mappings used to transform that PIM into a PSM. The next step is taking the marked PIM and transforming it into a PSM. This can be done manually, with computer assistance, or automatically. A tool might transform a PIM directly into deployable code, without producing a PSM. Such a tool might also produce a PSM, for understanding and/or debugging the code. The outputs of transforming a PIM using a particular technique are a PSM and a transformation record. The transformation record includes a mapping of the PIM elements to the corresponding elements of the PSM, and shows which parts of the mapping were used for each section of the transformation. The platform specific model produced by the transformation is a model of the same system specified by the PIM; it also specifies how that system uses of the chosen platform. Finally, developers or testers will use tools to generate code from PSM. Figure 1 demonstrates this process. IV.
APPLYING MDA TO EA
As we mentioned earlier, the integration of business and IT forces project teams to analyze and design a hierarchy of systems. This hierarchy can contain the following levels [9]: Groups of companies collaborating in business systems People and IT systems collaborating in business processes Software components collaborating in IT systems Programming language objects collaborating in software components.
457
AN MDA-BASED GENERIC FRAMEWORK
Suitable approaches for EA should have the ability to analyze and design a system in hierarchical levels. Does MDA have such ability? Can it be used in enterprise applications? Some researchers [9] argue that this is not the case, as MDA is based on UML and UML does not have enough hierarchical levels. However, it should be noted that OMG has adopted a number of technologies, which together enable the model driven architecture. These technologies include UML, MOF, CWM, XMI, and profiles (such as the profiles for EDOC, EJB, etc). They are used to describe PIMs. A PIM can be refined as many times as needed, until the desired system description level is obtained. Afterwards, the infrastructure is taken into account and the PIM is transformed into a PSM. Subsequently, PSMs are also refined as many times as needed. This result in MDA being more descriptive than UML. MDA can be used in analysis and design of hierarchical levels, and so can be used to describe systems found in business and IT. We address some researches for clarification. Grady Booch [10] states that “Model Driven Architecture is a style of enterprise application development and integration, based on using automated tools to build system independent models and transform them into efficient implementations”. Another quote that refer to the utilization of MDA in enterprise, is stated in D’Souza’s work [11], indicating that “MDA is an approach to the full lifecycle integration of enterprise systems comprised of software, hardware, humans and business practices. It provides a systematic framework to understand, design, operate, and evolve all aspects of such enterprise systems”. Moreover, our previous researches [12, 13] also signify that MDA can be used in EA modeling, and describing its various aspects. In this section we aim to show how MDA can be applied to hierarchical levels of analysis and design needed for EA.
A. A Basic Taxonomy As stated earlier, the common way to comprehend procedures in an enterprise is to provide views of components within that enterprise, which is called architecture. Architecture, such as Data Architecture, represents only a single view of an enterprise, but Enterprise Architecture refers to a collection of architectures which are assembled to form a comprehensive view of an enterprise. Organizing such great amounts of information requires a framework. Various enterprise architecture frameworks have already been proposed; among them are Zachman Framework, FEAF, TEAF, and C4ISR. Each framework classifies enterprise architecture aspects based on its own viewpoints. For example, Zachman Framework refers to Scope, Business, System, Technology, Detailed Representations, and Functioning Enterprise; while, FEAF addresses Technology, Applications, Data, and Business. C4ISR views enterprise architecture aspects as Operational, Systems, and Technical. This is not the case with TEAF which adopts Infrastructure, Organizational, Information, and Functional classification. Apparently, there is no agreement in this respect. Figure 2 depicts a basic taxonomy of different kinds of aspects that are commonly used in enterprise architecture. This taxonomy is not deterministic and some enterprise architecture frameworks use somewhat different classification and/or terms. We present this taxonomy to refer to various kinds of perspectives and their requirements. Here are the basic distinctions in the aspects. • Business vs. Technical: A business aspect describes aspects of the business, irrespective of whether those aspects are stated to be automated or not. A technical aspect describes aspects of an IT system that automate elements of the business. Since technical aspect just
EA
Business
Technology
Dynamic
Static
Logical
Infrastructure
Implementation
Application
Data
Service
Process
Strategic
Organization Chart
Fig. 2. A basic taxonomy of enterprise architecture aspects
Physical
458
•
•
OSTADZADEH ET AL.
models the automatic parts of a business, the scope of a technical aspect is smaller than the scope of a corresponding business aspect. Static vs. Dynamic: A static aspect describes the fixed part of the business. It includes strategic models and Organization Chart. A dynamic aspect describes behavioral part of the business. It contains the processes and services that are provided by the business. Logical vs. Physical: A logical aspect describes the logic of a system. It can include data and applications. A physical aspect describes physical artifacts and resources used during IT systems development and runtime. It contains infrastructure and implementation. Infrastructure describes the underlying services that are used for computing. Implementation describes the physical models used to execute the systems. Implementation models may include model files, source code files, executable files, archive files, and other implementation files.
B. Modeling Approach A business model describes business domain aspects of EA. This model can be drawn by business analysts and domain experts. The business analyst perceives the enterprise’s business processes and the information that the processes use. Generally, using UML business use case and activity diagrams is recommended for describing the business aspects [14, 15]. We can also use CRC cards, which are not UMLbased, to model a business. Since, MDA is based on UML, CRC cards approach is not suitable. Using UML primitives is easy and can be applied by the business analysts and domain experts. However, we prefer to use MDA metamodels to describe various aspects of business domain. Note that business aspects can be a part of CIM models in MDA. Strategic model can be described by BMM and SBVR. Organization chart can be modeled by OSM. We can also employ BPDM to describe business processes and services. Refer to [16] for more information about how these metamodels can be applied in practice. Data models provide data view of IT systems. They are part of the logical aspect. We divide data aspects into Knowledge models, Information models, and Raw Data models. Knowledge models describe the data aspects from the most abstract viewpoint. Knowledge models are CIMs, since they describe data aspects of IT systems in a computation independent way. These models should be refined into a computational model, in order to generate PIMs and PSMs. Information models are PIMs. They describe EA knowledge that should be automated, uninterested in a specific platform. Raw Data models describe data aspects based on a special platform. Data aspects of EA can be model with CWM. For more information see [16, 17]. Applications models describe applications view of logical aspect. They show software applications of IT systems in an enterprise. Applications aspects can be divided into information systems and systems technologies. Information systems models describe the applications from the most abstract viewpoint. They are CIMs. Systems technologies
provide a less abstract viewpoint of the applications compared to information systems models, because they consider technical environment. MDA is an approach that separates the specification of system functionality from the specification of the implementation of that functionality on a specific technology platform. Therefore, according to MDA perspective, system technologies models can be divided into two levels: Platform Independent Technologies (PITs) and Platform Specific Technologies (PSTs). As already explained, the distinction between a PIT and a PST depends on the specification of a reference set of platform technologies. PITs are independent of a special platform, while PSTs are specific to a platform. What distinguishes MDA from other approaches is the description of the applications models. We have already stressed that information systems models describe the application from the most abstract viewpoint. PITs provide a less abstract view because they factor in some considerations of the technical environment. PITs are refinements of information systems models. PSTs provide an even less abstract viewpoint of the applications, because they consider platform-specific environment. PSTs are refinements of PITs, in order to specify some software formatting technologies, programming languages, distributed component middlewares, or messaging middlewares. These refinements are based on platform model. To describe applications models, we can use general-purpose UML primitives, such as class, interaction, collaboration, and use case modeling. We can also utilize WSM and PSM-specific profiles (CORBA, EJB, and .Net) for the PSTs. Physical aspect doesn’t deal with logic aspect; therefore, it provides a very different view of the systems. A physical aspect describes physical artifacts and resources used during deployment and runtime. From an MDA perspective, physical models can drive automated deployment tools [7]. Using UML and/or some other MOF-compliant languages to describe deployment makes it possible to incorporate deployment automation into the MDA effort to automate more of the deployment process. MOF is a very abstract metamodel that every model in MDA is defined in terms of its constructs. UML deployment diagram can describe physical models. MDA tools can generate deployment diagrams from PIM. A generator that reads a PIM and implements a mapping to PSM could generate a skeletal deployment model, since certain outlines of the deployment requirements are only known. Figure 3 illustrates mapping MDA models to the basic taxonomy of enterprise architecture aspects. C. Synchronizing Models There are three basic engineering approaches for synchronizing models in various abstract levels [7]: • “Forward Engineering Only” approach: This approach permits no changes to be made in low level models. The changes can occur from top level models to the low level models. Since synchronization ripples in one direction only, it is not possible for a developer to make changes to low level models (here, PSMs and codes).
459
AN MDA-BASED GENERIC FRAMEWORK
•
•
“Partial Round-Trip Engineering” approach: This approach allows developers to enhance generated low level models. However, enhancement must be additive. Anything generated from the higher level model can not be overwritten or deleted. Furthermore, the developer can’t add anything that affects the higher level of abstraction. In this approach, synchronization also ripples in one direction only, however some local changes are allowed in low level models. “Full Round-Trip Engineering” approach: In this approach, it is permissible to define something at the lower level of abstraction that is reflected back to the upper level. In fact, the developers can add, edit, or delete something in low level models that affects high level models. With this approach, synchronization can ripple both up and down the abstraction levels.
From a software development process perspective (such as MDA), the Full Round-Trip Engineering is the best approach,
since the developers have considerably more freedom to alter the generated artifacts. However, if we want to employ MDA in EA, there are some notes that should be considered. A crucial contribution of EA in enterprise is the ability to enforce architecture. The Forward Engineering Only approach has the greatest capacity to enforce architectural styles that an architecture dictates. The more freedom engineers have, the more difficult it is to ensure architectural enforcement. RoundTrip engineering, whether partial or full, makes it more difficult to enforce architectural styles. Although these approaches have more capacities for engineering, but they are not suitable for EA. V.
PROPOSED METHOD VS. TRADITIONAL METHODS
Let us now take a closer look at the advantages achieved by MDA based EA compared to traditional non-MDA approaches.
EA
Business
Static
Logical
Physical
PSTs
Fig. 3. Mapping MDA models to the basic taxonomy of enterprise architecture aspects
Infrastructure
PITs
Raw Data
PSI
Implementation
Information Systems
Info.
System Technologies
Knowledge
Service
Process
PSM
Dynamic
Strategic
PIM
Organization Chart
CIM
Technology
460
OSTADZADEH ET AL.
A. Productivity MDA can improve productivity in two ways. First, the PIM developers have less work to do since platform specific details need not to be designed and considered. These details are already addressed in the transformation definition at the PSM and code level. Note that there is much less code to be written, because a large amount of the code is already generated from the PIM. The second improvement comes from the fact that in MDA, the developers can shift focus from code to CIM and PIM, thus paying more attention to solving the business problem at hand. This results in a system that fits much better with the needs of the end users.
are needed in an EA. We showed how MDA can support each abstract model. We have suggested that using Forward Engineering Only approach is the best solution for synchronizing models at various abstract levels. Finally, we have highlighted the improvements achieved by using MDA in Enterprise Architecture. In future, it would be a good idea if one investigates the way information in the framework can be modeled by MDA standards. This can serve as a practical guide for an architect who is willing to use MDA in EA, since it specifies which model(s) should be used for special architectural information. REFERENCES
B. Portability Within the MDA, portability is achieved by focusing on the development of CIMs and PIMs, which are platform independent. A PIM can be automatically transformed into multiple PSMs for different platforms. Everything that is specified at the CIM or PIM level is therefore completely portable. C. Interoperability In MDA, multiple PSMs generated from one PIM may have relationships, which are called bridges. When PSMs are targeted at different platforms, they cannot directly talk with each other. In this case, we need to transform elements from one PSM into elements used in another PSM. This is what interoperability is all about. MDA addresses this problem by generating not only the PSMs, but the necessary bridges between them as well. If we transform one PIM into two PSMs targeted at two platforms, all the information we need to bridge the gap between these two PSMs is available. For a given element in PIM, we know which elements corresponding to it are in the PSMs. So, we can find how elements in the first PSM relate to elements in the second one. In this case, we have all the information we need to generate a bridge between the two PSMs. D. Documenting In MDA, we need to document high level models of abstraction. The CIM and PIM models fulfill the function of high level documentations that are needed for any software system. These high level documentations are not new in this approach, since the traditional methods also do it. But the major difference is that the CIM and PIM are not abandoned after creating. In fact, these models are part of our software. When we want to make changes to the system, the changes will be made in CIM and PIM models, and then they are reflected in the lower models. VI.
CONCLUDING REMARKS
Business and IT integration is a critical challenge faced by IT industry. A key to overcome this problem is applying Enterprise Architecture. We have investigated the employment of MDA in EA. MDA seems to be a good solution for supporting the modeling of hierarchical systems. We discussed various models in different abstract levels that
[1] T. Hoffman, “Study: 85% of IT Departments Fail to Meet Biz Needs”, Computer World, October 11, 1999. [2] J. Miller and J. Mukerji, “Model Driven Architecture (MDA)”, Object Management Group, 2001. [3] M.A. Rood, “Enterprise Architecture: Definition, Content, and Utility”, IEEE Trans., 1994. [4] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 2nd Edition, Addison-Wesley, 2004. [5] C.M. Pereira, and P. Sousa, “Enterprise Architectures: Business and IT Alignment”, Proceedings of the 2005 ACM symposium on Applied computing, Santa fe, New Mexico, 2005. [6] MDA Guide, OMG document, available at http://www.omg.org.mda/, 2003. [7] D.S. Frankel, Model Driven Architecture: Applying MDA to Enterprise Computing, OMG Press, John Wiley & Sons, 2003. [8] S.J. Mellor, K. Scott, A. Uhl, and D. Weise, MDA Distilled: Principles of Model-Driven Architecture, Addison Wesley, 2004. [9] A. Wegmann, and O. Preiss, “MDA in Enterprise Architecture? The Living System Theory to the Rescue…”, Proceedings of the 7th IEEE international Enterprise Distributed Object Computing Conference (EDOC’03), 2003. [10] G. Booch, B. Brown, S. Iyengar, J. Rumbaugh, B. Selic, “An MDA Manifesto”, MDA Journal, May 2004. [11] D. D’Souza, “Model-Driven Architecture and Integration”, Kinetium, March 2001. [12] S.S. Ostadzadeh, F. Shams, and S.A. Ostadzadeh, “A Method for Consistent Modeling of Zachman Framework,” Advances and Innovations in Systems, Computing Sciences and Software Engineering, Springer, pp. 375-380, August 2007. (ISBN 9781-4020-6263-6) [13] S.S. Ostadzadeh, F. Shams, and S.A. Ostadzadeh, “Employing MDA in Enterprise Architecture,” Proceedings of the 12th International CSI Computer Conference (CSICC’ 2007), pp. 1646-1653, February 2007. [14] A. Fatholahi, An Investigation into Applying UML to Zachman Framework, MSc thesis, Shahid Beheshti University, Tehran, 2004. [15] C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, Prentice Hall, 2002. [16] S.S. Ostadzadeh, An MDA-Based Unified Modeling Approach for Zachman Framework Cells, MSc thesis, Science & Research branch of Islamic Azad University, Tehran, 2006. [17] J. Poole, D. Chang, D. Tolbert, D. Mellor, Common Warehouse Metamodel: An Introduction to the Standard for Data Warehouse Integration, OMG Press, John Wiley & Sons, 2001.
