An MOF-based repository for enterprise architecture models

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Introductory

John Butler, Chief Architect, Global Public Sector, Unisys Corporation
Ravi Hubbly, Senior Architect, Global Public Sector, Unisys Corporation
Walcelio Melo, Solution Architect Director, Unisys Corporation

15 Mar 2005

from The Rational Edge: This paper presents the work Unisys has done to create a central enterprise architecture (EA) at a large organization within the United States federal government. This work includes defining a standard core EA modeling language supported by the EA repository, and building transformations between tool-specific EA models to the standard core EA language. An overview of the IBM Rational tools used in the process is included.

Enterprise architecture (EA) is commonly defined as a set of models that are relevant for describing the components of an enterprise, the relationships among these components, and how these components support the objectives of the enterprise. EA models become the foundation for the entire organization because these EA models relate the organization's mission, goals, and objectives to the organization's work processes and its supporting IT infrastructure.

Large organizations face many issues modeling their EA, including:

• Use of multiple modeling tools and languages. The use of multiple languages and tools is common across many large organizations, since most large organizations consist of sub-divisions, each with their own EA models based on their own selected EA tools. Moreover, these separate teams often use domain-specific languages and tools that are limited in purpose and capability -- for example, business architecture tools that are not designed for fully capturing system architecture. This proliferation of multiple modeling languages and tools across an organization creates problems with tool integration.
• Incompatibility among modeling languages. Modeling tools use different concepts and terms to represent the same things. Therefore, the advantages of reuse, or the identification of redundant activities that would become evident through a consistent set of EA models, is minimal. Some EA modeling tools are based on standards like OMG's UML, whereas others are based on custom languages.
• Communication. Modeling language incompatibility naturally causes poor communication. Since organizations cannot rely on a common vocabulary for their EA architects, they may end up producing redundant, inconsistent, and poorly integrated EA models.
• No relations between models from different domains. An EA supporting environment should provide a modeling framework that allows EA architects to capture the organization, process, technical, and infrastructure models of the entire enterprise, as well as the relationships among these models in an integrated domain model. The relationship between modeling elements enables traceability across EA components. Currently there is no standard way to capture this traceability information. Hence, making any changes in any EA model on other EA models can lead to unpredictable consequences.
• Modeling tools are weakly integrated. As commented earlier, most of the tools supporting EA modeling are not easily integrated. Some EA modeling tools are based on the OMG's UML standard, which allows integration via exchange of XMI files. However, different UML modeling tools talk different versions of UML: e.g., UML 1.3, 1.4, and so on. This makes model integration difficult. Other tools do not "speak" UML at all and are only able to import or export models via proprietary file formats.

This article presents the work Unisys has done at a large organization within the United States federal government, where the following approaches were used to address the issues above:

• Creation of a common, central EA repository where EA models will be persisted
• Defining a standard core EA modeling language that will be supported by the EA repository
• Building transformations between tool-specific EA models to the standard core EA language

We will also present an overview of the IBM/Rational toolset and process we have leveraged in the development of this solution and describe how this toolset and process have contributed to the success of this project.

Solution overview

In essence, what this project required was a single infrastructure for creating cross-department or enterprise-level views by integrating existing department-specific models into an enterprise-level model. To accomplish this, we considered a number of approaches.

One method is to create direct relations (translators) between models, as shown in Figure 1. However, there are a number of problems with this approach. First, it creates an N² effort: i.e., as the number of tools grows, the effort to maintain the translators grows geometrically. Second, there is no central repository where relationships between model elements can be captured.

Figure 1: Create direct relations (translators) between models

Common EA repository

A better approach is to create an intermediate repository based on the Meta Object Facility (MOF), as shown in Figure 2. Recent work in Model Driven Architecture (MDA) within OMG, Eclipse Modeling Framework (EMF [1]) within Eclipse, and XSD/XMI work within W3C organization has opened up the possibility for all the models in virtually any tool to be ported into repository. This will make it possible to make the N² problem into an N-order problem and will also make it feasible to capture relationships between related model elements within the common MOF repository.

We took this approach. As we will present later in this article, we have defined an MOF-based common meta-model for EA models and built a supporting environment for this meta-model.

Figure 2: Tool integration via an MOF-based repository

Defining a standard core EA modeling language

OMG provides meta-models that can be used to capture EA models. As an example, Figure 3 provides a map between OMG specifications and the Zachman EA Framework. As indicated, OMG specification can be used to support the modeling of EA for different stakeholders' views.

The MOF-based common meta-model we created to support EA models is heavily based on OMG specifications.

Figure 3: Zachman EA Framework vs. OMG specifications [2]

Transformations

Eclipse/EMF can easily be used to build transformations between EA models stored in an MOF-based repository and EA tools. In addition, JET and GMT are currently Eclipse-based projects that can be leveraged to implement transformations among models.

As we show later in this article, we have developed transformation modules using Eclipse / EMF / Ecore to do bidirectional transformation between Popkins System Architect and DAT's ComponentX to the standard core model. In the future, OMG QVT-based tools can be used to replace these modules.

Tooling and process

In this section, we present an overview of the IBM / Rational tools and process leveraged to develop this solution.

RUP

Rational Unified Process is the de facto industry standard for project lifecycle development and management. As we have commented in a previous paper,¹ Unisys integrates RUP into its Business Blueprint methodology to provide a highly mature process across the entire organization. RUP was a key component in the development of our solution:

• It helped us define a cohesive software development where project activities, artifacts, key roles, and responsibilities could be easily established.
• It can be used in agile software development projects like our project. The agility (or lightweight) dimension of RUP allowed us to have disciplined software development process without bureaucracy that promotes adaptability rather than rigid planning.
• RUP is sufficiently business-focused to assure stakeholder acceptance and delivery of the development effort's values, goals, and objectives.
• RUP is based on standards, which was vital to our client. Although RUP is an IBM Rational product, it takes advantage of standards like UML and de facto standards like the Unified Software Development Process.
• RUP is adaptive. In our case, we could also take advantage of the specific Unisys implementation of RUP, which contains process elements tailored to the Unisys Blueprint methodology.

IBM Rational Requisite Pro

According to Pohl,² "requirements engineering is the systematic process of developing requirements through an iterative cooperative process of analyzing the problem, documenting the resulting observations in a variety of representation formats, and checking the accuracy of the understanding gained." As commented by the Standish Group, requirements issues account for 41% of the reasons for project cost overruns and cancellations. To avoid these, we decided to provide team members with a computer-based tool that would help them better carry out requirement engineering activities.

IBM Rational RequisitePro was the tool we chose. It is specially designed to support the requirement engineering process. During the execution of this project, Unisys Team leveraged RequisitePro capabilities in order to better manage the project requirements, promote communication and collaboration among team members, and reduce project risks.

RequistePro was also used in the following ways:

1. As recommended by Hanslip,³ we used RequisitePro to help us manage the proposal process. The system features from the statement of work and request for proposal have been comprehensively documented using RequisitePro. During the project, we could easily correlate system capabilities to the required system features stated in the request for proposal and statement of work.
2. As recommended by van Epps,⁴ we used RequisitePro as our risk management tool. RequisitePro provides a framework within which a risk management project was created. By leveraging RequisitePro as our risk management tool, we could easily:

• Define our risk management process.
• Specify risk types, risk attributes and default values.
• Enable email for discussion groups for risk identification, analysis, and plan.
• Protect our risk database in a centralized database under the control of RequistePro.
• Provide bi-directional relationships between risks and other project lifecycle artifacts, e.g., requirements, use cases, etc.

IBM Rational Rose

IBM Rational Rose is a popular tool for developing the various UML models, such as use case model and design model, used in the project lifecycle. It provides round-trip engineering and allows XMI model serialization. Unisys Team used Rational Rose as a meta-modeling tool for defining the MOF-based enterprise architecture meta-model (EAML). In addition, Rational Rose-based EAML models were used as input artifacts to the Eclipse Modeling Framework (EMF) for creating a model editor for models based on EAML.

Eclipse Modeling Framework

EMF is a modeling framework and code generation facility that provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor.

Use of EMF greatly contributed to the success of this project. It was used:

• To create an XMI schema for the enterprise architecture meta-model defined in the context of this project. The creation of an XML schema compatible with OMG XMI specification can be a tedious and error-prone task. However, leveraging EMF capabilities significantly eases generation of an error-free XML schema complying with OMG XMI specification. The process of creating XML schema is straightforward. Once you create an EMF project in Eclipse from a Rational Rose meta-model, EMF can be used to automatically generate the XMI-based XML schema for this meta-model.
• To serialize and persist in XMI enterprise architecture models in the MOF-based repository.
• To create tool transformers. As we will describe later in this article, EMF was used to build model transformers from enterprise architecture tools, like Popkins System Architect, to an MOF-based repository. The transformation drivers were built in Java by leveraging the EMF API.

IBM Rational ClearCase

According to CMMI,⁵ "the purpose of configuration management is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits." A reliable, robust, and efficient software configuration management tool is a key component in the achievement of configuration management process goals. In this project, we set up a configuration management environment based on Rational ClearCase. Among other benefits, ClearCase provides support to the following software configuration management activities:

• Identification of configuration items
• Establishment of a configuration management and change management supporting environment
• Creation and releasing of baselines
• Tracking of change requests
• Controlling of configuration items, e.g., requirements, business rules, UML models, Java code, etc.

Back to top

Context

The work described here has been developed under the context of the General Services Administration (GSA), Office of the Chief Information Officer (OCIO), Enterprise Architecture Program Management Office (EAPMO). This office contracted the Unisys Team to establish an Infrastructure Services Platform (ISP) for a GSA-wide Enterprise Architecture (EA). The purpose of developing a Federal Enterprise Architecture (FEAF)-compliant reusable asset repository is to enable enterprise architects to manage and consume reusable software assets across GSA projects and programs.

GSA described its vision for this work:

"...to support the GSA in establishing an efficient GSA-wide EA environment that is tool agnostic, facilitates model-driven architecture implementation, and supports interoperability between tools and frameworks through innovative and strategic application of IT."

Based on the non-functional requirements stated by GSA, we determined that this project needed OMG MDA-enabling capabilities. In addition, we would have to build an MOF-based repository for GSA EA models in order to foster reusability and centralized control above GSA EA models. Also, given the tool interoperability issues faced by GSA, we would have to deliver a standards-based solution, since GSA was not willing to be locked into a vendor-proprietary solution.

Based on these non-functional requirements and vision, we have designed the kernel of an MOF-based EA language allowing the integration of different kinds of EA models across the entire organization. We have also created a core of a centralized MOF-based repository to allow the reliable retrieval, storage, manipulation, and control of GSA EA models. These solution components will be described in the following sections.

Back to top

Solution architecture

This section provides a high-level description of the main aspects of the solution architecture put in place for the MOF-based repository, as requested by GSA.

Features and capabilities

Table 1 shows the major system capabilities, which an MOF-based repository should support to allow the manipulation of EA models. Figure 4 offers a conceptual view of this solution.

Table 1: Solution capabilities of an MOF-based central repository

Figure 4: Conceptual view of the solution

Architecture: Logical view

Figure 4 provides a conceptual architectural view of the target solution. EA models are stored in an MOF-based repository. In our case, we have used Xindice⁶ as the data storage component. Models are manipulated and transformed using Eclipse / EMF / Ecore. For each EA modeling tool, transforms are built in order to translate the models from the MOF-based repository to the tool dialect, and vice-versa.

In the current application, EMF-based translators have been built for Popkin SA and DAT ComponentX.⁷ The transformation engine is made up of the following major components:

• Eclipse Modeling Framework (EMF) to manipulate the model using the meta-model
• Translators to help conversion

As noted earlier, the Eclipse Modeling Framework (EMF) is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. Models can be specified using annotated Java, XML documents, or modeling tools like Rational Rose, then imported into EMF. Most important of all, EMF provides the foundation for interoperability with other EMF-based tools and applications.

The high-level overview of EMF is displayed in Figure 5.

Figure 5: EMF overview

Creating translators

We used a model-driven (MDA style) approach to generating models for creating the translators, including the following steps:

1. Create schema from metadata elements and instance XML metadata for that artifact.
2. Load XSD (XML schema) into Eclipse to generate .ecore and .genmodel files.
3. Generate Java factories, utils, and implementation classes for cartridges for that tool artifact.

Table 2 identifies the contents needed to import, export, and transform models between different target and source tool sets.

Table 2: Transformation content

Import/export process

The import/export process is responsible for translating XML model data into and out of the MOF-based common meta-model. This process utilizes the transformation engine to allow artifacts built by various modeling tools to be converted into the MOF-based common meta-model.

Model data from/to tools in XML

Model data from/to tools in XML form a repository that contains XML files that must integrate with the MOF-based common meta-model. This is a place where XML files will be kept before they are imported into the MOF-based common meta-model system or exported from the MOF-based common meta-model system to go into other tool repositories.

Back to top

An MOF-based EA modeling language (EAML)

We created an MOF-based common meta-model to support EA models. MOF-based EAML was limited to the following sub-set of EA models:

• Business data structures. A Business Data Structure Model is an EA model that documents the things-of-interest to the business, independent from the activities, which take place in the business.
• Organization decomposition. An Organizational Decomposition Model is an EA model that describes how the enterprises are structured for administrative purposes.
• Business process. A Business Process Model is an EA model that describes in detail the enterprise's large-to-medium grain value-chains.

We performed a gap analysis between the types of EA models listed above and those represented as OMG standards, and analyzed the following standards:

Enterprise Distributed Object Computing (EDOC). This standard aims at providing a platform-independent, recursive, collaboration-based modeling approach that can be used at different levels of granularity and different degrees of coupling, for both business and systems modeling. This standard contains a platform modeling facility, called ECA, which provides concepts for the modeling of business process, business process roles, and business information needs.

Common Warehouse Meta-model (CWM). This standard aims at providing interfaces that can be used to enable easy interchange of warehouse and business intelligence metadata among data warehouse tools, data warehouse platforms, and data warehouse metadata repositories in distributed heterogeneous environments. This standard was not originally created to deal with EA models. However, it provides concepts that can be reused and extended to model business functions decomposition, business information needs, and organization decomposition via its entity-relationship meta-model.

Business Process Definition Meta-Model (BPDM). BPDM is not yet a standard. Once approved, BDPM would provide a meta-model for business process modeling.

Ontology Definition Meta-Model (ODM). Like BPDM, ODM is not yet a standard. Once approved, it would provide modeling capabilities for defining ontologies.⁸ In addition, like CWM, ODM provides an entity relationship that could be used to model business functions decomposition, business information needs, and organization, decomposition.

Table 3 provides an assessment of these OMG standards and the concepts they support vis-à-vis the modeling concepts required by an EA modeling language as described above. "Very high" indicates that the standard already provides semantically rich concepts that fully map to the required EA model concepts, while "very low" indicates that the standard does not provide such direct mapping.

Based on this preliminary assessment we decided that EDOC would be used initially as the core model. However, when either BPDM or ODM are approved, EAML will evolve in order take advantage of these OMG standards.

Table 3: Assessment of OMG standards vis-à-vis the required EA model

In the context of this project, we applied a collection of changes to OMG's EDOC specification. These were necessary for several reasons: 1) to correct syntactical errors found in the specification; 2) to make the meta-model less sensitive to existing meta-modeling tools like EMF; and 3) to introduce functional enhancements. All changes will be reported back to the OMG.

Back to top

Model transformation

Within GSA, Popkins System Architecture (SA) is one of the most used data modeling tools. Given the important role this tool plays in the GSA's enterprise architecture, this section provides an overview of how logical and physical data models have been transformed to EAML.

Transforming entity models

Figure 6 shows a meta-model for logical and physical EA models derived from SA. This meta-model was based on the study of how the modeling tool imports and exports models from and to XML files. Basically, an entity relationship model contains the following information described as XML attributes and elements:

• Source and target entities
• Relationship containing relationship name and cardinalities

Figure 6: Reverse engineered meta-model for entity relationship models
Click to enlarge

In the transformation process, SA models serialized as proprietary XML files have been reversed engineered. Then, SA XML files have been converted to a non-proprietary, semantic-rich, MOF-based XMI using EMF.

Figure 7 shows the mapping between SA Entity Relationship and EAML. Entities and relationships are first class citizens and are represented by the CompositeData model element. This allows n-tier relationships to be easily captured in the model. For each CompositeData, an Entity model element is also created in order to capture conceptual entity-relationship models. (Further information about EDOC model elements can be found in the OMG EDOC specification.)

First, we have built EMF projects for EAML and SA. Then, we have used EMF to implement bi-directional transformations between EAML and SA.

Figure 7: EAML mapping for SA Entity-Relationship models

Transforming business process models

GSA uses process charts and process maps, which are part of a traditional business process modeling notation. An enterprise architect can model processes within swimlanes on both the Process Chart and the Process Map. Originally, the Process Chart was intended as a diagram to model processes without swimlanes; the Process Map provided swimlane capability. Now, both diagrams enable an enterprise architect to model swimlanes, so she only needs to use Process Maps if she particularly wants some sort of separation between diagrams that only have process flows drawn, and diagrams that have the same process flows drawn within swimlanes.

The Process Map diagram is an event-driven diagram -- you model events in the business, and the processes that take place after those events. You may optionally model the units of the business where the events and processes take place, with swimlanes.

Figure 8 shows a sample of a Process Map. In this diagram, the arrow-pointing-right symbol represents an event, Customer Requests Reservation. There is a mandatory flow (bold line) from this event to the process Store Customer Details. There is a mandatory flow (bold line) from process Store Customer Details to process Check Room Availability. There are two optional flow lines leaving the process Check Room Availability -- thin lines with an open arrowhead on the line. These lines denote a flow out of the process dependent on a condition. If Room Available, then the result called Provisionally Book Room is done; else the result Notify Unavailability To Client is sent.

Figure 8: Process Map sample
Click to enlarge

In addition, the event and processes in this diagram are plotted against the part of the organization where the event happens or the process takes place. These divisions, shown in the diagram as Reception, Customer, and Accounts are known as swimlanes, and represent units in the organization, or Organizational Units.

Thus, a Process Map is made up of:

• Swimlanes (Organizational Unit)
• Events
• Results
• Elementary Business Process
• Mandatory Flow
• Optional Flow

Figure 9 shows how we identified the mappings of these model elements to EAML model elements.

Figure 9: SA Process Model map to EDOC
Click to enlarge

As with the ER model, we used EMF to implement bi-directional transformations between EAML and SA Process Models.

Back to top

Conclusion

The General Services Administration (GSA), Office of the Chief Information Officer (OCIO), pursues new ways of applying computing and communications technologies to the practical problems of information management. The goal is to reduce the cost and improve the quality of government services, reduce technology risk, and share the results of projects throughout the federal sector. In order to assist GSA OCIO to attain its goals, we created the core of an MOF-based common EAML, and we built the kernel of an MOF repository to demonstrate the ability to store, retrieve, and handle EA models described in EAML language. To do so, common EA models used in this organization have been used, i.e., business process models and entity-relationship models.

Further work will include building an enterprise class MOF repository that is fully compliant with OMG MOF 2.0 and OMG MOF Lifecycle specifications.

Back to top

References

[1] F. Budinsky; D. Steinberg; E. Merks; R. Ellersick; T. J. Grose. Eclipse Modeling Framework. Addison-Wesley, 2004.

[2] David S. Frankel, Paul Harmon, Jishnu Mukerji, James Odell, Martin Owen, Pete Rivitt, Mike Rosen, Richard Mark Soley. The Zachman Framework and the OMG's Model Driven Architecture. Business and Process Trends, White Paper, September 2003.

[3] Object Management Group (OMG). Enterprise Collaboration Architecture (ECA) Specification. February 2004, Version 1.0, formal/04-02-01.

[4] J.A. Zachman. "A Framework for Information Systems Architecture," IBM Systems Journal, Vol. 26, No. 3, 1987. (The same article was reprinted in 1999 in a special double issue of the IBM Systems Journal that is easier to locate: Vol. 38, Nos 2&3, 1999.)

[5] Walcelio Melo. "Enhancing RUP for CMMI compliance: A methodological approach," The Rational Edge, July 2004.

Back to top

Notes

¹ Walcelio Melo. "Enhancing RUP for CMMI compliance: A methodological approach," The Rational Edge, July 2004.

² Klaus Pohl. Process-Centered Requirements Engineering. Research Studies Press. 1996

³ David Hanslip. Using IBM Rational RequisitePro to support a project responding to a Request for Proposal (RFP). 2004. URL: http://www-128.ibm.com/developerworks/rational/library/5347.html

⁴ Cindy Van Epps. "Automating Risk Management with Rational RequisitePro," The Rational Edge, Dec. 2001.

⁵ Capability Maturity Model Integration. See the Software Engineering Institute Web page at http://www.sei.cmu.edu/cmmi/

⁶ http://xml.apache.org/xindice/

⁷ See Data Access Technologies' Web page at http://www.enterprise-component.com/

⁸ Ontology is defined as "an explicit formal specification of how to represent the objects, concepts, and other entities that are assumed to exist in some area of interest and the relationships that hold among them" http://www.doi.org/handbook_2000/glossary.html

About the authors

		John Butler is the chief architect, Global Public Sector, for Unisys Corporation. He has more than fifteen years of broad IT experience, working in all aspects of large-scale system development and integration, ranging from mainframe to Internet-based technologies. He has provided IT services in both the public and private sectors in a variety of vertical industries, including healthcare, financial services, manufacturing, power generation, package delivery, and retail, and he currently chairs the OMG E-Government SIG.

		Ravi Hubbly is a Sr. Architect, Global Public Sector, for Unisys Corporation. He has a masters in computer engineering and has more than twelve years of experience in building information systems for large enterprises. He helps Unisys clients apply best practices in software architecture and use process methodology to build highly scalable information systems. He has provided information technology services to various industry verticals including automotive, retail, healthcare, expatriate and property tax, and government.

		Dr. Walcelio Melo is a solution architect director at Unisys Corporation and an Adjunct Professor at George Mason University. At Unisys, he is currently the chief architect for the GSA/Unisys FAME program, in which he indirectly oversees the work of FAME architects and developers. He is responsible for establishing and implementing architectural guidelines across all FAME Task Orders and leads the FAME architecture review board. Dr. Melo teaches in the graduate program of the Department of Information and Software Engineering at GMU. He has authored more than fifty papers published internationally in workshops, conferences, journals, books, and encyclopedias, and he can be contacted via http://www.geocities.com/walcelio_melo

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top