Design patterns

Enterprise application development should prioritize the adoption of design patterns. Using the latest technologies and best practices, including intelligent automation and AI-driven decision-making, is essential to achieving enhanced agility, efficiency, and scalability. Furthermore, adopting design patterns accelerates the development process. Pega assists Pega Lead System Architects (LSAs) in rapidly adopting AI, automating processes more intelligently, and delivering outstanding user experiences. Additionally, the Pega Platform architecture supports the adoption of design patterns in application development, creating robust structural elements for the application.

As a Pega LSA, employing design thinking techniques at the onset of application design is essential. This involves breaking down customer journeys into smaller, manageable segments known as Microjourneys®, implemented using the Pega Express™ delivery methodology. Refer to the discussion at Pega Express Values and Best Practices.

Selecting the appropriate architecture and application stack is vital for achieving scalability, maintainability, and efficiency. Application design patterns offer a systematic approach to addressing common design challenges. These patterns streamline development processes, improve modularity, and enhance system resilience.
In Pega Platform application development, adopting a microservices-oriented approach is advantageous. This approach can be implemented using key design patterns tailored to optimize Pega's capabilities. These patterns guide developers in structuring applications that handle complex business processes efficiently while remaining flexible and responsive to changes in business requirements.
The concept of Microjourneys within a microservices-oriented approach can be implemented using the following design patterns:
•    Divide and conquer
•    Straight through processing
•    Remote case processing

 Divide and conquer

Divide and conquer is a well-recognized computational problem-solving algorithm. This algorithm divides tasks into smaller, independently solvable units, which can be further broken down. It is a powerful algorithmic paradigm that addresses problems by recursively breaking them down into smaller units until they are simple enough to be solved directly. The solutions to these smaller units are then combined to form the solution for the overall business problem.
A significant advantage of the divide-and-conquer approach is that sibling units can be developed and processed in parallel, reducing the overall time required to complete the work compared to sequential processing. This approach also offers greater opportunities for reuse.
In Pega applications, the divide-and-conquer strategy is effectively implemented through the concept of Microjourneys. Individual small applications are combined to form the final end-user application by using multiple built-on applications.

Straight through processing (STP) 

Straight Through Processing (STP) is a design pattern in software engineering aimed at automating and streamlining processes by eliminating manual intervention. It focuses on creating an end-to-end automated flow where data or transactions are processed without human touch, from initiation to completion. This leads to increased efficiency, reduced errors, and faster processing times.
Pega LSAs can use Pega GenAI capabilities to implement the STP design pattern in application development. Some possible solutions using the STP design pattern are:

• Processing payments, securities trading, and loan applications.
• Automating patient registration, claims processing, and medical record management.
• Order processing, inventory management, and shipping.
• Automating procurement, logistics, and warehouse operations.

Remote case processing 

Pega Remote Case Processing enables case workers to handle cases from multiple applications within a single application context, eliminating the need to switch between different systems. This functionality enhances efficiency and provides a seamless user experience by enabling case workers to perform their tasks without logging in and out of various applications.
Pega Platform supports the implementation of the Remote Case Processing design pattern using Remote Case Types. Read more about it on Remote Case Types

For example, consider a CSR who handles financial operations for VIP customers. The CSR typically manages loan requests, mortgage requests, and credit card operations, which are spread across different applications. With Pega Remote Case Processing, you can create a VIP financial operations application to consolidate these cases. The CSR can then process loan requests, mortgage requests, and credit card operations within a single application, significantly reducing the time spent switching between applications and increasing productivity.

When designing the structural elements of an application, the focus shifts from architecture to the optimal use of technical capabilities and flexibility to implement Microjourneys, which become the structural elements of the enterprise application. In Pega applications, structural elements can include Case Types, Data Types, Child Case Types, Child Processes, Stages, Steps, or any other components that form part of the application. The concept of Microjourneys within the context of structural elements of the application can be effectively implemented using the following design patterns:

• Case instance first
• Data instance first
• Data instance only
• Limited availability and concurrency

Case instance first 

The case-instance-first design pattern in Pega Platform™ is similar to the object-action interface for core programming languages. In this design pattern, you perform an action on an existing object.
The case-instance-first design pattern is observable in scenarios where the context of a case instance is crucial for carrying out specific actions or transactions. For example, consider a Purchase Order (PO) process. In this context, creating a PO is necessary to start subsequent actions, for example, approval and billing. Therefore, both approval and billing actions are carried out within the context of the purchase order case, demonstrating the application of a case-instance-first design approach. This pattern ensures all necessary actions align contextually with the case instance, promoting a coherent and efficient workflow.

Data instance first 

The data-instance-first design pattern demonstrates how data related to a Case persists before the Case is created. For example, if you use a Web embed, it is unnecessary to create a Case immediately. Instead, you can persist Case data before creating the Case. In this example, a mashup interface is configured as a Display a page action instead of a Create a new Case action.

If the process involves the capture and persistence of data by a single actor, then the data-instance-first design pattern is the best method to apply. You can use the Pega landing page concept to capture data.

Data instance only 

The data-instance-only design pattern shows that some functional requirements need capturing of the data and persisting in the required format at the required location. Other objects can reference and process the persisted data.

For example, consider a functional requirement to capture and display the office locations of a global mobile sales and service company. Office administrators can add, delete, modify, or update office locations whenever the company extends or changes its service locations. According to the business scenario, office location is an important attribute that customers must select when raising a service request. Office location contributes to the calculations of service fees and taxes to pay for the services used. You can implement this business scenario with a data-instance-only design pattern.

Limited availability and concurrency 

The limited-availability-and-concurrency design pattern is a variant of the object-action approach pattern. This design pattern is useful in solving race-condition problems. When you have limited resources and many concurrent requests racing to secure them, it is essential to ensure that resources are used efficiently without overbooking or overusing them.

The simplest solution to the race condition problem is for a requester to acquire a lock on the resource, update the resource, and then release the lock. The next requester in the queue will then acquire the lock. If resources are still available, the next requester can use them; otherwise, the process will end.

In Pega implementations, acquiring a lock can be applied to both case types and data types. If you require case management capabilities like routing and SLAs, implement limited availability and concurrency using case types. Otherwise, the simplest approach is to use data types by acquiring a lock on the concrete data type to avoid simultaneous updates.

Check your knowledge with the following interaction: