Design approach
To meet a business requirement, a Lead System Architect (LSA) identifies the appropriate Pega Platform™ feature for the functional need. This process includes evaluating Case Types, Stages, Steps, Processes, Subprocesses, Data Types, child Cases, related Cases, and components to design an effective solution. Consider current and future requirements, including performance, scalability, extensibility, security, modularity, time, cost, and effort. Additional factors include user experience (UX), reporting, persistence, locking, integration, and application monitoring.
The LSA must also evaluate available infrastructure and design patterns to make informed design decisions. If functional requirements align with a design pattern, the design decision-making process becomes more straightforward, which leads to time savings. However, a thorough study is imperative if no design patterns align with the functional requirements. This study involves creating multiple approaches, conducting a comparative analysis, and ultimately selecting the most suitable Pega Platform feature for the solution.
Guidelines for identifying Cases
Begin the application design process by identifying the business processes in the scenario. For example, in a Purchase Request Process, a customer selects items from a list and adds the quantity of each item to purchase to a shopping cart. Approvers review the list, and the order proceeds after approval. The process is complete when the requestor receives the items.
You can represent this business process with several Case Type designs:
- A single Purchase Request Case Type for the entire process, with Subprocesses for each line item.
- A Purchase Request Case Type that gathers the initial request and, after approval, initiates a single Purchase Order Case Type.
- A Purchase Request Case Type that gathers the initial request with a Purchase Order child Case Type for each line item.
All provided solutions could be viable initially, but the best solution considers current and potential future requirements to minimize maintenance.
Consider the following factors when you identify Cases:
- Do the Case Types represent the items that need processing? Do they require multiple users to complete the process?
- Is it beneficial to divide the process into multiple Case Types or child Case Types, or are parallel Processes enough?
- If child Case Types exist, does the main Case Type processing depend on the completion of the child Case Types?
- Are there other current or future requirements, such as reporting or security, that can be implemented more effectively by adjusting the Case Type design?
- Are there detailed reporting requirements around Processes that demand separate Case Types or child Case Types?
- Does the Case Type infrastructure (for example, approval, security, or auditing) align with the functional requirements and help achieve the business outcome seamlessly?
Carefully review all influencing factors before making design decisions. In some cases, adding extra Case Types is unnecessary and can result in inefficient resource use and overly complex solutions.
The earlier Purchase Request example illustrates these design considerations:
- If security requirements apply to individual line-item approvals, implement a Case Type with child Case Types for each line item.
- If there is no specific requirement for line-item processing, a subprocess for each line item or presenting a unified view of all line items could be the solution
- Adding a Purchase Order Case Type might not be necessary unless a requirement explicitly states the need for it, such as special reporting requirements.
Check your knowledge with the following interaction:
This Topic is available in the following Module:
Want to help us improve this content?