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.
Here, in Part 1, I explain some terms for BAs who may be new to Pega.
Case Type
You may think this is analogous to a business entity, especially when you see examples of Case Type names as noun structures, e.g.: Expense Claim, Vacation Request, Loan Application, Customer Order, etc.. The reason we use noun structures in data models and business glossaries is to emphasise the static nature of the model and to allow us to fully understand what something is separately from how we process it. However, the Pega glossary definition of a Case Type uses the language of process: ‘A case type represents work in your application that follows a life cycle, or path, to completion‘ (the bold type is my emphasis).
If you’ve taken the Pega BA training course, you may remember the training material says: ‘A case type is a type of artifact in Pega used to define the tasks and decisions needed to resolve a case’ and ‘Case types model how and when work gets done‘ (the bold type is my emphasis). Pega also says a Case ‘delivers a meaningful business outcome to a customer, partner, or internal stakeholder’.
If you’re a business analyst new to Pega, these statements might strike you as more akin to definitions of a business process (hover here to see my definition), whereas you might understandably think of a ‘Case’ as a business entity. Indeed, the Case Designer in Pega is essentially a tool for designing the high-level implementation of a process. So when you are discussing Case Types with your team, be aware that it has a data model aspect (the What) and a life cycle aspect (the How). That Pega wraps the what and the how together in the Case Type has an impact on how you choose to model the business, as I shall explain in Part 3.
Stage
In Pega terms, a Stage ‘is the first level of organizing work in your case type’. You may by now 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 similar to what Pega calls a ‘Stage’. One main 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.
Another important aspect of a Stage in Pega is that each stage typically represents tasks performed by a different role. For example, an expense claim can go through submission, review and payment stages, with the Case assigned to a different role at each stage. At the very least, a Stage is one or more Processes (see below) that must be completed before then next stage can begin, even if only one role is involved.
This concept of a Stage in Pega is inseparable from the concept of a Case. This also has an impact on how you choose to model the business.
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. Be aware that many software developers only use ‘exception’ to mean technical exceptions (e.g., what to do when a particular system doesn’t respond to a request), rather than business exceptions.
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 to make you aware of them, so that when you hear Pega Systems Architects using them, you don’t get confused.
In Part 2, I’ll compare Pega’s Case Lifecycle Model with BPMN 2.0.
Kind regards.
Declan Chellar
Related posts:
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.