Pega Application Architecture – Part 5: Inheritance Architecture

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 5: How class inheritance, directed inheritance, application inheritance, ruleset hierarchy, and rule resolution work together in Alpha Bank's Nexus application.

1. Why Inheritance Matters in a Pega Application

Imagine Alpha Bank has the following Case Types:

• CustomerOnboarding
• AccountOpening
• CustomerMaintenance
• AddressChange
• CardRequest
• LoanApplication
• FraudReview
• KYCReview
• AccountClosure

Many of these Cases may need common behavior:

• Customer identification
• Case creation behavior
• Audit information
• Common validations
• Common notifications
• Common security behavior
• Common error handling
• Common business utilities

If developers copy the same rule into every Case Type, the application quickly becomes difficult to maintain.

Without inheritance

CustomerOnboarding → ValidateCustomer
AccountOpening    → ValidateCustomer
LoanApplication   → ValidateCustomer
CardRequest       → ValidateCustomer
KYCReview         → ValidateCustomer

Now the same business logic exists in multiple places. A change to the validation may require changes in several rules.

With inheritance, Alpha Bank can place genuinely common behavior at an appropriate reusable level and allow specialized Case Types to inherit it.

Alpha-Banking-Work
        │
        ├── CustomerOnboarding
        ├── AccountOpening
        ├── LoanApplication
        └── CardRequest

Common ValidateCustomer rule
        │
        └── Defined at the appropriate reusable level

2. The Four Concepts You Must Not Confuse

One of the biggest sources of confusion in Pega architecture is using the word inheritance to describe several different mechanisms.

Concept	Main Question	Alpha Bank Example
Pattern Inheritance	Which parent classes can this class inherit from?	LoanApplication → Alpha-Banking-Work
Directed Inheritance	Which explicitly specified class can provide additional reusable rules?	Alpha banking class explicitly inheriting from an applicable Pega class
Application Inheritance	Which application capabilities does Nexus build on?	Nexus → Alpha Banking Framework → Alpha Enterprise → Pega Platform
Ruleset Stack	Which rulesets and versions are available and in what precedence?	Nexus rulesets → Alpha Banking → Alpha Enterprise → Pega Platform

Important: Class inheritance and application inheritance are not the same thing. The class hierarchy answers one set of questions, while the application and Ruleset architecture answer another.

3. Alpha Bank's Complete Class Architecture

For our Alpha Bank application, we established the following class structure. The application name is Nexus, but Nexus is not part of our class namespace.

Alpha
│
└── Alpha-Banking
    │
    ├── Alpha-Banking-Work
    │   │
    │   ├── Alpha-Banking-Work-CustomerOnboarding
    │   ├── Alpha-Banking-Work-AccountOpening
    │   ├── Alpha-Banking-Work-CustomerMaintenance
    │   ├── Alpha-Banking-Work-AddressChange
    │   ├── Alpha-Banking-Work-CardRequest
    │   ├── Alpha-Banking-Work-LoanApplication
    │   ├── Alpha-Banking-Work-FraudReview
    │   ├── Alpha-Banking-Work-KYCReview
    │   └── Alpha-Banking-Work-AccountClosure
    │
    ├── Alpha-Banking-Data
    │   │
    │   ├── Alpha-Banking-Data-Customer
    │   ├── Alpha-Banking-Data-Account
    │   ├── Alpha-Banking-Data-Address
    │   ├── Alpha-Banking-Data-Product
    │   ├── Alpha-Banking-Data-KYC
    │   ├── Alpha-Banking-Data-Loan
    │   ├── Alpha-Banking-Data-Card
    │   └── Alpha-Banking-Data-Transaction
    │
    └── Alpha-Banking-Int
        │
        ├── Alpha-Banking-Int-CoreBanking
        ├── Alpha-Banking-Int-KYC
        ├── Alpha-Banking-Int-AML
        ├── Alpha-Banking-Int-CreditBureau
        └── Alpha-Banking-Int-Card

This structure gives us a business-oriented class hierarchy. It also creates natural places where rules can be reused.

4. Pattern Inheritance — The Most Important Inheritance Concept

Pattern inheritance is automatic. Pega uses the class name structure to determine the parent classes available for rule reuse.

For example:

Alpha-Banking-Work-LoanApplication
                │
                ▼
Alpha-Banking-Work
                │
                ▼
Alpha-Banking
                │
                ▼
Alpha
                │
                ▼
@baseclass

The important idea is that the child class can reuse appropriate rules defined higher in the hierarchy.

Example

Suppose Alpha Bank defines a common customer validation rule at:

Alpha-Banking-Work
    ValidateCustomer

The Loan Application Case can potentially reuse that rule because:

Alpha-Banking-Work-LoanApplication
             │
             └── inherits from
                     │
                     ▼
              Alpha-Banking-Work
                     │
                     └── ValidateCustomer

We did not copy the rule into every Case Type. The child Case Type reuses the rule through the class hierarchy.

5. Where Should a Rule Live?

This is one of the most important architecture decisions.

A useful design principle is:

Place a rule at the highest appropriate level where its business meaning remains correct.

For example, suppose the rule:

ValidateCustomerIdentity

is applicable to almost every Alpha banking Case. A higher reusable class may be appropriate.

But suppose we have:

CalculateLoanDebtToIncomeRatio

That is clearly loan-specific behavior. Putting it in the generic Work class would make the parent class less meaningful and potentially expose unrelated behavior to other Cases.

It belongs at a level where the rule's business applicability is accurate.

6. Rule Reuse Example — Customer Validation

Let's use a practical Alpha Bank example.

When a customer opens an account, applies for a loan, or requests a card, Alpha Bank needs to validate customer information.

Instead of creating separate copies:

CustomerOnboarding → ValidateCustomer
AccountOpening    → ValidateCustomer
LoanApplication   → ValidateCustomer
CardRequest       → ValidateCustomer

we can identify what is truly common and place that logic at an appropriate reusable level.

Then LoanApplication can add loan-specific validation without duplicating the common logic.

Alpha-Banking-Work
    │
    ├── ValidateCustomer
    │
    └── common banking behavior

Alpha-Banking-Work-LoanApplication
    │
    ├── loan-specific validation
    ├── credit validation
    └── debt-to-income validation

7. What Can Be Reused Through Class Inheritance?

Depending on the rule type and the class structure, child classes can reuse rules defined at parent levels.

Examples include:

• Properties and data-related rules
• Activities
• Sections and UI rules
• Flows and processes
• Decision rules
• Data Transforms
• Validations
• When rules
• Expressions
• Other reusable application behavior

The exact behavior is rule-type dependent, so inheritance should not be treated as a generic "copy everything from the parent" mechanism.

8. Directed Inheritance — When the Parent Is Explicitly Specified

Pattern inheritance follows the class-name hierarchy. Directed inheritance is different.

With directed inheritance, the parent class is explicitly specified on the class definition. This allows a class to reuse rules from another class that is not simply its automatic pattern-inheritance parent.

This is particularly useful when an application class needs to reuse standard Pega rules or rules from another functional hierarchy.

Conceptual Example

Alpha-Banking-Work-LoanApplication
        │
        │ Pattern inheritance
        ▼
Alpha-Banking-Work
        │
        │ Pattern inheritance
        ▼
Alpha-Banking

        +

Explicit directed inheritance
        │
        ▼
Applicable Pega Work/Data class
or another explicitly selected reusable class

Directed inheritance should be used deliberately. It should have a clear functional reason rather than becoming a shortcut for an unclear class hierarchy.

9. Pattern Inheritance vs Directed Inheritance

Pattern Inheritance	Directed Inheritance
Automatic	Explicitly specified
Based on class naming/hierarchy	Based on an explicit parent class relationship
Promotes business-oriented reuse	Useful for functional reuse outside the automatic business hierarchy
Example: LoanApplication → Alpha-Banking-Work	Example: Alpha application class explicitly referencing a reusable Pega class

10. The Most Important Part — How Pega Searches for a Rule

This is where inheritance connects directly to Rule Resolution.

Suppose Bob is working with:

Alpha-Banking-Work-LoanApplication

and the application requests a rule named:

ValidateCustomer

Conceptually, Pega has to answer several questions:

1. What Rule Type is being requested?
2. What is the current class?
3. Which rulesets are available to this operator?
4. Which candidate rules exist?
5. Which classes are in the applicable inheritance path?
6. Are the candidate rules available?
7. Are there circumstances or other specialization conditions?
8. Which candidate has the appropriate precedence?
9. Which rule should execute?

11. Rule Resolution — The Runtime Mental Model

A useful mental model for the Alpha Bank Nexus application is:

John
  │
  ▼
Operator / Access Group
  │
  ▼
Application + Application Version
  │
  ▼
Ruleset Stack
  │
  ▼
Rule Type + Rule Name
  │
  ▼
Current Class
  │
  ▼
Class Hierarchy
  │
  ▼
Pattern Inheritance
  │
  ▼
Directed Inheritance where applicable
  │
  ▼
Candidate Rules
  │
  ▼
Availability / Specialization / Circumstances
  │
  ▼
Selected Rule
  │
  ▼
Runtime Execution

This is the architecture-level view of how a Pega rule becomes executable behavior.

12. The Ruleset Stack Is Not Class Inheritance

This distinction is extremely important.

The class hierarchy tells Pega about the class-based inheritance path. The Ruleset Stack determines the rulesets and versions available to the application session and their precedence.

A conceptual Nexus stack might look like:

Nexus Implementation Rulesets
        │
        ▼
Alpha Banking Framework Rulesets
        │
        ▼
Alpha Enterprise Rulesets
        │
        ▼
Pega Platform Rulesets

The exact deployed names and versions depend on the implementation. The important architectural principle is the separation between:

• Class hierarchy — where the rule applies conceptually
• Ruleset stack — which rulesets/versions are available and their precedence
• Rule resolution — which specific rule candidate is selected

13. Alpha Bank Application Inheritance

There is another inheritance concept at the application level.

Nexus can be designed as the implementation application for Alpha Bank while building on reusable application capabilities where those capabilities genuinely belong in a framework or enterprise layer.

Pega Platform
      │
      ▼
Alpha Enterprise
      │
      ▼
Alpha Banking Framework
      │
      ▼
Nexus
Alpha Bank Banking Application

This is application inheritance / built-on application architecture. It should not be confused with:

Alpha-Banking-Work-LoanApplication
             │
             ▼
Alpha-Banking-Work

The first is an application composition relationship. The second is a class inheritance relationship.

14. Application Inheritance vs Class Inheritance vs Rulesets

Layer	Purpose	Alpha Bank Example
Application	Reuse application capabilities	Nexus built on Alpha Banking Framework
Class	Organize and reuse rules through class hierarchy	LoanApplication → Work
Ruleset	Package, version, and make rules available in a controlled stack	Nexus → Alpha Banking → Enterprise → Platform
Rule Resolution	Select the applicable rule at runtime	Select the appropriate ValidateCustomer rule

15. A Complete Alpha Bank Rule Resolution Example

Let's make this concrete.

Bob opens a LoanApplication. During processing, the application needs the rule:

ValidateCustomer

Assume the following rules exist:

Class	Rule	Purpose
Alpha-Banking-Work-LoanApplication	ValidateCustomer	Loan-specific validation
Alpha-Banking-Work	ValidateCustomer	Common banking validation
Alpha-Banking	ValidateCustomer	Broader banking behavior

The rule at the LoanApplication level is the more specialized candidate in this inheritance path, assuming the other rule-resolution criteria are satisfied.

If that rule does not exist or is not an applicable candidate, Pega can continue through the inheritance path and consider applicable rules at higher levels.

Key idea: The existence of a parent rule does not mean Pega automatically executes it. Rule resolution determines the appropriate candidate based on multiple inputs.

16. Rule Resolution Uses More Than Inheritance

This is an important interview and production concept.

Pega's rule-resolution process considers several inputs, including:

• Rule Type
• Rule name / purpose
• Apply To class
• Operator's Ruleset Stack
• Class hierarchy
• Rule availability
• Circumstances and specialization where applicable
• Access roles and privileges in relevant rule-resolution scenarios

Therefore, saying:

"Pega always executes the child class rule."

is an oversimplification.

A more accurate explanation is:

Pega evaluates applicable rule candidates using the rule-resolution algorithm and selects the appropriate rule based on the relevant rule keys, ruleset availability, inheritance path, specialization, availability, and other applicable factors.

17. Data Class Inheritance

Inheritance is not limited to Case Types. We can also apply thoughtful inheritance to the Data layer when the business model genuinely supports specialization.

For example:

Alpha-Banking-Data-Account
          │
          ├── Alpha-Banking-Data-CheckingAccount
          │
          └── Alpha-Banking-Data-SavingsAccount

The parent can contain truly common account behavior and properties, while the child classes can contain account-type-specific behavior.

However, inheritance should not be introduced merely because two Data Objects happen to share several properties.

Architecture rule: Shared fields alone do not automatically justify inheritance. The business relationship and rule reuse should justify the hierarchy.

18. Integration Class Inheritance

The same principle applies to the integration layer.

Alpha-Banking-Int
      │
      ├── Alpha-Banking-Int-CoreBanking
      ├── Alpha-Banking-Int-KYC
      ├── Alpha-Banking-Int-AML
      ├── Alpha-Banking-Int-CreditBureau
      └── Alpha-Banking-Int-Card

Common integration behavior can be separated from system-specific behavior.

For example, common standards may include:

• Correlation handling
• Common logging patterns
• Common error categorization
• Common monitoring metadata
• Common integration utilities

But Core Banking-specific request and response behavior should remain associated with the Core Banking integration rather than being placed into a generic banking integration parent simply for convenience.

19. Inheritance and Specialization

Alpha Bank may start with common behavior and later require specialized behavior.

For example:

Common banking validation
        │
        ├── CustomerOnboarding
        ├── AccountOpening
        └── LoanApplication
                │
                └── additional loan-specific validation

The architecture should allow specialization without forcing developers to copy the entire parent implementation.

This is one of the major benefits of a well-designed class hierarchy.

20. Inheritance and Ruleset Specialization

Class hierarchy is only one dimension of specialization. Ruleset organization also matters.

A rule can be associated with a particular class and ruleset. The Ruleset Stack controls which rulesets and versions are available to the current application context.

This means two developers could look at the same rule name and class and still need to consider the active Ruleset Stack to understand which rule instance is applicable.

Remember: Class hierarchy answers "where does the rule belong?" Ruleset Stack helps answer "which ruleset versions are available and what is their precedence?" Rule resolution answers "which rule should execute?"

21. A Practical Dev Studio Example

Suppose we are working on:

Alpha-Banking-Work-LoanApplication

In Dev Studio, an architect can inspect the class structure and determine:

1. The current Apply To class
2. The parent class
3. Any relevant directed inheritance
4. The rules defined directly against the class
5. The rules inherited from parent classes
6. The application's Ruleset Stack
7. The available rule versions

This is one of the reasons understanding the App Explorer and class hierarchy is important for Pega developers and architects.

22. The Most Common Inheritance Mistake — Putting Rules Too High

Suppose a developer creates:

Alpha-Banking-Work
    CalculateLoanInterestRate

because the developer wants to reuse it in two loan-related Case Types.

But Alpha-Banking-Work represents the broader banking Work domain. The rule is not meaningful for CustomerOnboarding, CardRequest, FraudReview, or AccountClosure.

The parent has now become polluted with specialized business behavior.

A better architecture would place the rule at the narrowest level where it is still genuinely reusable.

Alpha-Banking-Work
        │
        ├── CustomerOnboarding
        ├── AccountOpening
        │
        └── Loan-related reusable layer
                │
                ├── LoanApplication
                └── other applicable loan Cases

The exact hierarchy depends on the real Alpha Bank business requirements. The principle is to avoid putting unrelated behavior into broad parent classes.

23. The Opposite Mistake — Putting Everything at the Child Level

The opposite problem is also common.

Developers sometimes create the same rule separately for every Case Type:

CustomerOnboarding → ValidateCustomer
AccountOpening    → ValidateCustomer
LoanApplication   → ValidateCustomer
CardRequest       → ValidateCustomer
KYCReview         → ValidateCustomer

If the business behavior is genuinely common, this creates unnecessary duplication.

The architect should ask:

"Can this rule be defined once at a higher appropriate level and reused safely?"

24. Avoid Deep and Unnecessary Class Hierarchies

Inheritance is powerful, but deeper is not automatically better.

A hierarchy such as:

Alpha
  └── Banking
      └── Retail
          └── Consumer
              └── Lending
                  └── Personal
                      └── Unsecured
                          └── Premium
                              └── LoanApplication

can become difficult to understand if every level exists only to reuse a few rules.

A good architecture should make the reason for each level understandable.

25. Inheritance Is Not the Same as Copying

This is worth emphasizing.

When a child Case uses an inherited rule, Pega is not creating a second independent copy of that rule for every Case Type.

The architecture allows the rule to remain defined at its reusable level while the child uses it through rule resolution.

Why this matters: When common logic changes, there can be one authoritative rule rather than many duplicated implementations that developers must keep synchronized.

26. Inheritance Across the Alpha Banking Layers

We can now look at our complete architecture:

                    NEXUS
             Alpha Bank Application
                       │
             Application Architecture
                       │
        ┌──────────────┼──────────────┐
        │              │              │
       Work           Data           Int
        │              │              │
        ▼              ▼              ▼
   Case Types       Data Types    Integrations
        │              │              │
        └──────────────┼──────────────┘
                       │
                 Class Hierarchy
                       │
              Pattern Inheritance
                       │
              Directed Inheritance
                       │
                  Rulesets
                       │
                Rule Resolution
                       │
                Selected Rule
                       │
                    Runtime

This is how inheritance becomes an architecture concern rather than just a developer feature.

27. Runtime Example — John Creates a Customer Onboarding Case

Let's walk through one complete runtime scenario.

Step 1 — John logs in

John's Operator record and Access Group establish his application context.

Step 2 — Nexus becomes the application context

The application and version establish the application configuration and associated Ruleset Stack.

Step 3 — John creates CustomerOnboarding

The Case operates in:

Alpha-Banking-Work-CustomerOnboarding

Step 4 — A rule is requested

Suppose a section, flow, activity, decision, or other rule references:

ValidateCustomer

Step 5 — Pega resolves the rule

Pega evaluates applicable candidates using the rule-resolution mechanisms.

Step 6 — The selected rule executes

The Case does not need to know whether the selected rule was defined directly on CustomerOnboarding or inherited from a reusable parent level.

This is the power of the Pega architecture: business Cases can use reusable rules without embedding every implementation detail directly into each Case Type.

28. How to Troubleshoot "Why Is Pega Using This Rule?"

One of the most common questions in a real Pega project is:

"I created this rule, but Pega is executing a different rule. Why?"

Do not immediately change the rule. First investigate the resolution path.

1. Identify the Rule Type.
   A section, activity, decision rule, data transform, privilege, and other rule types have different rule structures and resolution behavior.
2. Check the Apply To class.
   Make sure the rule is created against the class you intended.
3. Inspect the class hierarchy.
   Determine where the current Case class sits in the inheritance structure.
4. Check the Ruleset Stack.
   Verify which rulesets and versions are available to the current application context.
5. Check rule availability.
   A rule that exists but is not available may not be an executable candidate.
6. Check specialization and circumstances.
   If applicable, determine whether another specialized candidate is being selected.
7. Check directed inheritance.
   The expected class hierarchy may not be the entire inheritance path.
8. Compare the exact rule keys.
   Rule name, Rule Type, Apply To class, Ruleset and other relevant attributes matter.

29. Common Inheritance Mistakes

1. Creating very deep class hierarchies
More levels do not automatically mean better reuse.

2. Putting specialized business logic in generic parent classes
This makes broad classes difficult to understand and maintain.

3. Duplicating common rules in every Case Type
This defeats the purpose of inheritance.

4. Using directed inheritance without a clear reason
Explicit relationships should be understandable to another architect.

5. Confusing application inheritance with class inheritance
Built-on application relationships and class hierarchy solve different problems.

6. Ignoring the Ruleset Stack
Class hierarchy alone does not explain every rule-resolution outcome.

7. Assuming the closest rule always executes
Rule resolution considers multiple inputs.

30. Inheritance Design Checklist for Alpha Bank

Before adding a new rule to the Nexus application, the architect should ask:

1. Is this rule specific to one Case Type?
2. Is this rule common to several Case Types?
3. What is the highest class where the rule remains business-correct?
4. Does an existing parent rule already solve the requirement?
5. Can an existing rule be parameterized instead of duplicated?
6. Is a new class level really necessary?
7. Is directed inheritance required?
8. Does the rule belong in the application framework instead?
9. Is the Ruleset Stack correctly structured?
10. Could this design make future rule resolution difficult to understand?

31. A Simple Mental Model for Pega Inheritance

When designing inheritance, remember these four questions:

1. APPLICATION
What reusable application capabilities does Nexus build on?

2. CLASS
What business class should this rule belong to?

3. RULESET
Which ruleset and version should contain and expose the rule?

4. RESOLUTION
Given the runtime context, which rule should Pega actually execute?

32. How I Would Explain Alpha Bank's Inheritance Architecture in an Interview

Example interview answer:

"In our Alpha Bank Nexus application, we use inheritance to maximize rule reuse while keeping business-specific behavior at the appropriate level. Our Case Types use an Alpha-Banking-Work class hierarchy, while reusable Data and Integration capabilities are separated into their respective class structures.

Pega supports pattern inheritance and directed inheritance. Pattern inheritance follows the class hierarchy automatically, while directed inheritance explicitly specifies another parent class for rule reuse when required.

We also separate application inheritance from class inheritance. Nexus can build on reusable Alpha Banking or enterprise applications, while individual Case Types inherit through the class hierarchy.

At runtime, the Ruleset Stack and class hierarchy are inputs to rule resolution. Pega evaluates the applicable rule candidates and selects the appropriate rule based on the rule's keys, availability, inheritance path, Ruleset Stack, specialization, and other applicable factors.

So, for me, inheritance architecture is not just about parent and child classes. It is about deciding where reusable business behavior belongs and making sure the runtime rule-resolution path remains predictable and maintainable."

33. The Complete Alpha Bank Nexus Architecture

We can now connect everything we have designed in the Application Architecture series.

                         ALPHA BANK
                              │
                              ▼
                           NEXUS
                    Banking Application
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
        ▼                     ▼                     ▼
   CASE TYPES             DATA TYPES           INTEGRATIONS
        │                     │                     │
        ▼                     ▼                     ▼
   Work Classes          Data Classes         Int Classes
        │                     │                     │
        └─────────────────────┼─────────────────────┘
                              │
                              ▼
                       CLASS HIERARCHY
                              │
                    ┌─────────┴─────────┐
                    │                   │
                    ▼                   ▼
              Pattern Inheritance   Directed Inheritance
                    │                   │
                    └─────────┬─────────┘
                              │
                              ▼
                       RULESET STACK
                              │
                              ▼
                       RULE RESOLUTION
                              │
                              ▼
                        SELECTED RULE
                              │
                              ▼
                           RUNTIME

This is the key architectural relationship:

Application architecture defines where capabilities live. Class architecture defines how rules are organized and reused. Rulesets control how rules are packaged and made available. Rule resolution determines which applicable rule executes.

34. Key Takeaways

• Inheritance is a core part of Pega architecture, not just a coding technique.
• Pattern inheritance follows the class hierarchy automatically.
• Directed inheritance explicitly specifies another class for rule reuse.
• Application inheritance and class inheritance solve different architectural problems.
• The Ruleset Stack is separate from the class hierarchy.
• Rule resolution considers multiple inputs, not inheritance alone.
• Put common rules at the highest level where they remain genuinely applicable.
• Keep specialized business behavior at the appropriate specialized level.
• Avoid unnecessary class depth and unnecessary duplication.
• A good inheritance architecture makes Nexus easier to extend, maintain, troubleshoot, and evolve.

The Big Idea

A mature Pega application does not solve every business requirement by creating another independent rule. It creates a meaningful architecture where rules are placed at the appropriate level, reused through inheritance, packaged through rulesets, and selected through rule resolution.

In Alpha Bank's Nexus application, inheritance is what allows us to build once, reuse where appropriate, specialize when necessary, and keep the overall application maintainable as the banking platform grows.

Pega Academy References

• Pega Academy — Rule reuse through inheritance
• Pega Academy — Rule resolution
• Pega Academy — Ruleset Stack
• Pega Academy — Classes and class hierarchy
• Pega Academy — Ruleset, class, and circumstance specialization

Pega Application Architecture Series

Part 1 — Application Architecture: Designing Nexus for Alpha Bank

Part 2 — Case Type Architecture

Part 3 — Data Type & Data Architecture

Part 4 — Integration Architecture

Part 5 — Inheritance Architecture

Part 6 — Security Architecture

Part 7 — Runtime, Deployment & Operations

Pega Application Architecture Series  •  Alpha Bank Nexus