Part 1 of this series introduced the concept of business entities (BEs) and provided an overview of holistic approach to modeling business processes with business-significant data. It also introduced Business Entity Definition Language (BEDL), an XML language used to define business entities. Part 2 introduced an extension to BPEL called BPEL4Data and demonstrated how BPEL processes can work with business entities.
In Part 3, we'll use modeling patterns to show how complex, end-to-end operations can be expressed quite elegantly through the combination of business processes and business entities. We'll use the industry standard Business Process Modeling Notation (BPMN) for business process modeling. However, because BPMN today does not support business entities in a first-class way, we will propose an additional notation (and associated semantics).
This article covers the following:
- Description of the sample process
- Proposed BPMN extension to support business entities
- Modeling the process using the extended BPMN notations
- The modeling patterns
The scenario used in this article focuses on a hotel stay. The scope comprises the guest check-in and check-out scenarios, the night audit process for posting room charges for in-hotel guests and Point of Sale (POS) charge handling (services and taxes for the room and additional services used by the guest). In order to design the BPMN process using the business entity (BE) approach we'll need to identify the key business entities, their lifecycle milestones and the process segments that move the business entity instances along their lifecycle.
The first step in creating the process model that uses business entities is to identify the potential BE types. This might be considered the most important step in the design. It's useful to ask yourself the following questions as you consider the key business data in the process.
- Is this entity something your business produces in order to fulfill the overall business objective? Would you be successful without this BE?
- Does the BE, along with its attributes, track against a business goal (for example, as defined through a scorecard)?
- Does the BE cross multiple functional areas throughout its lifecycle?
- Do the milestones within a BE's lifecycle represent meaningful business events?
- Is the BE identified at the right level of granularity to provide the insights the business requires?
For the hotel scenario, we'll use the following BE types. When evaluated against the questions above, these represent the core business entities for the scenario.
- Folio: This is the entity that records and tracks the overall stay of the customer from check-in to check-out.
- Charge: This entity captures all of the information about individual charges made at the hotel (such as room charges, restaurant charges, dry cleaning services, and parking) and the charge lifecycle. Charges are incurred independently, but are ultimately posted to the appropriate guest Folio.
The information model for Folio and Charge has attributes for all of the information that might be accumulated over the lifetime of a Folio or Charge instance. The Folio, for instance includes the Customer profile, holding information such as name, contact information, credit card number, arrival date, departure date, room assignment, and so on.
BPMN provides businesses with the capability of understanding their internal procedures in a graphical notation and gives organizations the ability to communicate these procedures in a standard manner The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts who create the initial drafts of the processes to the technical developers responsible for implementing the technology that will perform those processes.
The current BPMN specification, however, doesn't state how to deal with
business entities in a BPMN process. Though business entities can be
considered as type of
semantically they need to be represented differently and require
additional attributes (like milestones) to qualify as business
To represent business entities, we propose a single additional element, the
Business Entity Milestone. We've denoted the
Milestone element with a rhombus inside the existing data store cylinder
notation in Figure 1, which illustrates the overall
relationship of the Business Entity Milestone element to other
elements and notations in BPMN 2.0.
Figure 1. Process, business entity and data store overall relationship
The lifecycle of each BE is represented in its own "pool." Milestones are laid out in the pool connected by transition lines depicting the legal path the BE can evolve through the milestones. The rhombus box represents the condition on BE data that must be true at that milestone. We decided to put the box inside the cylinder (instead of on the outside), to make it clear that there is only one condition to reach that milestone, regardless of how the business entity arrives at the milestone via any of the potentially several incoming transition lines.
In some sense, the milestones are views of the physical data stores that persist or are the "system of record" of data elements accumulated in the BE. The existing BPMN data store element, shown in the top layer in Figure 1, carries the semantics. When modeling processes with business entities, this element is optional unless you want to also capture the details of the BE milestone mappings onto a persistent store.
The final aspect of the relationship is the process solution, shown in the bottom layer of Figure 1. The process solution includes one or more pools of processes that evolve the business entities through their milestones and are constrained by the overarching BE lifecycle.
In the following sections, we'll look at the usage of the BE Milestone element as part of our Hotel Stay process design.
First, let's look at the lifecycle models for the two BE types – Folio and Charge. As shown in Figures 2 and 3, the lifecycle models comprise a set of business-relevant operational milestones that must be achieved by the BE as it matures through its lifecycle. For the Folio BE, the milestones are Active and Settled, as shown in Figure 2. You also need to specify the conditions (the rhombuses) for each milestone. For example, the Folio is Active when the basic guest information, payment information, room assignment, and so on, have been recorded. Needless to say, detailing the information needed in each milestone has major business implications because it is very helpful in driving cross-functional synchronization and consensus. However, for the sake of brevity and to focus on the main purpose of this article (BPMN modeling notations and semantics), we won't go into any further detail on milestone conditions.
Figure 2. Lifecycle model of the Folio BE
Figure 3 shows the lifecycle model for a Charge. The normal milestones of the Charge BE are Pended and Posted, to reflect a Charge being incurred and then posted to a Folio. However, a Charge could also be Lost or Cancelled to account for exception paths.
Figure 3 Lifecycle model of the Charge BE
Next we'll identify the high-level process segments for the Hotel Stay scenario and describe how the process interacts with the BE lifecycle. Recall that each milestone of a Folio corresponds to a business-relevant operation objective that a Folio instance might achieve. The process model would consist of a series of activities or tasks and, based on the requirements, completing an activity would trigger a milestone transition for the BE or leave the entity instance in the same milestone. For example, the process of checking in a guest would move the Folio to the Active milestone.
Based on the Hotel scenario, we come up with the following processes segments:
- Check-in process
- Room charge process
- Point of sales charge process
- Night audit process
- Check-out process
Figure 4 shows the BPMN model for the Check-in process.
Figure 4. Check-in process
The check-in process consists of a human task activity called Check in guest. The check-in process is initiated by the front desk role. After the check-in activity is completed, an instance of the Folio BE is created and persisted in the data store. The Folio BE milestone is marked as Active after the check-in activity is completed.
The data flow line "carries" the Folio data object. However, the Active annotation on the data object means that the data object is carrying necessary and sufficient information to satisfy the condition for the Folio in the Active milestone.
Figure 5 shows a snippet of the BPMN model for the Room Charge process.
Figure 5. Room Charge process snippet
Note: To keep the process illustrations simple, we show only the relevant data objects annotated with the BE milestones for the remaining processes. The full set of data flow interactions is shown in the integrated model.
The Room Charge process is used by the hotel to determine all occupied rooms for the night and create a room charge for each guest. This process is instantiated with a time trigger and scheduled to run late every night.
The Room Charge process consists of a Create Room Charges task. After this task is completed, many instances (indicated by the dotted lines on the data flow object) of the Charge BE are created in the Pended milestone.
Figure 6 shows a snippet of the BPMN model for the POS Charge process.
Figure 6. POS Charge Process snippet
The POS Charge process consists of three activities: the Create POS charge task, the Settle check task, and the Calculate tax and post subprocess. The Create POS Charge activity is initiated by the POS role when then guest or walk-in customer incurs a charge, such as eating in the restaurant. Once the Create POS Charge activity is completed, the Charge BE moves to the Pended milestone and a reference to the Charge BE is passed on the control flow to the next task, Settle Check.
Calculate Tax and Post is a system-executed subprocess that calculates the tax and either posts the charge (moves the BE to the Posted milestone) or marks the charge as lost (moves the BE to the Lost milestone). We won't elaborate on the Calculate Tax and Post subprocess, but the logic is essentially (a) try to match the Charge to an active guest Folio (note the input from the Folio Active milestone). If the guest cannot be found, mark the Charge as Lost. Or, (b) compute the tax and post the Charge to the guest Folio.
Figure 7 shows a snippet of the BPMN model for the Night Audit process.
Figure 7. Night Audit process snippet
The Night Audit process is initiated under certain conditions, or rule triggers. The Validate PMS (Property Management System) Ledger Totals with POS (Point of Sale) Totals activity is a human task activity that is worked by the night auditor role. The night auditor is responsible for conducting audits and generating reports for hotel room management. The night auditor validates the charges and cancels or posts the charges correspondingly. The night auditor process handles multiple charge instances in the above example.
The check-out process, shown in Figure 8, consists of a Check-out human task activity. The Check-out process is initiated by the front desk role. After the Check-out task is completed, the Folio milestone is marked as Settled and persisted in the data store.
Figure 8. Check-out process snippet
Combining all of the above process snippets, Figure 9 shows the complete integrated model for the Hotel Stay process. This model follows the relationship pattern we described earlier - a set of process pools interacting with a set of BE pools. The BE pools (Folio and Charge) show the milestones and the valid transitions. The process pools (Check-in, Check-out, Room Charge, POS Charge and Night Audit) show the set of activities that "pick" (essentially copy via the data flow object) one or more business entities from particular milestone stores, work with the data and then "drop" onto another (or the same) BE milestone store. The "drop" connection data flow object to the particular BE milestone store, of course, has to meet the milestone condition.
The process pools are the same as those in the regular BPMN semantics. What we have added is the BE pools to specify the BE lifecycle milestones and transitions.
Figure 9. The Hotel Stay integrated model
In this section, we'll look at some of the common modeling patterns you can use for modeling the BE as part of a BPMN model. Based on these patterns, you can generate corresponding user interface patterns, which can be used for quick validation of business design.
In a control flow pattern, all tasks are performed sequentially and the BE undergoes a milestone change as part of the process activity. This is the most commonly used pattern. Figure 10 shows the typical model of a control flow pattern. When Task 2 is started, business entity 1 is in Milestone1; when Task 2 is completed, BE 1 changes to Milestone2. In this the kind of pattern, typically the same instance of the BE is being processed.
The Point of Sale process segment of the Hotel Stay scenario is an example of this pattern.
Figure 10. Control flow pattern
In the Hybrid or Business Object Lite (BO-Lite) pattern, the reference of the BE is passed between two tasks. Figure 11 shows the typical model of the Hybrid or BO-Lite pattern.
When Task 1 completes, BE 1 changes to Milestone1 and is persisted to an external data store. When Task 2 starts, there is a sequential flow from Task 1 to Task 2 and Task 2 pulls BE 1 in Milestone 1 and starts working. What flows on the control flow is just a reference to BE 1, not the entire BE. Task 2 retrieves the BE from the external store using this reference. This kind of pattern is typically used when you don't want to pass the entire BE data or milestone information along the control flow or store it in process variables, instead only a reference can be passed.
Figure 11. BO-Lite (Pass by reference) pattern
In the Synchronization pattern, the task waits for a milestone transition to occur before it can be started. Figure 12 shows a typical example of the Synchronization pattern.
Figure 12. Synchronization pattern
When Task 1 is completed it stores BE 1 in Milestone 1 into an external data store. The next step in the task is the control flow to the Synchronized Task. This Synchronized Task, although enabled and started, cannot complete because there is a constraint that BE 1 should be in Milestone 2. There could be some other process executing in its own thread or started by a different trigger that is responsible for changing the milestone of the BE 1 to Milestone 2. This kind of pattern is used in cases where a task has to wait for some other process to complete in order to execute.
In this pattern, end-to-end operations are modeled as process fragments and business entities are used to broker and stitch these process fragments. As seen in Figure 13, Process Fragment 1 and Process Fragment 2 are full-fledged processes that can start and end on certain events. The business entities in their respective milestones are used to stitch together these process fragments. The process fragments can in turn work with any number of BE instances, picking and dropping from their respective milestone buckets.
Figure 13. Fragmented Processes pattern
The integrated Hotel Stay process is a good example. It showed how multiple process fragments can be stitched together around the milestones of the Folio and Charge business entities.
The Case Handling pattern indicates that different processes can work on parts of the same BE instance without stepping on each other. This pattern is used to model typical case handling scenarios. As seen in Figure 14, the BE is the Case, which has a lifecycle model with the milestones, Milestone 1 and Milestone 2. When the Case is in Milestone 1, a number of processes could be working on it simultaneously. Figure 14 shows shows two processes working on two different parts of the same Case instance. These processes can start and end arbitrarily without any defined sequence, and work on parts of the Case in an ad hoc manner. The processes can work on the Case in Milestone 1 and put it back in the data store once they're done, as long as the Milestone 1 conditions are not violated). Another process also works on other parts of the Case. It detects that the work has progressed to a sufficient extent, satisfying the conditions needed for Milestone 2, thus moving the Case from Milestone 1 to Milestone 2. The pattern continues with a different set of processes being triggered when the Case is in Milestone 2 and then working on maturing the Case further in its evolution.
Figure 14. Case Handling pattern
As described in Part 1 of this series, complicated end-to-end business processes can be easily modeled using the combination of business entities and process segments. The BE view does not take away the need for detailed task modeling. However, it helps the modeler focus on the key goals enabled by the process, in terms of BE milestones and the information needed in the milestones. This helps break down complexity into bite-size chunks, which can then be addressed through traditional activity-based process design and implementation.
- See Part 1 for a complete list of resources for more
Process Model and Notation (BPMN) web site
developerWorks BPM zone: Get the latest technical resources on
IBM BPM solutions, including downloads, demos, articles, tutorials,
events, webcasts, and more.
Journal: Get the latest articles and columns on BPM solutions in
this quarterly journal, also available in both Kindle and PDF versions.
Prabir Nandi is a Research Staff Member in the Business Services Department at the IBM T. J. Watson Research Center. He is an inventor of the business entity (BE) concept and has led its continued research and development for the last several years, including the now commercially available Business Entity Lifecycle Analysis (BELA) and Business Value Modeling (BVM) capabilities as part of IBM Global Business Services method and tools.
Vlad Klicnik is a Senior Technical Staff Member at the IBM development lab in Toronto, Canada. He is currently part of the IBM BPM Product Design and Architecture team. Prior to his current role, Vlad was one of the lead architects responsible for the implementation of the converged IBM Business Process Manager solution, a successful blend of the Lombardi Teamwork environment and WebSphere Process Server. His other work included product architecture roles on WebSphere Business Modeler, and WebSphere Integration Developer. Vlad was also one of the founding members responsible for the design and development of the Eclipse platform (eclipse.org).
Stephen A. White, Ph.D., is a BPM Architect at IBM. He has over 25 years of process modeling experience, ranging from modeling pilot workload to commercial business processes, and has been involved in most aspects of business process modeling software, from product management, design, consulting, training, and technical writing. In the last few years, he has been active in the development of business modeling standards, was the primary editor of the BPMN 1.0 and BPMN 2.0 specifications. He is currently a designer for the IBM Business Process Manager product.