Pega Application Architecture – Part 1: Designing Alpha Bank Nexus
A deep, rule-level walkthrough of how we design a real-world banking application in Pega using Alpha Bank Nexus as our example.
When people hear Pega Application Architecture, they often immediately think about Applications, Rulesets, Classes, Case Types, Data Types and Integrations. But before creating any of those rules, we need to answer a more important question: What are we actually building?
In this series, we will design a realistic banking solution from the ground up. Our fictional bank is Alpha Bank, and the enterprise Pega application we are building for the bank is called Nexus.
Nexus is not the Core Banking system. Instead, it is the Pega application that orchestrates customer and banking operations, manages business processes, coordinates data and integrations, enforces security, and provides a consistent experience for bank employees and customers.
Alpha Bank Nexus: End-to-end Pega application architecture from business capabilities and application hierarchy to classes, cases, data, integrations, security and runtime execution.
1. What Are We Building?
Let's start with the business problem rather than with Pega rules.
Alpha Bank is a fictional enterprise bank with multiple banking capabilities: customer onboarding, account management, lending, cards, KYC, AML, fraud review, customer service, notifications and other shared banking services.
The bank does not want each department to build a completely separate workflow solution. Instead, it wants a reusable enterprise application that can orchestrate these processes while integrating with the bank's existing systems.
Our Application
Organization: Alpha
Application / Product: Nexus
Business Domain: Banking
Purpose: Customer and banking operations orchestration
The most important point is that Nexus is the application name, not part of our class naming convention.
Therefore, we don't create classes such as:
Nexus-Customer
Nexus-Loan
Nexus-Work-Loan
Instead, our enterprise namespace is based on Alpha and the banking domain:
Alpha-Banking-Work
Alpha-Banking-Data
Alpha-Banking-Int
2. Start With Business Capabilities
Application architecture should begin with the business capabilities the application needs to support.
For Alpha Bank, Nexus supports several major business areas.
Customer onboarding, profile maintenance, KYC and customer updates.
Account opening, maintenance, closure and account services.
Loan applications, credit review, approvals and servicing.
Card requests, replacement, activation and maintenance.
KYC, AML, fraud investigation and regulatory processes.
Service requests, inquiries, disputes and customer support.
Notice that these are business capabilities, not Pega Case Types yet. We first understand the business and then decide which capabilities should become Case Types, reusable components, Data Types, integrations or shared services.
3. What Exactly Is Alpha Bank Nexus?
Alpha Bank Nexus is the Pega implementation application for Alpha Bank's customer and banking operations.
It provides the workflow and orchestration layer between the people who perform banking work, the business rules that determine how work should proceed, the data required to process that work, and the enterprise systems that own the underlying information.
↓
Pega Experience / UI
↓
Case Management & Business Processes
↓
Data Access & Business Rules
↓
Integration Layer
↓
Enterprise Systems
This distinction is important because Pega does not automatically become the System of Record for every piece of banking information.
For example, the Core Banking system may remain the authoritative source for account balances, while a Customer Master or CRM may own customer information. Nexus orchestrates the business process and retrieves the information it needs.
4. Application Hierarchy – Where Does Nexus Fit?
Now we move from business architecture into Pega application architecture.
Nexus should not contain every reusable banking capability directly. We separate reusable enterprise capabilities from banking-specific capabilities and implementation-specific behavior.
Base platform capabilities
Enterprise-wide reusable capabilities
Reusable banking capabilities
Alpha Bank implementation application
Think of the hierarchy as a capability-sharing model.
- Pega Platform provides the underlying Pega capabilities.
- Alpha-Enterprise contains capabilities that can be shared across enterprise applications.
- Alpha-BankingFramework contains reusable banking capabilities.
- Nexus implements the specific customer and banking processes for this application.
5. The Rule-Application Rule – The Starting Point
In Pega, an application is represented by a Rule-Application rule. This rule defines the application context and its relationship with the applications on which it is built.
For our example, conceptually we have:
Application: Nexus
Built on: Alpha-BankingFramework
Built on: Alpha-Enterprise
Base: Pega Platform
The application rule is not itself a Case Type, Data Type or Integration. It provides the application context in which those rules are developed and executed.
Why does this matter?
Suppose a developer opens a Flow, Data Transform, Section or Decision Table. Pega needs to know the application context in which that rule exists. That context affects which Rulesets and Rules are available and how dependencies are resolved.
6. Work, Data and Integration – The Core Separation
One of the most important architectural decisions in Nexus is separating:
Work
Business processes, Case Types, assignments, stages, SLAs and workflow behavior.
Alpha-Banking-Work
Data
Business entities such as Customer, Account, Product, Loan and KYC.
Alpha-Banking-Data
Integration
Connectors, request/response mappings and integration-specific rules.
Alpha-Banking-Int
This separation is not just about naming. It gives us a clear ownership model.
A developer looking at a Case Type should not have to search through integration rules to understand the business process. Likewise, an integration developer should not need to modify Case-specific rules to change an API mapping.
7. Enterprise Class Structure
Now we reach one of the most important concepts in our architecture: the class structure is different from the application name.
Our organization is Alpha. Our business domain is Banking. Our application is Nexus.
Therefore, our primary business class hierarchy can look like this:
Alpha
└── Alpha-Banking
├── Alpha-Banking-Work
│ ├── CustomerOnboarding
│ ├── AccountOpening
│ ├── LoanApplication
│ ├── CardRequest
│ └── FraudReview
│
├── Alpha-Banking-Data
│ ├── Customer
│ ├── Account
│ ├── Product
│ ├── Loan
│ ├── Card
│ └── KYC
│
└── Alpha-Banking-Int
├── Customer
├── CoreBanking
├── KYC
├── AML
└── CreditBureau
8. Work Classes – Where Business Processes Live
The Work portion of the class structure represents the business processes that Nexus manages.
For example:
Alpha-Banking-Work-CustomerOnboarding
Alpha-Banking-Work-AccountOpening
Alpha-Banking-Work-LoanApplication
Alpha-Banking-Work-CardRequest
Alpha-Banking-Work-FraudReview
These classes can own the behavior associated with their respective Case Types:
- Stages
- Processes
- Assignments
- Flow Actions
- SLAs
- Case-specific validation
- Case-specific business rules
- Case security
- Case lifecycle behavior
We should not put every banking process into one giant class such as
Alpha-Banking-Work.
The parent class provides common behavior, while specialized Case Types inherit or specialize
where appropriate.
9. Data Classes – Separate Business Entities From Work
A Customer is not a Case. An Account is not a Case. A Product is not a Case.
They are business entities that Cases work with.
Alpha-Banking-Data-Customer
Alpha-Banking-Data-Account
Alpha-Banking-Data-Product
Alpha-Banking-Data-Loan
Alpha-Banking-Data-Card
Alpha-Banking-Data-KYC
For example, a CustomerOnboarding Case may use Customer, Address, KYC and Document data.
The Case represents the work being performed. The Data Objects represent the business information involved in that work.
"Open a new account for this customer."
"Here is the customer's profile and account information."
10. Integration Classes – Keeping External Communication Separate
Nexus will interact with many enterprise systems.
Examples include:
- Customer Master / CRM
- Core Banking
- KYC provider
- AML / sanctions service
- Credit Bureau
- Card Management System
- Document Management
- Email / SMS services
These integrations should not be mixed directly into every Case Type. Instead, we isolate integration-specific rules under the integration layer.
The Customer Onboarding Case should not contain the complete implementation details of the KYC provider API.
The Case requests KYC verification through a reusable data/integration abstraction. The integration layer handles the external communication.
11. Rulesets – Organizing the Application
A Pega application is not simply a collection of random Rules. Related Rules are organized into Rulesets.
For Nexus, we can logically organize Rules into areas such as:
| Ruleset | Purpose |
|---|---|
| AlphaBanking | Application-specific banking behavior |
| AlphaBankingInt | Integration-related Rules |
| AlphaBankingCommon | Reusable banking functionality |
| AlphaBankingSecurity | Security-related Rules |
The exact Ruleset decomposition should be driven by ownership, reuse, deployment and maintainability requirements. We should not create dozens of Rulesets simply because we can.
12. Ruleset Stack – Why Order Matters
This is where application architecture becomes directly connected to runtime behavior.
The Ruleset stack determines the order in which Pega searches Rulesets during Rule resolution. The higher-precedence Rulesets are considered before lower-precedence Rulesets.
2. AlphaBankingInt – integration Rules
3. AlphaBankingCommon – reusable banking Rules
4. Alpha-Enterprise – enterprise capabilities
5. Pega platform/base Rules
The exact stack depends on the application and built-on configuration. The important architectural point is that the stack is not decorative. It directly participates in runtime Rule resolution.
This is why a developer should never casually change the order of application Rulesets.
13. Built-On Applications – Reuse Without Copying Rules
Suppose Alpha Bank already has reusable capabilities for:
- Enterprise authentication
- Audit
- Notifications
- Document management
- Common customer services
- Banking-specific KYC capabilities
We do not want Nexus developers to copy those Rules into the application. Instead, Nexus can build on reusable applications where there is genuine reuse.
At runtime, Pega builds a linear application stack from the built-on hierarchy. This is one of the reasons application hierarchy and Ruleset precedence must be designed carefully. :contentReference[oaicite:0]{index=0}
14. Where Do Case Types Fit?
At this point, we have the application architecture. We have not yet designed the individual Case Types in detail.
But we can identify the major processes that Nexus will eventually support:
In the next level of this architecture series, we will take these Case Types individually and design their stages, processes, child cases, assignments, SLAs, data ownership and lifecycle.
15. What Happens at Runtime?
Let's connect everything together.
↓
Access Group
↓
Application: Nexus
↓
Built-on Application Hierarchy
↓
Ruleset Stack
↓
Rule Resolution
↓
Selected Rule
↓
Case / Data / Integration Processing
When an operator logs in, the Access Group identifies the application context. Pega then establishes the Ruleset list available to that session based on the application and its built-on applications.
When the application executes a Rule, the Ruleset stack becomes one of the inputs into Rule resolution.
This is why application architecture is not something that exists only on an architecture diagram. It directly influences what Rules are available and which Rule can execute.
16. Application Architecture and Rule Resolution
Consider a simple example.
Nexus has a validation Rule for a Loan Application. The banking framework also has a generic validation Rule.
If both Rules are candidates, Pega does not simply choose the Rule that was created most recently. It evaluates the applicable Rule-resolution criteria, including class, Ruleset availability, precedence and specialization.
CLASS → RULESET STACK → VERSION → AVAILABILITY → SPECIALIZATION → CIRCUMSTANCE → TRACE → VALIDATE
This is one reason why understanding application architecture is essential before troubleshooting an unexpected Rule execution.
17. Application Validation vs Ruleset Validation
This is another area where architecture and development lifecycle meet.
Application Validation and Ruleset Validation help determine what Rules can reference during development and migration.
They should not be confused with the runtime Ruleset list.
Application Validation
Uses the application context and application stack to determine available dependencies.
Ruleset Validation
Explicitly defines prerequisite Ruleset versions for Ruleset-level dependency control.
Validation governs development and migration dependencies. The runtime Ruleset list governs Rule execution and Rule resolution. :contentReference[oaicite:1]{index=1}
18. How I Would Design Nexus Rulesets
I would avoid creating a Ruleset for every Case Type.
Instead, I would group Rules according to responsibility and reuse.
| Area | Possible Ruleset | Responsibility |
|---|---|---|
| Application | AlphaBanking | Nexus-specific business behavior |
| Integration | AlphaBankingInt | Integration-related Rules |
| Common | AlphaBankingCommon | Reusable banking capabilities |
| Security | AlphaBankingSecurity | Security and authorization Rules |
The actual names can vary by enterprise standards. What matters is that the architecture makes ownership, reuse and dependency relationships clear.
19. Versioning and Deployment
Application architecture must also account for how changes move through environments.
A change to the application stack can affect Rule availability and Rule resolution. Therefore, changes to:
- Application versions
- Built-on applications
- Ruleset versions
- Ruleset stack ordering
- Ruleset prerequisites
- Class hierarchy
should be treated as architectural changes rather than simple configuration changes.
Pega's current guidance also emphasizes keeping reusable applications and Rulesets properly separated and using validation to identify dependency problems before migration. :contentReference[oaicite:2]{index=2}
20. Common Application Architecture Mistakes
The application becomes difficult to reuse, maintain and govern.
Developers cannot easily determine ownership and dependencies.
The same business logic ends up implemented in multiple applications.
An unnecessary framework adds complexity instead of reducing it.
A developer may change a Rule and be surprised when another Rule is selected at runtime.
Workflow ownership and data ownership are different architectural decisions.
21. Troubleshooting an Application Architecture Problem
Suppose a developer says:
I would not immediately change the Rule again. I would trace the architecture from the outside in.
↓
2. Which Access Group?
↓
3. Which Application version?
↓
4. What is the Application stack?
↓
5. What is the Ruleset stack?
↓
6. What class is the Rule executing against?
↓
7. Is the expected Rule available?
↓
8. Is another Rule higher in precedence?
↓
9. Are specialization/circumstance conditions involved?
↓
10. Trace and validate
22. How to Explain Nexus Application Architecture in a Pega Interview
"For our Alpha Bank implementation, we designed a Pega application called Nexus to orchestrate customer and banking operations. Nexus is the implementation application, while Alpha is the organization namespace used in our class structure.
The application is built on reusable enterprise and banking capabilities. We separate Work, Data and Integration responsibilities using classes such as Alpha-Banking-Work, Alpha-Banking-Data and Alpha-Banking-Int.
Work contains business processes and Case Types, Data represents reusable business entities, and Integration contains connectivity to systems such as Core Banking, Customer Master, KYC, AML and Credit Bureau.
We manage the application's behavior through Rulesets and an application stack. At runtime, the operator's Access Group establishes the application context, Pega builds the applicable Ruleset list, and Rule resolution determines the Rule that executes.
This architecture allows us to separate responsibilities, promote reuse, control dependencies, and maintain the application as the banking platform evolves."
23. The Easy Way to Remember Application Architecture
What does the bank do?
What are we building?
How is responsibility organized?
How are Rules packaged?
Which Rules take precedence?
Which Rule actually executes?
24. Key Architecture Principles for Alpha Bank Nexus
- Start with business capabilities.
- Keep Nexus as the implementation application.
- Keep Alpha as the organizational namespace.
- Separate Work, Data and Integration responsibilities.
- Use built-on applications only when there is genuine reuse.
- Keep reusable capabilities outside the implementation layer.
- Design the Ruleset stack intentionally.
- Understand Rule resolution before troubleshooting Rules.
- Separate workflow ownership from System-of-Record ownership.
- Design for future reuse without creating unnecessary abstraction.
What We Will Build Next
This post establishes the application architecture. From here, we will go deeper one architectural level at a time.
Business capabilities, Nexus, application hierarchy, built-on applications, class structure and Ruleset architecture.
Customer Onboarding, Account Opening, Loan Application, stages, processes, child cases, assignments and SLAs.
Customer, Account, Product, Loan, KYC, Address, Data Objects, Data Pages and System-of-Record design.
Core Banking, Customer Master, KYC/AML, Credit Bureau, REST APIs, Connectors, Request/Response mapping and error handling.
Key Takeaway
A strong Pega application architecture is not simply a collection of Case Types and Rules. It is a deliberate structure that connects business capabilities, applications, classes, Rulesets, data, integrations and runtime behavior.
In our example, Nexus is the Pega application for Alpha Bank, while Alpha defines our organizational namespace. Nexus orchestrates the banking work, while the class structure separates Work, Data and Integration responsibilities.
Once this foundation is correct, we can confidently move to the next level: designing the individual Case Types.
No comments:
Post a Comment