Case design

The first step of the case design activity in the Prepare phase is to review the Case Type Backlog and create the case type for each Microjourney^™ that has been prioritized for the Minimum Lovable Product (MLP). This is important to ensure what you plan to build makes sense.

The objective of the case design activity is to:

• Create the foundation case types and the associations between them in preparation for the Build phase
• Validate the functional scope of the Microjourney with the product owner
• Ensure that the case design applies best practices from the start

Using Directly Capture Objectives (DCO), the business architect, systems architect, and product owner collaborate to model the case type into stages and steps. This activity breaks down the case type into its component parts.

Once the steps and stages have been agreed with the product owner, further discussions define the personas involved in the case type, and the data objects you need to complete the processing. At the end of the DCO sessions, you have a visual representation of the case type to be validated by the product owner.

To ensure case design best practices are adopted from the start, the system architect (SA) leads the technical design aspects of the case type within the DCO session.

The SA makes sure that case design takes into account:

• Workflow
• Personas and Channels
• Data
• Reuse
• Scale

In the following image, click the + to learn more about case design stages and steps.

The combination of stages and steps determines the case workflow. In most businesses, there are several combinations of work:

• Some work may be executed in sequence.
• Some work may be conducted in parallel.
• Some work may be optional; applicable only under specific conditions.  

At the start of the project, the different types of work influence your case design. Based on findings from workshops with the product owner, the lead system architect (LSA) considers the technical best practice. Where appropriate, they may decide to create additional case types (for example, to enable parallel work through the means of child cases).

Another case design consideration is work allocation, which is discussed and agreed on early in the project. Work allocation defines the way work is directed to the personas that are linked to the case type. Defining the work allocation model requires understanding the business operating model.

There are two models for work allocation:

• Push model: In a push model, the system or a team manager manually assigns work to the appropriate user.
• Pull model: In a pull model, the user is assigned work automatically based on a set of business rules.

Using the Pega Express^™ approach, personas are associated with stages within a case type to represent the persona's interaction during the case. Personas are also associated with channels to indicate how the persona can access the application (for example, by email or by using a self-service webpage). 

Because Pega Platform can associate a persona with a channel, you can cater to channel-specific user interface (UI) and processes to create a user experience that is appropriate to the particular situation.

As part of the DCO sessions run during the Prepare phase, the product owner and business architect (BA) map the personas to the stages to ensure that business scenarios are covered within the scope of the case type. As part of these discussions, it is important to understand what type of interactions can be formed by the persona within a specific channel. For example, it may be possible to create a claim through a self-service channel, but not by email. 

Security by persona and channel

Access rights to both the data and the processes are also defined for the case type. Access rights can impact the design of the case type in several ways, for example:

• Exclude work/data from specific channels
• Separate work into different stages within the case type
• Create an entirely new case type  

Based on the security requirements, the SA must decide on the case type design to meet the security needs.

At the start of the project, you need a high-level understanding of the data objects linked to the case type to ensure the design accommodates the data needs. 

For each data object the system architect must understand the following;

• Availability and Timeliness
• Retention and Archiving 

The availability of data refers to the source of the data. Some data may be available from external systems. Users may directly capture other data, and some data may not be available; it must be created during the case's progression. Timeliness of the data is how quickly the data can be retrieved from other systems and how frequently the data changes.

With the ever-increasing awareness of data privacy requirements, the client's data retention rules directly influence the data modeling activity associated with the case design. Identifying these rules upfront requires the SA to design the case type to optimize the management of data within the case. 

Example: A bank workflow might capture the bank details at the last possible moment in the case to avoid holding bank information until necessary. Additionally, the workflow might need an automatic step to remove bank details after there is no longer a legitimate business reason to retain the data.

At the start of the project, identify the key areas in the case type that may be useful to other case types or later MLPs. This gives the SA information to guide the case design activity during Prepare to support re-use of the case type as a whole, or parts of the case type (for example, specific processes, data, and the user interface). The best practice is to identify business and technical commonalities. Then, specify and design the commonalities as rules or components for use across multiple case types.

Consider the frequency and volumes of the cases when designing the case type for scale. The scale also considers the interaction of the personas with the case type. 

Different team members use scale to design the case type:

• The product owner and BA review the workflow to decide on what levels of automation to implement in the case type.  
• The system architect considers the mechanisms of accessing and storing data within the case type.

Where cases frequently occur and in large volumes, focus on the case design to maximize straight-through processing to achieve the best possible throughput in the shortest time.   

Recognizing the case volume drives the initial design conversations to consider the data needs associated with case types. This recognition highlights the changes necessary to the initial case modeling to ensure that data access is efficient and streamlined, avoiding undue strain on interfaces and response times. 

During the Prepare phase, note these aspects as user stories and add them to the backlog for further elaboration during the project. 

Check your knowledge with the following interaction.