Showing posts with label
Pega Application Architecture.
Show all posts
Home » Posts filed under Pega Application Architecture
PEGA APPLICATION ARCHITECTURE — PART 6
Security Architecture for the Nexus Banking Application
How Authentication, Authorization, RBAC, ABAC, Case Security, Data Security,
Integration Security, and Audit work together in Alpha Bank Nexus
In the previous parts of this series, we designed the major building blocks of
the Nexus banking application for Alpha Bank.
We looked at the application architecture, Case Types, Data Types, integrations,
and inheritance.
Now we need to answer one of the most important architectural questions:
How do we make sure that the right person can access the right application,
the right Case, the right action, and the right data — while preventing
unauthorized access?
Security in Pega is not implemented by a single Rule Type or one configuration.
It is a collection of complementary layers. Authentication establishes identity,
while authorization determines what an authenticated user can access or perform.
Pega supports multiple authorization models, including Role-Based Access Control
(RBAC), Attribute-Based Access Control (ABAC), Client-Based Access Control (CBAC),
and Basic Access Control (BAC). These models can complement each other rather than
representing mutually exclusive choices.
In this article, we will build the complete security architecture for our
Alpha Bank Nexus application and trace a request from the user
all the way through authentication, authorization, Case security, data security,
integrations, and audit.
Pega Application Architecture – Part 5
Inheritance Architecture
How Pega Reuses and Resolves Rules in the Alpha Bank Nexus Application
One application. Reusable rules. Controlled specialization. Predictable rule resolution.
In the previous parts of this series, we designed the overall architecture of the
Alpha Bank Nexus application, including Case Types, Data Architecture,
and Integration Architecture.
But there is an important question that appears as the application grows:
When Alpha Bank creates hundreds or thousands of Pega rules, how does Pega know which
rule to reuse, where to look for it, and which version of the rule should actually execute?
This is where inheritance and rule resolution become extremely important.
In Pega, inheritance is not simply about creating a parent class and a child class.
A well-designed Pega application uses several related mechanisms:
- Class hierarchy and pattern inheritance
- Directed inheritance
- Application and built-on application architecture
- Ruleset hierarchy and Ruleset Stack
- Rule specialization
- Rule availability
- Circumstance and other rule-resolution factors
- Runtime rule resolution
The most important thing to understand is that these mechanisms solve
different problems.
Pega Application Architecture – Part 4: Integration Architecture
How does the Nexus banking application communicate with
Core Banking, KYC, AML, Credit Bureau, Card, CRM, and other enterprise systems?
In the previous parts of this series, we designed the overall application architecture,
Case Types, and Data Architecture for Alpha Bank.
We established that Nexus is the banking application/product,
while the underlying Pega class structure belongs to the
Alpha organization.
But there is one major architectural question left:
Where does the data actually come from?
A Customer may exist in a Customer Master system.
An Account may belong to the Core Banking system.
A credit score may come from a Credit Bureau.
KYC information may come from a KYC provider.
AML screening may be performed by an external AML platform.
Card information may come from a Card Management platform.
Nexus should not try to become a copy of every one of these systems.
Instead, Pega should provide a clean integration architecture that allows
business processes to access the right information and invoke the right
enterprise services when required.
This is where Integration Architecture becomes one of the
most important parts of a Pega application architecture.
Pega Application Architecture
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
Pega Application Architecture – Part 2:
Designing Case Types for the Nexus Banking Application
In Part 1, we designed the high-level architecture for Alpha Bank's
Nexus banking application. Now we move one level deeper and design
the most important building block of a Pega application:
the Case Type.
Before creating a Case Type in Pega, we should first understand
what business problem the Case Type represents.
A Case Type should not simply be created because a business screen
or database table exists.
A Case Type represents a repeatable business transaction or
business journey that Pega manages from initiation through
resolution.
For our Alpha Bank example, customers may open accounts, apply for
loans, update their information, request cards, complete KYC
verification, or report potentially fraudulent activity.
Each of these business journeys may become a separate Case Type
when the organization needs Pega to manage its lifecycle, work,
assignments, decisions, automation, SLAs, security, and auditability.
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.
