 | Level: Intermediate Mei Selvage (meis@us.ibm.com), Data Architect, SOA Design Center, SOA Advanced Technologies, IBM
Ray W. Ellis (rayellis@us.ibm.com), Senior Software Engineer, SOA Design Center, SOA Advanced Technologies, IBM
Daniel T. Chang (dtchang@us.ibm.com), Senior Software Engineer, Information Management, Data Tools, IBM
29 Nov 2007 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.
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.
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
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
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
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
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
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
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
- "WebSphere Business Modeler and Rational
Data Architect Integration Asset – User Guide"
(IBM, 2007): Find step-by-step guidance on installing and using the IBM Rational
Data Architect XSD-LDM transformation plug-in.
-
"Achieve
Semantic Interoperability in a SOA"
(developerWorks, June 2006): This article unveils the mysteries of semantic
interoperability in a SOA context. Walk through the semantic spectrum, and then
discover the anti-patterns, patterns, and best practices of semantic
interoperability.
-
"Integrating
Rational Software Architect with Rational Data Architect"
(developerWorks, August 2007): Get a quick overview of Rational Software Architect
and Rational Data Architect. This article outlines the high-level steps in three
Rational Software Architect to Rational Data Architect integration scenarios, and
discusses the UML-to-LDM and the LDM-to-UML transformations as well as the UML
Logical Data Model profile.
-
developerWorks Information Management zone:
Learn more about Information Management. Find technical documentation, how-to
articles, education, downloads, product information, and more.
- Stay current with
developerWorks technical events and webcasts.
-
Technology bookstore:
Browse for books on these and other technical topics.
Get products and technologies
-
IBM Rational Data Architect XSD-LDM transformation plug-in: Convert
RDA logical data models to and from XSD files. Since WebSphere Business Modeler
business items and business service objects can be exported as and imported from
XSD files, this plug-in makes it possible to integrate Rational Data Architect and
WebSphere Business Modeler.
- Build your next
development project with
IBM trial software,
available for download directly from developerWorks.
Discuss
About the authors | 
| | Mei 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 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 is a senior software engineer at IBM Silicon Valley Lab. He has been with the RDA Core team since 2006. |
Rate this page
| |
