What is modeling for execution?

IBM® WebSphere® Business Modeler (hereafter referred to as Modeler) provides powerful business process modeling, simulation, analysis, and reporting features to help you optimize the performance of your business processes. Modeler can help with three major tasks:

• Modeling for documentation and compliance: Some companies want to capture a business process just for the sake of documentation, especially if the process is not otherwise well documented and only understood by a few people in the enterprise.

• Modeling for redesign: Some companies want to take their current state (as-is) processes and improve them. For this, Modeler provides a powerful simulation engine to help, along with both dynamic and static reports for defining a future state (to-be) process.

• Modeling for execution: Other companies want to implement a business-driven development cycle, where a business analyst can build a model that is used to create useful artifacts for IT.

Traditionally, Modeler is most widely used for the first two tasks above. With the release of Modeler V6.1 and its improvement in traceability and modeling matched with IBM WebSphere Integration Developer (hereafter referred to as Integration Developer), we are seeing more and more users exploring the third, most difficult task -- and yet the most rewarding usage pattern, since modeling for execution enables faster development cycles, and ensures that the implemented process meets the business requirements.

Back to top

Why is modeling for execution so difficult?

Modeler has different modeling modes. When you perform modeling for documentation, or for analysis and redesign, you typically operate in Basic, Intermediate, or Advanced mode. These modes are product independent. When you perform modeling for execution, you are targeting a specific runtime environment. For example, if you perform modeling for IBM WebSphere Process Server execution, you must be in WebSphere Process Server mode (Figure 1).

This will post some challenges for you: if you are modeling for a particular runtime for execution, you must have intimate technical knowledge of that runtime environment, with regard to its functions and limitations. To elaborate on some of these challenges:

• Some artifacts in Modeler cannot be exported

  Modeler provides an extensive variety of modeling artifacts that are not supported in the BPEL standard, and therefore cannot be exported to Integration Developer. For example, one of the flow artifacts you can't import into Integration Developer is a loopback. The reason for this is that loopbacks are not supported in the WS-BPEL standard, and WebSphere Process Server is based on the WS-BPEL standard. You will need very detailed technical Integration Developer knowledge for a workaround in this situation.

• Some BPEL artifacts cannot be modeled in Modeler

  Similarly, you cannot model some runtime specific artifacts in Modeler either. For example, if you have a process that needs to stop a couple of hours after one activity before continuing forward to the next task, you can model this behavior very easily in Integration Developer with a wait primitive, but you cannot do this easily in Modeler.

• Specify technical attributes for runtime mode

  When in WebSphere Process Server modeling mode, each process diagram has a Technical Specifications tab in the process editor. This tab provides Modeler with a way to define the values for the technical specifications that are needed for implementation and deployment. Options specified here will affect code generation. This requires intimate knowledge of a particular runtime environment, which can pose a challenge for a business analyst who usually doesn’t care much about runtime at all.

• Modeling and design best practices need to be followed

  Most importantly, when modeling for WebSphere Process Server execution, there are additional best practices around BPEL design, SOA services orientation, business object and interface design, and so on, which must be followed. These are definitely something outside of most business analysts' skill set. It would be wrong to think a logical business process created in Modeler by a business analyst will map exactly to one executable BPEL process in a WebSphere Process Server runtime, and so you might need to restructure the logical business process, and convert it to several modular processes according to BPEL design best practices.

Back to top

Proposed roles in modeling for execution

Modeling for execution is a fairly technical endeavor. While some business analysts might acquire some of these skills over time, training them to become familiar enough with all necessary technical nuances is extremely difficult in practice. The following three roles have been identified as being involved in the modeling for execution process:

Back to top

A methodology

After establishing the roles and people involved in the modeling for execution process, you can further break up the process into three phases with associated activities.

Phase I: Create logical business process model and establishing contract

In this phase, the business analyst creates a pure abstract logical business process model in Modeler, with no assumptions made about technical implementations and no changing of the semantics in order to facilitate a hand-off to IT. This model should be sufficiently valid to support optional simulation.

After the business analyst has created the initial logical process model, a process technical architect from IT reviews this model. The architect and the analyst come to agree on the process. At this point, the process is called the business contract, meaning that IT will use the process model as the basis for what they will deliver. If IT were to change what the process does, they would be breaking the contract with the business. However, IT can change the structure of the logical model.

Theoretically, the logical business process model could be created in any tool, but creating it in Modeler will help dramatically in Phase II, since both the business analyst and the technical architect use the same tool, the same notation, and the same modeling language -- which help communicate the business contract more easily.

Phase II: Derive physical business process design model from logical model

After the business contract has been established, the process technical architect can begin to restructure and enhance the logical business model.

The architect has an opportunity at this point to break up the one large logical business process into several smaller physical processes (which will eventually become separate runtime BPEL process), based on some BPEL design best practices. This will be the final physical process design model. At this stage, the process architect will need to design and define the common resources; that is, the interfaces (WSDL) and data types (XSD) of enterprise-wide common services used by the process.

At this stage, you know that the business process will be running in the WebSphere Process Server runtime environment. You should oversee the development of the physical business process design model from the beginning so it is exportable to WebSphere Integration Developer as is:

1. Strip out any Modeler-specific artifacts. For example, if there were mapping nodes in the business model that are known to cause technical implementation challenges, then they should be changed to tasks instead.
2. Apply workarounds to any known limitations, such as the loopback occurrence mentioned above. This also includes all the considerations in WebSphere Integration Developer that cannot (or should not) be modeled in Modeler.

Finally, the process technical architect will annotate the process with technical details. This important technical information is used in code generation when the process is exported to WS-BPEL.

Phase III: Enhancing physical business process design model to the implementation model

After importing the process design model created by the process technical architect, the integration developer needs to enhance the model to the full implementation model. For example, the generated WS-BPEL still needs work if you want to include features such as fault handlers, compensation handlers, QoS elements, and so on. The generated SCA components need additional work before they are ready to be used, but they are generated with the correct interfaces and structures, which simplifies development, and ensures that the needs of the business are met. The integration developer will also add necessary artifacts that cannot be easily modeled in Modeler.

Iterative improvement

With this methodology, iterative development is also possible. The physical design model sits in the middle and tries to fulfill all the business process requirements implied in the logical analysis model described above; at the same time, it follows the best design practices (BPEL, SCA, SOA) for WebSphere Process Server, thus simplifying the realization of the physical implementation model (Figure 2).

Back to top

Summary

The business analyst, process technical architect, and integration developer are all involved in modeling for execution, mainly because, in most cases, the very technical nature of the exercise would make it extremely difficult for a typical business analyst to fulfill alone. It is the process technical architect who plays a central role in this scenario, bridging the logical business model and the final implementation model, making sure the logical model is implement-able, and also making sure implementation model does what it is supposed to do. The process technical architect is a role that must be actively promoted if we intend to make the full business process management lifecycle a reality.

Resources

Learn

• Modeling business process in Modeler for BPEL transformation
  
  
• Using cyclic flows to enable loopbacks in WebSphere Business Modeler and WebSphere Integration Developer
  
  
• Transforming business models to BPEL with WebSphere Business Modeler 6.02
  
  
• IBM WebSphere Business Modeler Information Center
  
  

Get products and technologies

• Download IBM WebSphere Business Modeler trial
  
  

About the author

Peter Xu is a Senior Consultant with IBM Software Services for WebSphere group. Consultants with Software Services for WebSphere help customers deploy IBM products into their organizations. Peter provides consulting services, education, and mentoring on J2EE technologies, and specifically WebSphere and WebSphere Studio products to Fortune 500 clients. You can reach him at peteryxu@us.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• What is modeling for execution?
• Why is modeling for execution so difficult?
• Proposed roles in modeling for execution
• A methodology
• Summary
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Business Modeler Advanced
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Business Modeler Advanced

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers