Business Process Model versus Pega Case Life Cycle Model

Pega 7’s case life cycle modelling tools enable you to quickly model and demonstrate a high-level process design within Pega in front of your customer.

The tools I’m talking about are the life cycle view of a case type and the flow view of a process within a case type. While these are useful tools for the high-level technical solution design and, importantly, getting your customer on-board with that design, I do not see them, strictly speaking, as business analysis tools.

I’ll explain why in a moment but first, let me explain some terminology for new Pega Business Architects.

Case: In Pega terms, a Case ‘delivers a meaningful business outcome to a customer, partner, or internal stakeholder’. If you’re a business analyst new to Pega, this definition might strike you as more akin to the definition of a business process (hover here to see my definition), whereas you might understandably see a ‘Case’ as a container for information, which it is in Pega.

Stage: In Pega terms, a Stage ‘is the first level of organizing work in your case type’. I assume by now you have studied my slide deck on defining process scope, in which case you will know that my first iteration of a process model only addresses the Key Stages of the process. This is the highest level view of how a process breaks down into activities. This is also what Pega calls a ‘Stage’. The only difference is in the naming convention. Pega uses a noun phrase, whereas I use the BPMN convention of modelling key stages as sub-processes, thus I name them with verb phrases.

Process: In Pega terms, ‘processes are organized within [my emphasis] stages and define one or more paths the case must follow’. In other words, in Pega each possible path through a Stage is a separate process. Here is an important difference in language between a business analyst trained in process modelling using BPMN and a Pega business analyst. In BPMN a Stage is a sub-set of a Process. In Pega 7, a Process is a sub-set of a Stage.

Alternate: In Pega 7. the terms ‘alternate’ and ‘exception’ are synonymous. ‘Use alternate stages to organize the process steps used to manage exceptions from the primary path’. To my mind the word ‘alternate’ refers to a different way to achieve your original objective; it’s a deviation from the normal path but you still end up where you wanted to go. An ‘exception’, on the other hand, deviates from the normal path but does not lead you to your desired outcome.

Participant: In Pega 7, a Participant is an actor who performs activities. The term for this in BPMN is Performer. A Participant in BPMN is an entity (external to your process) or another process, that interacts with the process you are modelling.

I’m not pointing out these differences as a criticism of Pega but simply to make you aware of them, so that when you hear Pega Systems Architects using them, you don’t get confused.

The lifecycle view of a Case in Pega 7 is similar to the Discovery Map in Pega 6.

Case lifecycle example in Pega 7

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 if you’re using it to gain an initial understanding of the business process, it is not appropriate. As an analysis tool, it has the same weaknesses as its predecessor, the Discovery Map. In this model, you cannot see 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 (in blue below), what the alternate activities are (in grey) and what the exceptions are (in pink) and then drill down into the sub-process according to your audience.

The high level view of the 'Manage Expense Claim' process in BPMN.

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.

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:

Pega Flow Rule

Here is the corresponding diagram for the ‘Review Expense Claim’ sub-process in BPMN:

Review Expense Claim sub-process in BPMN.

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 ‘Determine Further Review Required’ but 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.

If you are working on understanding the business process, a model in BPMN gives you a much more ‘joined-up’ view. Ideally, by the time you get into the high level design of your Pega solution, the business will have already worked with appropriately experienced business analysts to produce models of their “To Be” business process in BPMN and those models will be the input to your Pega design.

However, if the business does not bring robust process models to the table, my recommendation is that you take some time to work with the business to produce them. In the case of a straightforward process such as ‘Manage Expense Claim’, I  hope you can see that it would only take a few minutes to produce the high-level view of the process in BPMN, so there wouldn’t be a significant delay in producing the Case life cycle model in Pega and you would have more confidence that the model in Pega represented the business need. In fact, one person on the team could model the life-cycle in Pega while the BA models it in BPMN, so there would be no delay at all.

If the business process is much more sophisticated, such as the process to handle a tax fraud case, there is all the more reason to model the process in BPMN because you don’t want to get too far into your technical solution design before discovering that you haven’t understood the business process (or that the business people didn’t explain the process well).

Other advantages of modelling processes in BPMN before (or, less ideally, at the same time as you model the life cycle in Pega):

  • You can show the entire business process and not just the activities that will be implemented in Pega
  • You can show the business events that can impact the process
  • You can show the interactions between your process and other processes / external entities

Don’t forget to attach each version of your business process model to the Specification in Pega that corresponds to your Case Type:

Attachments in Pega specifications

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

Kind regards.

Declan Chellar

Follow by Email

1 comment to Business Process Model versus Pega Case Life Cycle Model

  • Belinda Cowen

    Another excellent article. Wholeheartedly agree with closing comments about BPMN providing the bigger picture. Having previously worked on a Pega implementation involving integration with multiple systems, it was essential to model the overall end to end process, not just the Pega piece. Had I known then what I know now about BPMN and TDM, our process and business rules models would have been very different, and I believe would have led to a more successful and robust solution.

    The other plus point about modelling using BPMN and separate business rules models in parallel with Pega is that you create a technology agnostic set of process and logic artefacts. This makes the process logic/rules more accessible to business and technical stakeholders within and beyond your programme.

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>