Pega Application Architecture – Part 3: Data Type & Data Architecture
In Part 1, we designed the overall application architecture for Nexus, Alpha Bank's banking application. In Part 2, we went one level deeper and designed the Case Type architecture.
Now we move to one of the most important parts of any enterprise Pega application: how we design, model, access, cache, secure and maintain business data.
Using our Alpha Bank example, we will understand the difference between a Case, a Data Object / Data Type, a Data Page, a Data Transform, an external System of Record, and the integration layer that connects them.
Pega Application Architecture – Part 3: How Data Types, Data Objects, Data Pages, Systems of Record, Data Transforms and integrations work together in Alpha Bank's Nexus banking application.
1. Why Data Architecture Matters in Pega
A Pega application is not only about Cases and workflows. Almost every Case depends on business data.
Consider a simple Alpha Bank scenario.
John starts a Customer Onboarding Case in Nexus.
The Case may need:
- Customer information
- Address
- Phone and email
- Existing accounts
- KYC information
- Identity verification results
- Risk information
- Products selected by the customer
- Branch information
- Documents
The important architecture question is: Should all of this data be copied into the Case?
In a well-designed enterprise application, the answer is usually no.
We need to determine:
- What is Case data?
- What is reusable business data?
- Where does the authoritative data live?
- How does Pega retrieve it?
- How long should Pega cache it?
- Who can access it?
- How is it updated?
- What happens if the external system is unavailable?
That is the purpose of the Data Architecture layer.
2. Start With the Alpha Bank Business Data
Before creating Pega Data Types, we first identify the business entities that exist in Alpha Bank.
For our Nexus application, some important business entities are:
Customer ID, name, contact details, status
Account number, type, status, balance
Product code, name, category, eligibility
Address lines, city, state, ZIP
Verification status, risk indicators
Transaction ID, amount, date, status
Branch code, name, region
Risk classification and indicators
These are not automatically Case Types. They are business entities used by multiple business processes.
3. Data Object vs Data Type – What Is the Difference?
Pega terminology can sometimes be confusing because projects and documentation may use the terms Data Object and Data Type in closely related ways.
In current Pega terminology, a Data Object represents a business entity, while the Data Type represents its technical structure, including its fields and data definition. Pega Academy also notes that the terms are often used interchangeably in projects. :contentReference[oaicite:1]{index=1}
Think about it this way:
Business meaning: Customer
Technical definition: Customer fields and their types
Runtime access:
Data Page such as D_Customer
For Alpha Bank, we can model:
Customer ├── CustomerID ├── FirstName ├── LastName ├── DateOfBirth ├── Email ├── Phone ├── CustomerStatus └── BranchCode
The important design principle is: model the business entity once and reuse it.
4. Case Data vs Business Data
This is one of the most important architecture decisions.
A Case represents a business process or transaction. A Data Object represents a business entity.
| Case | Business Data |
|---|---|
| CustomerOnboarding | Customer |
| LoanApplication | Customer, Account, Product, Credit information |
| CardRequest | Customer, Account, Card Product |
| AddressChange | Customer, Address |
Do not create duplicate Customer fields independently inside every Case Type just because several Cases need customer information.
Instead, create a reusable Customer Data Object and provide controlled access to that data through Data Pages.
5. Alpha Bank Data Class Structure
In Part 1, we established an important naming rule:
Alpha is the organization namespace.
Nexus is the application/product name.
Therefore, Nexus does not appear in our Pega class names.
Our Data layer can therefore follow the Alpha Banking namespace:
Alpha
└── Alpha-Banking
├── Alpha-Banking-Work
│ ├── CustomerOnboarding
│ ├── LoanApplication
│ └── AccountOpening
│
├── Alpha-Banking-Data
│ ├── Customer
│ ├── Account
│ ├── Product
│ ├── Address
│ ├── KYC
│ ├── Transaction
│ └── Branch
│
└── Alpha-Banking-Int
├── Customer
├── CoreBanking
├── KYC
├── AML
└── CreditBureau
Therefore, an example Customer Data class can be:
And an Account Data class:
6. Designing the Customer Data Object
Let's take the most important banking entity: Customer.
Suppose Alpha Bank needs the following information:
| Field | Purpose | Example |
|---|---|---|
CustomerID |
Unique customer identifier | C100234 |
FirstName |
Customer first name | John |
LastName |
Customer last name | Smith |
Email |
Primary email | john@example.com |
Phone |
Primary phone | 555-0101 |
CustomerStatus |
Current customer status | Active |
BranchCode |
Home branch | NY001 |
These properties form the structure of the Customer Data Object.
The important point is that the Case does not need to redefine this structure every time it needs Customer information.
7. Data Page – The Runtime Gateway to Data
Now we reach one of the most important Pega concepts in the data architecture: Data Pages.
A Data Page provides on-demand access to data and separates the business process from the details of where that data comes from. Pega caches Data Page contents in memory according to its scope and load/refresh configuration. :contentReference[oaicite:2]{index=2}
For Alpha Bank, we can have a Data Page such as:
Conceptually:
The Case does not need to know whether Customer data comes from:
- A REST API
- A database
- A Pega database
- A report
- Another enterprise service
- Multiple aggregated sources
The Data Page provides that abstraction.
8. Data Page – Rule-Level Configuration
In Dev Studio, a Data Page is configured with several important characteristics.
The major design decisions include:
- Object Type – What business entity does the Data Page represent?
- Structure – Does it represent a single object or a list?
- Edit Mode – Read-only, editable, or savable depending on the use case.
- Scope – Thread, Requestor or Node.
- Data Source – Where does the data come from?
- Load / Refresh strategy – When should cached data be considered stale?
These are core Data Page configuration concepts documented by Pega Academy. :contentReference[oaicite:3]{index=3}
Example – D_Customer
| Name | D_Customer |
| Object Type | Customer |
| Structure | Page |
| Mode | Read-only example |
| Parameter | CustomerID |
The exact configuration should be based on the business requirement, data volatility, sharing requirement, and performance characteristics.
9. Single Data Page vs List Data Page
Alpha Bank will need both individual records and collections.
| Requirement | Example | Concept |
|---|---|---|
| Retrieve one customer | Customer ID = C100234 | Page |
| Retrieve multiple accounts | Accounts belonging to customer | List |
| Retrieve products | Savings / Checking / Loan products | List |
10. Parameterized Data Pages – A Critical Enterprise Pattern
Imagine that Bob is processing a CustomerOnboarding Case.
Bob needs customer information for customer C100234.
Instead of creating separate Data Pages such as:
D_Customer_C100235
D_Customer_C100236
we design one reusable Data Page:
The parameter identifies which customer is requested.
This is especially important when the application processes many Cases and many customers.
Parameterize reusable data access instead of creating one-off data retrieval rules for every Case.
Pega's current Live Data guidance also highlights the importance of considering parameter cardinality because unique parameter combinations can result in separate Data Page instances. :contentReference[oaicite:4]{index=4}
11. Data Page Scope – Thread, Requestor and Node
Scope determines how broadly a Data Page instance is available. Pega supports Thread, Requestor, and Node scopes. :contentReference[oaicite:5]{index=5}
| Scope | Concept | Alpha Bank Example |
|---|---|---|
| Thread | Available within the current thread | Customer-specific information used only by the current transaction |
| Requestor | Shared across the requestor's threads | Data that can safely be reused within the user's requestor context |
| Node | Shared on the current node | Relatively stable reference data such as a product catalog |
Scope is a data-sharing and caching decision. If the data is user-specific or changes frequently, broader sharing can introduce incorrect or stale data.
12. Where Does the Data Actually Come From?
A Data Object defines the business data. A Data Page defines how the application accesses that data.
The underlying source can be different.
Pega Data Pages support data sources such as Data Transforms, Activities, Connectors, Report Definitions, database lookups, robotic automation and other supported sourcing mechanisms. :contentReference[oaicite:6]{index=6}
For Alpha Bank, the source depends on the domain.
| Data | Possible System of Record | Pega Access |
|---|---|---|
| Customer | Customer platform | D_Customer |
| Account | Core Banking | D_Account |
| KYC | KYC provider/platform | D_KYC |
| Credit Information | Credit Bureau | D_CreditProfile |
| Products | Product platform | D_Product |
These system-of-record names are illustrative for our Alpha Bank architecture. The actual enterprise would define the authoritative system for each business domain.
13. Pega Is Not Automatically the System of Record
This is an important architecture distinction.
Nexus may orchestrate a Customer Onboarding process, but that does not automatically mean Nexus owns the authoritative Customer record.
Pega owns:
- Case lifecycle
- Workflow state
- Assignments
- Case-specific information
- Business process orchestration
Enterprise systems may own:
- Customer master data
- Account balances
- Transactions
- Credit information
- KYC records
- Card information
The exact ownership must be defined by enterprise architecture, but the principle is extremely important: do not create accidental duplicate systems of record.
14. Data Transform – Mapping Data Between Models
External systems rarely use exactly the same field names or structure as the Pega Data Object.
For example, Alpha Bank's Customer service might return:
{
"cust_id": "C100234",
"fname": "John",
"lname": "Smith",
"email_addr": "john@example.com"
}
But our Pega Customer Data Object may use:
CustomerID FirstName LastName Email
A Data Transform can map the external representation into the Pega application model.
Conceptual mapping:
.CustomerID = .cust_id
.FirstName = .fname
.LastName = .lname
.Email = .email_addr
The exact implementation depends on the connector and the response/request model, but the architectural principle remains: keep the external API contract separate from the business data model used by Nexus.
15. Alpha Bank Example – Customer Onboarding
Let's put everything together.
John starts a CustomerOnboarding Case in Nexus.
The Case needs Customer information.
Instead of directly calling the Customer system from the UI, the architecture can look like this:
CustomerOnboarding Case
│
▼
D_Customer(CustomerID)
│
▼
Data Source
│
▼
Customer Integration
│
▼
Customer System of Record
│
▼
Response
│
▼
Data Transform
│
▼
Customer Data Object
│
▼
CustomerOnboarding Case
The Case is therefore insulated from the details of the external Customer system.
16. Why the Case Should Not Directly Know the Integration Details
Suppose the Customer system changes from one REST service to another service.
If the CustomerOnboarding Case directly contains all the connector details, the workflow becomes tightly coupled to the external system.
With a Data Page abstraction, the Case continues to ask for:
The underlying sourcing implementation can change without changing every Case that consumes Customer information.
Pega Academy explicitly describes Data Pages as a way to separate business processes from integration details and the underlying data source. :contentReference[oaicite:7]{index=7}
17. What If Alpha Bank Needs to Update the Data?
So far we have mostly discussed reading data.
But suppose Mary processes an AddressChange Case and updates the customer's address.
The architecture must now answer:
- Where is the authoritative address stored?
- Is Pega allowed to update it?
- Which system receives the update?
- What happens if the update fails?
- Should the Case wait for confirmation?
Pega supports Savable Data Pages for scenarios where changes need to be persisted back to a data source through a configured save plan. :contentReference[oaicite:8]{index=8}
Mary changes John's address.
Nexus updates the appropriate Customer Data Object through the supported Data Page/save mechanism.
The authoritative Customer system receives the update according to the enterprise integration design.
18. Data Page Refresh Strategy – Freshness vs Performance
Caching data improves performance, but cached data can become stale.
Imagine Bob opens a LoanApplication Case and retrieves a customer's credit information.
If the credit information changes externally, Bob should not automatically continue using an old value simply because it was cached.
Pega provides Data Page refresh strategies to determine when cached data should be considered stale and reloaded. :contentReference[oaicite:9]{index=9}
How fresh does this particular piece of data need to be?
Different Alpha Bank data has different freshness requirements.
| Data | Typical Volatility | Architecture Consideration |
|---|---|---|
| Product Catalog | Low | Broader caching may be appropriate |
| Customer Profile | Medium | Balance reuse with freshness |
| Account Balance | High | Avoid inappropriate stale-cache assumptions |
| Credit Information | Context dependent | Define business freshness requirement |
Pega Academy emphasizes that refresh design requires balancing processing cost against the risk of stale data. :contentReference[oaicite:10]{index=10}
19. How I Decide the Data Page Scope
There is no universal rule that says every Data Page should be Node scope or every Data Page should be Thread scope.
I would ask four questions.
One Case? One user? Multiple users?
Static, occasional, or constantly changing?
Can it safely be shared across the intended scope?
How expensive is it to retrieve the data?
Scope is therefore both a data-sharing decision and a performance/caching decision.
20. Data Architecture and Security
Data architecture cannot be designed separately from security.
Alpha Bank handles sensitive information such as:
- Customer identity information
- Account information
- Financial information
- KYC information
- Credit information
- Transaction information
Therefore, simply placing data behind a Data Page does not mean the data is automatically authorized for every user.
The security architecture from our earlier Security series still applies:
Data architecture defines how the application gets the data. Security architecture determines whether the user is allowed to access or act on that data.
21. Data Architecture and Performance
A poor Data Architecture can become a major performance problem.
Consider a Case screen that needs:
- Customer
- Accounts
- Products
- KYC
- Credit profile
- Branch information
If every field causes a separate synchronous call to an external system, the Case can become slow and fragile.
1 Case → 20 fields → 20 separate external calls
Multiply that by hundreds of concurrent users and the integration layer can become the bottleneck.
Case → reusable Data Pages → appropriate caching/refresh → controlled integration calls.
The exact design depends on data freshness, concurrency, source-system limits and business requirements.
22. What Happens When the Data Source Is Down?
Enterprise data architecture must also define failure behavior.
Suppose John starts CustomerOnboarding and
D_Customer attempts to retrieve his profile.
The Customer service is unavailable.
The application should not simply display an empty customer record and allow the process to continue as if the customer did not exist.
We need to distinguish:
- Technical failure
- Timeout
- Authentication failure
- Authorization failure
- Business-level failure
- Customer not found
- Temporarily unavailable service
The Case Type should then have an intentional business response:
- Retry where appropriate
- Route to an exception path
- Place work into background processing when appropriate
- Notify the user
- Record the failure
- Prevent incorrect business decisions
23. One Data Object Can Support Multiple Case Types
This is where reusable Data Architecture becomes valuable.
The same Customer Data Object can be used by:
This prevents every Case Type from independently defining its own version of Customer.
Pega Academy describes Data Objects as reusable building blocks that can be used by multiple Case Types. :contentReference[oaicite:11]{index=11}
24. Data Object Inheritance
Suppose Alpha Bank has common Person information.
We could conceptually have:
├── Customer
└── Employee
Common attributes such as name, email and phone can be defined at the appropriate reusable level, while specialized entities can contain their specific properties.
Pega supports reuse of Data Object structure through inheritance, where child Data Objects can extend fields from a parent object. :contentReference[oaicite:12]{index=12}
Use inheritance when there is a genuine business relationship and meaningful reuse.
25. Thinking About the Data Model Visually
Once the Data Objects and Case Types are identified, we can understand the relationships between them.
↓
Customer
↓
Account
↓
Product
Customer
├── Address
├── KYC
└── RiskProfile
Current Pega capabilities also provide Visual Data Model views that show how Case Types and Data Objects relate within an application. :contentReference[oaicite:13]{index=13}
26. Rule-Level View of the Data Architecture
Here is the important part for developers and Pega architects.
| Pega Concept | Role in Alpha Bank |
|---|---|
| Data Object / Data Type | Defines reusable business entity structure |
| Data Class | Owns the data entity's rule-level structure |
| Data Page | Provides reusable access to the data |
| Data Transform | Maps data between structures |
| Connector | Communicates with an external service |
| System of Record | Authoritative enterprise source for a business domain |
| Case Type | Uses business data to execute a business process |
27. Complete Alpha Bank Runtime Flow
Let's follow the entire request from the user to the data source.
John ↓ Nexus ↓ CustomerOnboarding Case ↓ Customer Data required ↓ D_Customer(CustomerID) ↓ Data Page checks available/cached data ↓ If required → Data Source ↓ Customer Integration ↓ Customer System of Record ↓ Response ↓ Mapping / Data Transform ↓ Customer Data Object ↓ Case uses required data ↓ Business processing continues
This is the architecture we want developers to understand: the Case consumes business data without becoming tightly coupled to the physical source of that data.
28. Common Data Architecture Mistakes
Creates duplication and synchronization problems.
Creates tight coupling and repeated integration logic.
Can expose inappropriate sharing or stale data.
Cached data can become stale.
Can create ownership and synchronization problems.
Makes the model difficult to understand and maintain.
Adds complexity without meaningful reuse.
Excessive synchronous calls can become a production bottleneck.
29. Troubleshooting Data Problems in Pega
When a Case is showing incorrect or missing data, do not immediately blame the UI.
Trace the complete data path.
A practical troubleshooting sequence is:
- Confirm the correct Data Object.
- Confirm the Data Page name.
- Verify the Data Page parameters.
- Check whether an existing cached instance is being reused.
- Check Data Page scope.
- Check refresh/load strategy.
- Verify the configured data source.
- Verify the connector or database request.
- Inspect the external response.
- Verify Data Transform mapping.
- Confirm the Case is consuming the expected property.
30. My Practical Approach to Data Architecture
When I design a new Alpha Bank Case Type, I would not start by creating properties randomly on the Case.
I would follow this sequence:
What Case are we building?
Customer? Account? Product? KYC? Transaction?
Which enterprise system owns each entity?
Establish the reusable business structure.
Define how the application retrieves or saves the data.
Decide how data is identified and shared.
Determine acceptable stale-data limits.
Decide who can read or update the data.
Timeout, retry, exception, fallback and business response.
Calls, latency, caching, concurrency and external capacity.
31. The Data Architecture Mental Model
If you understand this chain, you can understand a large portion of Pega's enterprise data architecture.
32. Interview Question – Explain Data Architecture in Pega
Question: How would you design data architecture for a large Pega banking application?
Answer:
"I would start by identifying the business entities and their ownership rather than putting everything directly on the Case. For Alpha Bank's Nexus application, entities such as Customer, Account, Product, KYC and Transaction would be modeled as reusable Data Objects/Data Types. I would then use Data Pages as the application's reusable access layer to retrieve or save those entities from the appropriate systems of record.
For each Data Page, I would determine the structure, parameters, scope, sourcing mechanism, refresh strategy and error handling. I would also separate the external integration contract from the Pega business data model using appropriate mappings such as Data Transforms. Finally, I would consider security, data freshness, caching, external-system capacity and performance.
This allows the Case Types to focus on business process orchestration while the Data layer provides reusable and controlled access to enterprise data."
33. Data Architecture – The Big Picture
At this point, our Nexus architecture has three important layers.
Application
Nexus defines the banking application and its reusable application architecture.
Case
Case Types such as CustomerOnboarding and LoanApplication orchestrate business processes.
Data
Data Objects, Data Pages and integrations provide reusable access to business information.
The next architecture level is where we go deeper into how Nexus communicates with external enterprise systems.
Key Takeaway
A strong Pega Data Architecture is not about creating as many Data Types or Data Pages as possible.
It is about creating the right separation between:
- Business entities
- Case data
- Systems of record
- Data access
- Integration contracts
- Caching and refresh
- Security
- Performance
In our Alpha Bank Nexus architecture, Case Types own the business process, Data Objects define reusable business entities, Data Pages provide controlled access to those entities, and enterprise systems remain authoritative for the domains they own.
What's Next?
We have now covered the first three architecture levels:
No comments:
Post a Comment