![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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
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 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
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
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.
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.
- IBM WebSphere Business Process Management Information Center
- IBM
developerWorks WebSphere Business process management zone
- Phases of modeling for iterative development
-
Recommendations for iterative development
-
Model-Transformation vs Model-Preservation
-
Lombardi BPM resources
-
IBM developerWorks WebSphere
Peter 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).
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
