In Part 1, we went through some of the key terms Pega terms in Case Life Cycle modelling. Here, in Part 2, we’ll compare modelling a Case life cycle using Pega 7’s modelling tool with BPMN 2.0.
The life cycle view of a Case in Pega 7 is similar to the Discovery Map in Pega 6.
However, other than the sequence of the three primary stages, it is not possible to show the flow of the life cycle in Pega 7. If you are using it as a high-level technical solution design tool, that’s fine, but it conceals too much of the process flow to be useful in gaining (and displaying) an initial understanding of the business process. As an analysis tool, it has the same weaknesses as its predecessor, the Discovery Map. In this model, it’s not explicit that ‘Review Claim (2)’ is actually an alternate path. Moreover, while you can see that ‘Approval Rejection’ is an alternate stage, you cannot see where it branches from the primary.
Using BPMN, however, you can see at a glance the high-level view of the entire life cycle, what the key stages are, what the primary path is (which I have marked in blue below), what roles are involved, what the alternate activities are (in grey) and what the business exceptions are (in pink) and then drill down into the sub-process according to your audience.
Even with this high-level overview of the business process, you can start to build test scenarios to make sure the process works at a business level before implementing anything in Pega. I’m a big fan of testing the business logic before you implement, so that when you test the software, you are testing only that the software works and not that the business logic makes sense.
Notice that I have re-used the sub-process “Review Expense claim”. Any differences can be handled by alternate paths in the child diagram or in the logic of any decision points in the child diagram. In the Case Life Cycle Model, such re-use is not obvious, nor even suggested. The fact that “Review Claim (1)” and “Review Claim (2)” are labelled differently means they are different processes in Pega.
In Pega 7, you can model the flow of a particular path through a particular Stage (remember, this is what Pega calls a ‘process’). Take the ‘Review Claim (1)’ process from the Pega life cycle model above, for example:
Here is the corresponding diagram for the ‘Review Expense Claim’ sub-process in BPMN:
I’m sure you can see that if you gave that diagram to Pega developers instead of a textual use case, they would find it much easier to understand what flow to build.
This sub-process diagram covers both Pega processes “Review Claim (1)” and “Review Claim (2)”. How? By handling the difference inside the decision logic for the task “Determine Further Review Required”. In essence, one of the factors taken into account by the logic is the user’s business role; if it is “Director”, then a further review is not required.
Note: in Pega flows, the diamond shape represents a Decision Rule that holds the implementation of the decision logic. In BPMN, the diamond shape (called a ‘gateway’) simply interrogates the outcome of the decision logic, while a model of the logic itself sits in a Decision Model behind the corresponding ‘business rule’ task (in this case, ‘Determine Further Review Required’).
Here’s an important point for traceability: I would add a Specification in Pega of type User Story to represent any atomic tasks in the BPMN model. In the case of ‘Determine Further Review Required’ the actual business logic I would model and test in a Decision Model of the same name. The logic (business rules) in the Decision Model would essentially be the requirements. Neither a Process Model nor a Pega Specification is an appropriate mechanism for modelling business logic. Any Decision Rules in Pega could be traced back to the Decision Model via the relevant Specification and the ‘Determine Further Review Required’ activity in the Process Model.
I hope you have found this post useful. Thanks for taking the time to read it. For bonus points, have another look at the second BPMN diagram above (click here if you don’t want to scroll back up) and tell me:
- Why I assigned the Business Rule type to the task ‘Determine Further Review Required’
- Why I assigned the Service type instead of the Send type to the ‘Notify Employee’ tasks
In Part 3, we’ll consider when you should and should not use Pega’s Case Life Cycle Design tool to model the business process.
Kind regards.
Declan Chellar
Related posts:
Leave a Reply