Integrate WebSphere Business Modeler and Rational Data Architect

Three integration scenarios

Get an overview of IBM® Rational® Data Architect and IBM WebSphere® Business Modeler. Step through three scenarios for integrating business process and data modeling using Rational Data Architect and WebSphere Business Modeler, and find recommendations and best practices along the way. [2009 Apr 17: Added note about Rational Data Architect changing product name to InfoSphere Data Architect. --Ed.]

Mei Selvage (meis@us.ibm.com), Data Architect, SOA Design Center, SOA Advanced Technologies, IBM Japan, Software Group

Mei Selvage photoMei Selvage is an SOA data architect with extensive experience in various information management areas and SOA. She is a frequent speaker of conferences and author for many articles.



Ray W. Ellis (rayellis@us.ibm.com), Senior Software Engineer, SOA Design Center, SOA Advanced Technologies, IBM

Ray Ellis photoRay Ellis is a senior software engineer in SOA Design Center at IBM Austin. He has been involved with numerous IBM Information Management, WebSphere, and Rational product development.



Daniel T. Chang (dtchang@us.ibm.com), Senior Software Engineer, Information Management, Data Tools, IBM

Dan Chang photoDaniel T. Chang is a senior software engineer at IBM Silicon Valley Lab. He has been with the RDA Core team since 2006.



17 April 2009 (First published 29 November 2007)

Also available in Chinese Vietnamese Spanish

Introduction

In an SOA world, business process and data modeling are closely related. Most business processes need to manipulate some sort of data. Data supports business processes to accomplish desired business results. When you use a Model-Driven Development (MDD) approach, business process and data modeling can be easily integrated. Moreover, there is semantic interoperability across the layers of enterprise architecture.

Product name change

On December 16th, 2008, IBM announced that as of Version 7.5.1, Rational Data Architect is renamed to InfoSphere Data Architect to feature its role in InfoSphere Foundation Tools.

IBM is the leader in providing business process and data modeling tooling. Users can model business processes in WebSphere Business Modeler and perform logical data modeling in Rational Data Architect. IBM has recognized the importance of integrating process and data modeling using MDD, and has thus developed a WebSphere Business Modeler to Rational Data Architect integration plug-in (hereafter called "plug-in") to link these two tools together. This plug-in is installed on top of Rational Data Architect V7. The "WebSphere Business Modeler and Rational Data Architect Integration Asset – User Guide" details the step-by-step guidance on installing and using the plug-in (see Resources). This article provides an overview of WebSphere Business Modeler and Rational Data Architect, then outlines the recommendations and high-level steps in three WebSphere Business Modeler to Rational Data Architect integration scenarios: top-down, bottom-up, and meet-in-the-middle. The following sections describe each of the scenarios in more detail.

WebSphere Business Modeler and Rational Data Architect

WebSphere Business Modeler is a business process modeling tool that enables an organization to model, design, simulate, analyze, and generate reports for business processes, as well as define organizations, resources, and information. WebSphere Business Modeler bridges the gap between business and information technology (IT) by not only helping an organization locate and eliminate hidden inefficiencies, costs, and delays in their processes, but also by capturing important information to the downstream IT tools such as WebSphere Integration Developer, WebSphere Process Server, and Rational Software Architect.

Business items in WebSphere Business Modeler can be anything that is created, assembled, inspected, tested, modified, or worked upon in business processes. Figure 1, below, shows a few sample business items -- Loans, Application, and so on -- from the sample WebSphere Business Modeler project, QuickstartFinance, which is shipped as part of WebSphere Business Modeler tutorial.

Figure 1. Sample business items in WebSphere Business Modeler QuickstartFinance project
figure1

Rational Data Architect is a comprehensive development environment for data modeling, relating and integrating data assets, and developing database applications. Foremost, Rational Data Architect is a powerful tool that allows you to perform logical, physical, storage, domain, and integration data modeling. Figure 2, below, shows a sample Logical Data Model derived from the sample Rational Data Architect project, QuickstartFinance. Note that the entities correspond to business items in WebSphere Business Modeler.

Figure 2. Sample Logical Data Model created in Rational Data Architect
figure2

Logical Data Models (LDM) were frequently overlooked in the software development life cycle, but they become increasingly more important in SOA for many reasons. A LDM allows you to quickly have an overview of data entities (in other words, a unit of data that generally represents a real-life thing or abstract idea) in an application or an enterprise without overwhelming implementation details. A LDM is especially useful to deal with increasingly complex and heterogeneous IT environments. A LDM creates an enterprise view of data, helps to reduce data redundancy, improve data quality, and speed up integration and green-field projects. Other IT artifacts, such as service models, message models, object models, and physical data models, can be traced to LDMs semantically and often are transformed directly from LDMs. It is not an exaggeration to say LDM is the semantic hub of enterprise architecture.

With state-of-the-art MDD tooling in hand, such as Rational Data Architect and Rational Software Architect, you can easily generate downstream models and physical implementations based on LDMs. This article later describes a real-life case study on using a LDM as the semantic source and transforming it into various IT artifacts.


Top-down integration scenario

In top-down scenario, WebSphere Business Modeler Business Items are exported as an XSD, which is then imported into Rational Data Architect as modeling elements (in other words, entities, attributes, and relationships) in a LDM. This scenario assumes two main IT roles are involved: Business analyst performs business modeling, and data modeler carries out logical data modeling.

Here are the steps for this scenario:

  • Business analyst models business processes in WebSphere Business Modeler. Business data is captured as business items (BI).
  • Business analyst exports business items as XSD in WebSphere Business Modeler.
  • Data modeler imports XSD and transforms it as a LDM using the plug-in in Rational Data Architect.
  • Optionally, data modeler can transform a LDM into a physical database schema and DDL using Rational Data Architect.

The following diagram (Figure 3), created in WebSphere Business Modeler, shows the interaction between business analyst and data modeler in the top-down scenario:

Figure 3. Top-down scenario steps overview
figure3

Consider using the top-down scenario when a combination of the following conditions is true:

  • Business process modeling is driving the project initiative
  • Business processes cut across silos of business units
  • LDM is not available, and it is out of scope for a project
  • Physical database schema is too complex

However, people sometimes adopt top-down scenario for the wrong reasons. The following (in quotes) are some ill-suited reasons to decide to adopt the top-down scenario:

  • "We have never done LDM before." There is always a first time. If your organization has cut corners on LDM in the past, the sooner a LDM effort starts, the better off the organization will be in the long term.
  • "We don't have LDM skills." A good data modeler is worthy of investment so you should hire someone or develop people internally with LDM skills.
  • "Our application deals with messages only." Most messages will eventually be persisted somewhere. Someone else needs to know message semantics and map into the physical implementation of a database and Java classes. A LDM helps to reduce total cost of ownership.

Finally, you should also consider the cons of using the 'pure' top-down approach:

  • Data models may become so tightly coupled with particular business processes that future projects need to modify a LDM significantly.
  • Because business items are highly de-normalized and document centric, straight transformation from business items to a LDM without careful design and normalization could produce a poor LDM.

Bottom-up integration scenario

In the bottom-up scenario, the Rational Data Architect LDM is exported as an XSD, which is then imported as business items in WebSphere Business Modeler. In general, it is preferable to use the bottom-up than the top-down approach because of many benefits coming with the LDM, as mentioned at the beginning of the article. In addition, the bottom-up approach allows the separation of concerns: Business analyst focuses on business process modeling and improvement, and data modeler concentrates to develop an enterprise-wide vocabulary and consistent logical data entities.

Here are the steps for this scenario:

  • Data modeler models data in a LDM in Rational Data Architect. Optionally, data modeler could derive a LDM based on existing database schema, visio, and so on.
  • Data modeler transforms LDM into XSD using the plug-in in Rational Data Architect.
  • Business analyst imports the generated XSD as business items.
  • Optionally, business analyst could also import XSD as a Business Service Object. A Business Service Object is similar to a business item and is used to define the business data that is required when a business service operation is invoked. This option is only appropriate in the case that the business analyst has no need to make modifications to the BSO, as this element is read-only in WebSphere Business Modeler.

The following figure, created in WebSphere Business Modeler, shows the interaction between business analyst and data modeler in the bottom-up scenario:

Figure 4. Bottom-up approach overview
figure4

Consider using bottom-up scenario when combinations of the following conditions are true:

  • LDM is available.
  • Organizations want to de-couple data from business processes and manage data from enterprise-level (for example, master data management).
  • Organizations want to create reusable information services across the enterprise.
  • Multiple initiatives are involved (for example, a business application rewrite and the need to tie into data warehouse). The extra cost of LDM can be more easily shared.
  • Business processes are too complex and frequently in flux. LDM can give a more stable picture.
  • Application is data centric.
  • The project needs to consider, at least in part, existing data sources. This can happen if you have legacy applications, third-party applications, or standards-based interfaces to business partners.

Finally, the 'pure' bottom-up approach also comes with a price:

  • Some semantics may be lost during transformation from LDM to business items because LDM holds richer semantics than business items.
  • Because LDMs tend to be more complete than business items, with more fields or properly normalized entities. If you simply push LDMs into process models without appropriate communication, the details might overwhelm business analysts. If business analyst doesn't understand LDMs, they may end up repeat information and define entities or attributes that are already in LDMs. Thus, proper education and communication between data modeler and business analyst is essential.
  • LDM should avoid being bound by a physical database, an application, or a business unit in order to be a true semantic hub across the enterprise.

Meet-in-the-middle integration scenario

The article previously described both the top-down and bottom-up scenarios, which primarily focus on green-field development. However, change is the only constant in SOA. Modeling business process and data models should rarely be a one-time shot. It's more likely a one-time shot when models sit on the shelf and get quickly out-of-date. To avoid such obsolescence, business process and data modeling needs to be iterative and deliver business value quickly. Thus, the tooling of business process and data modeling should support round-trip capability. For example, changes in business items of the process model can be updated and reflected in a LDM either through automated (for simple changes) or manual (where complex heuristics are required) methods for model convergence.

In reality, it is not an easy task to manage the synchronization and change management of business items in process models and logical data models, as they reside in different tools and are often performed by two distinct roles -– the business analyst and the data modeler. Nevertheless, careful planning, excellent communication, and disciplined change management can make the best out of tooling features and achieve end-to-end data governance.

There are two use cases in the meet-in-the-middle scenario, depending on whether you want to update your business items or logical data models.

First use case: Update business items: Once LDM is imported into WebSphere Business Modeler as business items, business analysts make some changes in the business items (for example, adding new attributes). You want to update Rational Data Architect to reflect modifications in the business items in WebSphere Business Modeler. This use case is very similar to the top-down scenario, except adding the complexity of synchronizing existing LDMs in Rational Data Architect with the new/modified information. Here are the steps in the first use case:

  • Data modeler imports XSD version one, which is exported from WebSphere Business Modeler business items, and transforms it as a LDM (baseline one) using the plug-in in Rational Data Architect.
  • Business analyst modifies business items in WebSphere Business Modeler, then exports the updated business items as XSD version two.
  • Data modeler imports XSD version two and creates a LDM (baseline two) based on it.
  • Data modeler compares and merges LDM baseline one and two in Rational Data Architect.

Second use case: Update logical data models: Once the business items from WebSphere Business Modeler are passed into Rational Data Architect, data modelers perform some modifications in Rational Data Architect (for example, adding new columns). You then want to update WebSphere Business Modeler to reflect modifications. This use case is very similar to the bottom-up scenario, except adding the complexity of synchronizing existing business items in WebSphere Business Modeler with the new/modified information. Here are the steps in the second use case:

  • Business analyst imports the generated XSD version one, which is exported from Rational Data Architect LDM, as business items in WebSphere Business Modeler as base one.
  • Data modeler modifies LDM in Rational Data Architect, then exports the updated LDM as XSD version two.
  • Business analyst imports XSD version two as business items in WebSphere Business Modeler.
  • For entities with the same names, WebSphere Business Modeler will create new business items adding "_1" as a suffix; for new entities, WebSphere Business Modeler will just create the new entities.
  • Business analyst needs to determine which version he wants to keep.

The screenshot in Figure 5 shows business items are suffixed with _1 after importing back from Rational Data Architect using XSD.

Figure 5. Business Items in WebSphere Business Modeler after round-tripping
figure5

A case study on MDD based on LDM

An SOA demands both layered architecture and inter-connection among various layers. Layered architecture allows separation of concerns, and inter-connection enables impact analysis and traceability. The manual approach that relies on unstructured documents, manual discovery, and redundant communication is no longer sufficient to keep up with the pace of rapid application development and business requirements. Thus, it is becoming very important to utilize Model-Driven Development (MDD) to speed up software development in SOA.

IBM SOA Advanced Technologies US Design Center has recently performed an SOA proof-of-concept for a financial services client using ESB to enable business-to-business message routing and transformation. MDD is at the core of this SOA proof-of-concept. The client does not have a well-formed enterprise logical data model. The existing database schema is highly de-normalized, which essentially reflects a message structure. The de-normalization causes difficulty on data retrieval, analysis, and quality control. Fortunately, the client's industry has a set of relatively well-formed, standard message schemas. The IBM team first developed a LDM suitable for the proof-of-concept purpose using best practices in data modeling based on industry standard message schema. The team then reviewed that LDM with business analysts and development teams to ensure the definition and standards of this LDM are consistent with the rest of the organization. Figure 6 shows the model and code transformation steps using Rational Data Architect, WebSphere Business Modeler, and Rational Software Architect.

Figure 6. Use Rational Data Architect, Rational Software Architect, and WebSphere Business Modeler for model-driven development
figure6

Summary

This article provided a high-level overview of WebSphere Business Modeler and Rational Data Architect. You now know when to adopt each integration scenario based on the recommendations in this article. You also know the steps involved in three WebSphere Business Modeler to Rational Data Architect integration scenarios.

WebSphere Business Modeler captures key business information as business items during process modeling. Business items could be a business document, work product, or commodity that is either produced by a task or process (such as an invoice), or causes a process to start (such as a customer inquiry). Business items could become a basis for defining the Logical Data Models (LDMs), if a LDM does not exist for that business domain. Meanwhile, a LDM captures business entities, their relationships, and business rules. A well-formed LDM can provide a quick overview to the key business information in a complex IT environment, which reflects business information requirements. It could outlive many applications, processes, and physical data sources. The precise, complete, and accurate semantics in the LDM is a perfect foundation for business items when an organization takes on a business process modeling endeavor.

Last but not least, it is not enough just to know how to use the tooling to create well-formed business process and logical data models. It is equally important to know the reasons behind adopting a certain scenario, laying out a robust, repeatable change management, and creating a strategy to leverage the synergy of business process and data modeling. Successful business process and logical data modeling often require organizational and cultural changes. The "WebSphere Business Modeler and Rational Data Architect Integration Asset – User Guide" also summarizes some best practices for integrating business process and data modeling (see Resources). This article and the user guide will give you a jump-start to your integration business process and data modeling effort.

Resources

Learn

Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management, WebSphere, Rational
ArticleID=272036
ArticleTitle=Integrate WebSphere Business Modeler and Rational Data Architect
publish-date=04172009