Comment lines: Modeling for execution, revisited

The modeling for execution technique has been used frequently in business process management (BPM) solution design. This article highlights some evolution in the thinking of how to apply this concept in successful BPM project deliveries. This content is part of the IBM WebSphere Developer Technical Journal.

Share:

Peter Xu, Senior Managing Consultant, EMC

Author photoPeter Xu is a Senior Managing Consultant with IBM Software Services for WebSphere, working directly with IBM's largest customers and helping them design and deploy SOA-based solutions on broad range of IBM Software offerings. Peter specializes in business process analysis, modeling for execution and end-to-end BPM solutions. Peter is an OMG-Certified Expert in BPM (OCEB Business Track Advanced).


developerWorks Contributing author
        level

14 April 2010

Also available in Chinese Spanish

Modeling for execution & BPM

An earlier article from 2008 discussed modeling for execution methodology in the context of IBM® WebSphere® business process management tools. A follow-on article in 2009 talked about the improvements in the V6.2 release of IBM’s BPM stack products, which make process modeling for execution easier. Now, in 2010, with some real implementation experiences in the field and some new emerging industry standards in business process management, it’s time once again to revisit this topic.

What is modeling for execution?

Modeling for execution is not a new concept, as this approach has been used in traditional software and system development for a while. This technique always starts with a high level platform independent model (PIM) that is often expressed in some visual language. This model might then be translated or transformed into a platform specific model (PSM) in a particular programming language for a particular platform, which then can be compiled or interpreted for execution. In fact, this methodology uses the principles of Object Management Group’s (OMG) Model Driven Architecture (MDA). Figure 1 depicts the relationship between the models.

Figure 1. Model transformation
Figure 1. Model transformation

The model-driven architecture starts with the well-known and long established idea of separating the specification of the system’s operation from the details of how that system uses the capabilities of its platform. The three primary goals of MDA are portability, interoperability, and reusability through architectural separation of concerns.

BPM solution delivery is a new business-driven and process-centric way of delivering applications. It can and should use the best practices we have learned over decades of software development and system engineering. MDA principles can certainly apply here, but because BPM solution delivery is unique in that it puts more emphasis on iterative business design and requires more involvement of business users and analysts, there are special considerations when adopting modeling for execution techniques.


Applying modeling for execution with WebSphere BPM

Many companies have been using modeling for execution methodology and techniques for solution delivery based on the WebSphere BPM product suite. Figure 2 illustrates the typical transition from business model to technical business model to implementation model.

Figure 2. Business model to implementation model
Figure 2. Business model to implementation model

Figure 2 shows three phases:

  • A business analyst or business process architect creates a business model in IBM WebSphere Business Modeler in either the Basic or Advanced mode. The business model graphically represents the business process and uses semantics relevant to business analysts and subject matter experts. The business model might also be used for simulation.
  • A technical business analyst or technical process architect refines the model in IBM WebSphere Process Server mode, producing a technical business model that graphically represents the business process for implementation and begins to translate the business semantics into technical semantics. The technical business analyst exports the technical business model from WebSphere Business Modeler as a project interchange file, which is a .zip file containing all the run time artifacts that make up the implementation model.
  • A process architect or integration developer imports the implementation model into IBM WebSphere Integration Developer. The implementation model graphically represents the business process to be implemented. The integration developer further refines the model and completes translating the business semantics into technical semantics.

The important thing to notice here is that while working inside WebSphere Business Modeler, the underlying models are represented as a modeler specific business object model (BOM) process model. When you export the model as a project interchange file, these BOM process models are transformed to BPEL process models, which are the semantics you work with in WebSphere Integration Developer.


Improving the development process

Users have had some success with delivering WebSphere BPM solutions using the modeling for execution approach, especially in the area of service-oriented and integration-centric processes. This is achieved by using BPEL as the underlying platform specific model (PSM) transformed from the business process model. BPEL is an open industry standard and a proven process orchestration language, with particular focus on Web service integration. Many companies have mission-critical process applications based on BPEL running in production, offering the required transaction integrity, security, and performance.

While the current WebSphere modeling for execution approach offers robust solutions from a run time perspective, there is room for improvement on the development process side, particularly in the area of model synchronization in iterative development.

Figure 3 depicts how this situation is tackled now in the current tooling.

Figure 3. Iterative development process with WebSphere BPM tooling
Figure 3. Iterative development process with WebSphere BPM tooling

As you can see, this can be a fairly complex process, and can involve several manual steps which, simply by their nature, can be error-prone. Practical user experience also suggests this approach can be challenging for frequent and large sets of changes, widely known as the "roundtriping problem." Of course, this situation is not at all unique to the WebSphere BPM stack. Model synchronization will always be a challenge whenever you perform model transformation between different domains with different semantics.

Some best practices have emerged for modeling for execution. One is to minimize changes to the business logic module in WebSphere Integration Developer, which represents the business model. Because the elements in the business logic module map directly to elements in WebSphere Business Modeler, you should make your changes in WebSphere Business Modeler. In particular, you should minimize structural changes to your processes.

Recommendations like these can be helpful in minimizing the need to perform model synchronization, but they will not totally eliminate this need, which leads us to an alternative approach.


The shared model and Lombardi approach

Lombardi Software, a leading provider of BPM software and services that was acquired by IBM at the beginning of this year, has a different approach to modeling for execution in that it retains the same form of the model through the process lifecycle. Figure 4 depicts the architecture of the Lombardi Teamworks BPM suite.

Figure 4. Lombardi Teamworks modeling for execution approach
Figure 4. Lombardi Teamworks modeling for execution approach

As shown here, all process elements defined in Teamworks are stored in a single Shared Model, representing every element of a process, from process diagrams to business data, user interfaces, and system integration. With the Shared Model architecture, changes made in one process element are (depending on access privileges) immediately visible and accessible to other process elements. This provides instant visibility to interdependencies between process elements, which enables better communication between process designers and contributes to better process quality.

Why is this important to modeling for execution? Since the business modeler and developer (as depicted in Figure 4) work on the same shared underlying process model -- just from different views and perspectives -- the model will never be out-of-sync, and the roundtripping problem is gone! This paradigm would encourage more iterative and agile development, with close collaboration between business stake holders and IT.


Conclusion

We now have two different strategies to modeling for execution:

  • Transforming models for optimized run time behavior.
  • Sharing model across the process lifecycle.

Which is better? The answer will always depend upon what kind of business processes you are implementing and what factors are most important to you, such as support for agile and iterative development, support for round-trip, run time robustness, continuous process improvement, ease of use to encourage business/IT collaboration, and so on.

Hopefully, this information will help you expand your thinking and decision process in selecting the right methodology and tools for your particular needs.

Resources

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 Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere
ArticleID=481999
ArticleTitle=Comment lines: Modeling for execution, revisited
publish-date=04142010