What is business process modeling?

A process is a specific ordering of activities with clearly identified inputs and outputs that provide business value. For example, a technical document search process takes a customer's search request from a Web page and produces a list of documents from which one can be selected.

Modeling a process presents significant challenges. Modeling should ensure consistency and thoroughness in capturing relevant information so that both business analysts and the developers can understand the business requirements that are captured in the model. During modeling, alternatives and exceptions to standard procedures must be captured, in addition to normal operations. Professionals with different scopes of interest and expertise can build process models to meet a wide range of business objectives. For example, an analyst requires a high-level view of a process to drive strategic decisions and to do process analysis such as simulation. A developer uses a process model as the input to implement a solution.

An analyst constucts a business process (BP) model based on requirements collected from discussions with the business requirements owners. These requirements are gathered using appropriate tools, such as PowerPoint, spreadsheets, IBM® Rational® Requisite Pro, or any of another set of tools, and when appropriate, the process modeling tool itself. The analyst uses these requirements, together with an analysis of the existing processes, as input to construct the model. Existing process models could be used for analysis of the existing processes or to create new process models by modifying existing models rather than recreating it from scratch.

Modeling starts with the structuring of a BP into sub-processes. Subsequent analysis is done on each sub-process of interest to identify the components, services, data inputs and outputs, policies, and measurements. These elements are encoded into the BP model using the WebSphere® Business Integration Modeler software tool (Business Integration Modeler).

A modeling artifact called a process element is used to define a segment of a BP which is designed to be reusable. A process element is an artifact asset that defines a segment of a process which is designed and managed to be reusable within BP models. They incorporate established series of tasks and decisions, references to data objects, policies, roles, and measurements. For example, a login process element includes a series of activities, the log-in credential data, and log-in rules for completing a user log-in process.

These process elements represent accepted operational practices, which can be reused for similar needs, for example, as a sub-process model to verify and price the contents of a shopping basket.

A service element is a pre-defined service which can be imported in Business Integration Modeler to be integrated in the model. These service elements specify the input, output, and operations of a published Web service. For example, a service element can specify the Web service that exposes a remote parts supplier.

Back to top

Tools for BP modeling

Business Integration Modeler provides business analysts with a tool to model, analyze, simulate, and improve business processes before transforming or exporting them into UML models for Rational XDE or Business Process Execution Language for Web Services (BPEL4WS) for WebSphere Business Integration Server Foundation (Business Integration Server Foundation). We use Business Integration Modeler V5.1 to create BP models and export them to WebShere Studio Application Developer Integration Edition V5.1.1 (Application Developer), as shown in Figure 1.

Business Integration Modeler V5.1 provides a rich set of capabilities for process modeling including a number of graphical and text editors, business operations models (BOM), and a transformation mechanism to convert BOMs to corresponding target platform artifacts.

As Figure 2 shows, an analyst creates various process elements in the appropriate editor (for example, a use process editor for the graphical representation of a BP flow, consisting of activities and the connections between them). These process elements are stored as BOMs in disk files. Business Integration Modeler automatically applies the corresponding validations on the BOM. At a later stage during the model export time, the analyst will apply the correct transforms to convert the BOMs to corresponding target artifacts. Figure 2 also shows four types of artifact exports that are supported:

1. Business Integration Modeler artifacts (Business Process Execution Language (BPEL)+/XML Schema Definition (XSD)/Web Services Description Language (WSDL))
2. FlowMark Definition Language (FDL) for MQ Workflow
3. UML
4. Delimited text

Business process modeling comprises the following:

1. Gather BP requirements.
2. Model business Items.
3. Model roles and resources.
4. Model services.
5. Model policies.
6. Model Key Performance Indicators (KPI).

We will take you through each of these steps in more detail in the following sections.

Back to top

Gather BP requirements

The BP analyst works with the BP owners and domain experts to get all of the information required to build the BP model. For example, the analyst gathers roles, tasks, sequence information, resources, data, narratives, requirements, and so on using appropriate tools and uses them as input to construct the BP model. By creating a model of the process in the Business Integration Modeler, the information that the business analyst captures can be easily exported for the workflow developers to use in the Application Developer tool.

Back to top

Model business items

Business items are business documents, work products, or commodities that are used in business operations. Some examples of business items are order documents, customer address, and bills of materials. An analyst could import a data model defined in XML schema format or could create a new data model using the Business Integration Modeler.

The elements of data modeling include the creation of the following:

• Data catalogs
• Business items
• Business item templates
• Business item instances

Data catalogs are folders used to organize the business items, templates, and item instances. The creation of a data catalog is optional; otherwise the data models can be created in the Business Integration Modeler default Business items data catalog.

The business items are created and added to an existing data catalog. The business item attributes or properties are then added to the business item. For example, we can have an order business item with its attributes such as orderItems and valid. These attributes could be simple types (String, Integer, Boolean, and so on) or could be business items from the same or a different data catalog. For example, an orders business item could include an orderItems attribute of type OrderItem from the same or a different data catalog.

Business item templates enable creating business items with common attributes. The new business item could add new attributes that are not present in the template. For example, you can create an orderItem template with the appropriate attributes and later use that template for the creation of the purchase order and manufacturing bill of materials items without typing the entire orderitem attributes. In addition, you could add appropriate extensions by adding new attributes. For example, you can create a purchase order item by deriving from the orderItem template and then adding additional attributes such as purchase date, location, store, and so on. A business item instance represents a specific occurrence of a business item, for example, an order with a manufacturing number "1xDBCS."

A guide for modeling business items

It is possible to associate rules with the business items and their individual attributes. However, since this feature is currently not supported for BPEL export, it should be documented in the model to assist the developer. We recommend creating the necessary data catalogs and business items as a first step in modeling the process so that they are available to be associated with the tasks.

Create an ordered sequence (array) of business items by setting the minimum and maximum values for the item attributes. Import business items from existing XML schema elements using the XSD import option in the WBI modeler whenever possible. Data catalogs are mapped to java packages and target namespace in XSD schema, hence we recommend the proper use of data catalog names to avoid development problems.

Back to top

Model business roles and resources

Resources represent the people, equipment, or material used to perform a task. Roles add additional characteristics to a resource. For example, an employee resource could have a role of Manager. Roles are assigned to tasks mainly for use in processes that have staff activities. For example, an administrative staff could handle an exception in a task (for example, invalid order, system failure). Process analysis is conducted by adjusting the resource allocations. This analysis provides details on resource utilization levels and helps to calculate the cost and cycle-time. This helps to perform process optimizations and improvements. Also, for workflow, the roles are used to assign people to the staff activities.

Back to top

Model services

In Business Integration Modeler, services are defined as external entities (outside the process being modeled) that can be used from within the organization's processes.

In Business Integration Modeler, you can group sets of inputs as input criteria. Each input criterion defines a particular combination of inputs that can start a process, service, or task. When there is more than one input, the default is an and condition. For the or condition, additional input criteria can be created. Since you are exporting to BPEL, you are restricted to having only one input criterion per element. Similarly, output criteria are used to group sets of outputs. In a Web service WSDL interface model (portType definition) these input and output criteria map to operation input and output messages respectively.

A guide for modeling business services

Even though it is possible to create a number of input criteria and output criteria for each service, it is not allowed in a BPEL model. For BPEL-based executable workflows it is recommended that there be a limit of one input criteria and one output criteria. The WSDL portType operation accepts a single input message and a single output message. Listing 1 shows how input criteria and output criteria are mapped to input and output messages in portType operations.

<portType name="ValidateGenerateTopologyPT">        
<operation name="sendValidateGenerateTopology_InputCriteria">
   <input message="tns:InputCriteriaMessage" 
name="InputCriteriaMessage"/>            
<output message="tns:OutputCriteriaMessage" 
name="OutputCriteriaMessage"/>        
   </operation>    
  </portType>
  					

Currently it is not possible to create a service element by reusing the existing service WSDL. To reuse an existing WSDL requires changes in the generated code. The developer should later associate the correct external services through the BPEL partnerLinks.

Back to top

Model business policies

Analysts might specify the intended policies, but the policies need to be enforced by explicit, executable rules. A policy is typically declarative, for example, "only USA customers can order machine X". Each policy might require one or more enforcement points in the implementation. An enforcement point can be implemented as an explicit step in a process or a specific location in the code. An enforcement point can also occur when processing events. Rules are a useful way to implement a policy enforcement point. A rule is imperative and logically executable. Listing 2 shows an example of a simple rule.

"If !(location(customer) == "USA") then reject(order);"

In some cases, policies are not explicitly stated but are just implicitly defined by an implementation. In other words, the actual set of implemented enforcement points and rules defines the policy.

The analyst documents the policies in the comments field of each task. The developers are responsible for converting the policies to rules. The analyst can add service elements to the model which represent pre-existing services that provide enforcement points. They can also add tasks to represent placeholders for code which will enforce policies. The developer will add the necessary code to implement the task, in other words, execute the correct rules. (See Part 4 of the "On demand business process life cycle" series for details -- see Resources).

Back to top

Model a process

The task of modeling a process consists of defining the details of a business process flow and modeling all the data, resources, and other elements that the flow uses. A business process is composed of process steps that are normally connected through control flows, and these control flows connect activities with decision nodes. A decision node holds the business rules (transition conditions) that are evaluated to decide what path in the process should be followed. Modeling includes the decomposition of a BP into sub-processes and adding required process elements to the model. The analyst can apply pre-existing modeling artifacts (for example, service or process elements) to facilitate and speed-up the construction of the model. The paper "Business process modeling using WebSphere Business Integration Modeler" (part of the "On demand business process life cycle" series) describes how to construct process models from the modeling artifacts (see Resources).

Back to top

Model Key Performance Indicators

Key Performance Indicators (KPI) are measures designed to track the critical success factors of a business. BP monitoring capabilities allow the process owners and administrators to monitor its KPIs in real-time. These capabilities also help the analysts to identify the problems and bottlenecks in the existing processes, thereby closing the development loop as described in Part 1 in this series (see Resources). Business Integration Modeler provides tools to add KPIs to processes to document the critical factors that we intend to track for those processes (see the paper "Business process modeling using WebSphere Business Integration Modeler" for details).

Back to top

Additional modeling guidelines

• There are three modes in Business Integration Modeler: FDL, BPEL, and Operational. If the process is to be executed in Business Integration Server Foundation you should begin modeling in BPEL mode. This helps to view and fix the validation errors in the Error View before attempting to export the model.
• The Advanced Business Modeling user profile should be used to add run-time requirements, such as input criteria for controlling task execution and use of repositories.
• Business Item Modeling Refinements -- business items can be defined without all of the detail and be refined later with more details such as new attributes. They also can be imported from XSD files.
• Fault Handling should not be part of the model, but left to the workflow developer (for example, the handling of service timeouts).

Back to top

Process model validation

Placing the modeler in BPEL mode turns on the BPEL validation checker. Any errors or warnings appear in the Error View. You can filter this list to show errors or warnings and select the level of the model from the entire project down to the selected element only. You can export the model with errors, but these errors should be fixed eventually to prevent reworking future exports.

Back to top

Process model export

The modeler exports the required BPEL, XSD, and WSDL files for the Application Developer tool -- either to an existing service project, or to a folder for later import to a service project.

Figure 3 shows the generated files and the relationship between the process model elements and the corresponding artifacts in the generated files. For example, complex business items are generated as XSD Complex types. It is possible to export the entire business modeling project or a selected portion of the project. Another important option that could be chosen while exporting is the selection of process execution mode. There are three different options available, and the default is Long-running (request-reply)

Process execution modes

While exporting the process model to BPEL based executable workflow artifacts, three execution modes are available:

1. Long-running (receive/reply) -- This option sets the executable BPEL workflow mode to a long-running process and specifies the process operation as a two-way operation with both input and output messages. Long-running processes are interruptible and this enables introduction of staff and other activities that might require interrupting the process execution.
2. Long-running (receive with callback) -- This option sets the executable BPEL workflow mode to a long-running process and specifies the process operation as a one-way operation, which accepts only input messages and no output. However, a callback operation is created to enable the process to return the result to the caller. A BPEL correlation set is created but, no correlation property is added. It is expected that the developer will later add the necessary properties.
3. Microflows -- This option creates workflow process operations which accept two-way messages. However these processes are non-interruptible, so it prevents adding staff activities to the process. If the process model contains tasks with resources and roles based on staff or person, the model exports with staff activities enabled. However, the exported executable model has validation problems which the developer must correct.

Back to top

Conclusion

A business analyst's top-down modeling is a key element of the on demand business process life cycle methodology. The business process model defines the technical framework to align business specifications with IT development. A shared model is preserved over the lifetime of the business process, helping to keep the business and IT views synchronized. This paper introduced some of the concepts of process modeling that analysts use to define business processes using WebSphere Business Integration Modeler V5.1. In addition, it introduced some modeling guidelines and described the various export options in Business Integration Modeler and the generated artifacts which are used as input to the development tools.

Back to top

Appendix

Business Integration Modeler V5.1: Core features

WebSphere Business Integration Modeler V5.1 is an easy-to-use tool designed specifically for business users to capture and document the specific steps of a business process. Included as core features are the following:

User Profiles: Business Integration Modeler provides three different user profiles which allow different views of the same process model with different details. The three profiles are: basic, intermediate, and advanced. These profiles are associated with the roles of the different users. A business domain expert or analyst uses the basic profile which illustrates the business tasks as sequences of activities, while the rest of the model information is captured as documentation. The intermediate profile is more technically oriented with details on data models, expressions, and cardinality information and is more suited for business architects. The advanced profile provides the comprehensive details on the process and data models. This profile is well-suited for solution or IT architects. It should be noted that switching the profile does not change the underlying data model.

Technology Modes: There are three technology modes: operational, BPEL, and MQ Workflow FDL. Based on the technical expertise and the view on the required details, you could switch between the modes. Some options and notational elements can be disabled in some modes, and selecting the appropriate model helps define appropriate artifacts for the target workflow execution environment. Note that switching the modes does not change the underlying data model.

Catalogs: These are a logical grouping of similar modeling entities. These catalogs include the following:

• Data (business items such as order, product)
• Processes (main process, sub process, services, tasks)
• Resources (roles such as customer service representative, sales manager, or resources such as Web server, app server)
• Organization (organization hierarchy, location)
• Report (summary, comparison, documentation)

These groupings increase the reusability of the modeling entities.

Processes: Processes are a sequence of activities, conditions that dictate when these activities will be performed, resources required to perform activities, and the data flows between activities and interaction with services. These processes are modeled using the diagramming notations provided by the tool.

Simulation: Process model simulation helps the organization to observe how a process will perform under the variations of input. This feature provides capabilities for varying the input, associating cost factors, and adjusting the resources/current allocations to simulate a real business scenario. These simulations could enhance the analysis on the critical path, shortest path, cycle time, and cost/time measures about the process model.

Reporting: This feature provides a valuable guidance in process analysis and redesign. There are various reporting features available, including process summary, comparison reports on two process models, comparison on As-Is versus To-Be on ROI measurements, documentations, and procedure (rules, policies and procedures) report.

Analysis: There are two types of analysis that could be performed on a process model: static analysis and dynamic analysis. In the case of static analysis, most of the information is extracted from the model and used to analyze cost, time management, performance, process flow validity, and resource leveling. The dynamic analysis is done on the output from the simulation process based on the output logs or the events. There are two kinds of dynamic analysis: aggregated analysis (based on the from multiple execution of the process model elements) and case analysis (using one instance of execution of a specific sequence of process elements).

Resources

• Read all parts of the On demand business process life cycle series, and keep track as we add new installments.
  
  
• Get the Business Process Execution Language for Web Services, Version 1.1 specification on developerWorks.
  
  
• Read BPELJ: BPEL for Java technology, a whitepaper that explains how the two langugaes can be used together to build business process applications (developerWorks, March 2004).
  
  
• Find out more about WebSphere Business Integration Modeler V5.1 from this FAQ.
  
  
• Browse the WebSphere Business Integration Library.
  
  
• Get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®. You can download evaluation versions of the products at no charge, or select the Linux® or Windows® version of developerWorks' Software Evaluation Kit.
  
  
• Browse for books on these and other technical topics.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  
• The IBM developerWorks team hosts hundreds of technical briefings around the world which you can attend at no charge.
  
  
• Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• What is business process modeling?
• Tools for BP modeling
• Gather BP requirements
• Model business items
• Model business roles and resources
• Model services
• Model business policies
• Model a process
• Model Key Performance Indicators
• Additional modeling guidelines
• Process model validation
• Process model export
• Conclusion
• Appendix
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers