What is a module in Pega Platform?
The Modular Applications and Reusable Features approach is similar to working with classes and functions in traditional programming languages.
In this approach:
- A module is similar to a class
- A feature is similar to a function
A module is a built-on application that contains processes, flows, decisions, data pages, views, and other reusable rules that address a specific business, integration, or utility use case.
You can find more information about this topic in the Module Best Practices course on the Pega Academy website.
When designing a module, it is very important to keep in mind that the module cannot depend on any specific part of the application. It must be self-contained and reusable across different flows, case types, or applications within the organization.
Generally, a module is related to an entity in your case model. For example, Customer could be implemented as a module.
But how can you determine whether something should be a module?
You should analyze the following questions:
- Is it transparent?
- Can it be encapsulated?
- Is it largely self-documenting?
- Is it easy to consume?
- Can it be parameterized?
- Does it provide appropriate flexibility?
- Is it App Studio–friendly?
The main goal of a module is reusability. No matter which case type or application uses it, the module should work independently and be fully parameterized to support different scenarios.
This means that modular applications should not contain business-specific logic, case types, or UI views. Instead, they should contain reusable features.
What are the features in Pega?
Features in Pega Platform work similarly to functions in programming languages.
A feature:
- Receives parameters
- Processes information
- Returns an output
Examples of features include:
- Integration with external APIs
- Business logic evaluation
- Data retrieval services
- Utility processes
It is very important that a feature can work in any application within the organization. This means it must not depend on specific case types, flows, regions, or divisions..
How to build modular applications in pega?
THow to Build Modular Applications in Pega
To build modular applications in Pega Platform, we need to define the application class structure and data model.
Let’s break the process into simple steps.
Step 1: Define the Modular Situational Layer Cake
This design pattern helps organize applications into reusable layers.
The module application should not contain case types. Instead, it should contain reusable processes that function as features.
These features can then be reused anywhere within the organization.
Let’s imagine we are designing an Onboarding application for a banking institution.
We will organize our architecture using the following layers.
Pega platform
This is the base layer of the class hierarchy.It contains all out-of-the-box rules provided by the Pega Platform, including assets required to run and automate the application.
Enterprise
This layer contains assets reusable across the entire organization.
Examples include:
- Shared data types
- Common integrations
- Shared utilities
Example:
A Contact data type that contains:
- phone number
- address
- contact details
This data type can be reused across multiple entities such as:
Related party
Customer
Stakeholder
Module layers
This layer contains the modular applications.
These modules are not part of the class inheritance hierarchy.
Instead, they are added to the Built-On Applications section of an application’s definition.
This allows the business application to reuse all the rules, features, and data objects from the module.
Business applications layer
This layer will contains the application that will have the business logic, case types, validations, stages, process, etc.. all the assets necessary for that application to run, for example on this layer We will define the onboarding application that will contains the case type to onboard a customer we can called it journey, the forms and steps to get all the data, and then we can call the features from the modules to get some information about our customer, generally since the modular application is already added to the built on applications in the onboarding app, this will get access to all the features for the customer module application and to his data objects.
Step 2: Data model design
This step is very important because we want to make sure that all data could be reusable for all the modules, is very important that all stakeholders gets involved in this two steps to align all departments with the business requirements.
object oriented data model, another important point is that in constellation, views are created on the data objects for example you have a form that request all the information about the costumer, this form will be on a view, this view must be on the customer data type to access all his data, doing that you will have the form view in the modular application that can be reused in any application whit in the organization.
there are couple of tools that will help you to design the data model I personally use drawio because is free and very easy to use, at work we use Visio that is a good choice if you have the license because you can design a large data model and can export it I high resolution.
I will give you an example below of a data model design even though there are not complete but it gives you the idea of what you need to accomplished on this stage.
since you already create the customer module you need a data object for that module, in the picture above show a table called customer that will represent the data type for customer in Pega, customer will have some attributes such as Name, Last Name, Accounts.. etc, all the information that we are going to use in forms, features, etc.. must be on customer. then we create a separate table called contact, in this data type we encapsulated the address, phones, emails all the contact information.
We are going to create de contact data type in a enterprise layer, this is because we identify that the contact information can be reused not only in customer, it can be reused in any other application or module that requires this information, lets say that you are building a stakeholder case, and need to capture the contact information, since we create this data object in the enterprise layer, you can create a field on the data object of stakeholder and reference the contact data, with that you will also have access to de views.
Step 3: Identify and Design the features
on this stage you have to identify the features that are necessary for each module, for example if you have the requirement to create an integration that you will send the id of the customer and it will return all the information of the customer if its finds it and if not you will get a response that says customer not found.
So at this point we can identify if it can be a feature because it will receive information, process this information and returns a response, ok where do we put this feature in which module?, since we send information about the customer and receive information about the customer, this feature will need access to the customer data object so consequently it needs to be on the customer module. and that’s how you can define where to create the feature analizing the data that the feature will need and what is the purpose of this feature.
So you can create a miro (is an application that is like a board that you can create bunch of stuff I think is free) with all the stakeholders and start designing all the feature for each module, something that we used to do in this stage is, list all the possible features, lists all the possible modules, and then
the picture above could be an example of the very first stage of designing the features per module, you can listed and just give a brief explanation of what this would do. then when you have all the features already identified you can start designing you case types and journeys.
Step 4 : Create a feature
To create a feature you have to take in mind that will be a process, this process will return some data or do some work in your case type. this feature could be an integration with an API, it could be a data transform that evaluates some business logic and return a response.
To be reusable in any application is necessary that doesn’t depend on any other feature or module, one very important point to take into consideration is the data that the feature needs I has to be created on the module where this feature lives, or any common layer that any application can reference to.
Another Important point is that you have to mark as relevant the process of the feature, this is to be visible on app studio and you can integrate it to the application.
this is what a feature may look like in the design phase
In Pega you will have a process that will call an activity lets called Invokeweatherservice, this activity will be on charge to create the params that the service needs , invoke the service and then returns a response, then on the activity get that response and mapped back to the case
Recap
- Create you modular application for this example I created customer:
- Create customer data model, I created using the ai from Pega and automatically create all the fields I need it
- Crate the feature this feature could be an api, exernal service etc. create a flow and inside this flow call your logic. is very important that mark this flow as a relevant record
- Invoke Customer application in business application for this example I will call it form the application KYC
- add the feature to your case type, click on new process and then create a new process such as getCustomerFeature, then click on add process, since we already marked as a relevant record it will appears on the list even though we cerated in a different application
and that is how you can create a modular application , features and used in a different application. if you came to the end of it please let a comment below if you have any questions, please like and subscribe , I will post a video explaining all this step by step in the upcoming days, thanks for being here
Leave a Reply