1.2 Pega Architecture & Enterprise Class Structure (ECS)

Pega Architecture & Enterprise Class Structure (ECS)

The Pega Platform is an enterprise application engine designed around model-driven development. Rather than writing compiled Java, C#, or SQL code directly, architects author business rules—such as Case Types, Data Pages, Views, Data Transforms, and Decision Tables. The Pega runtime engine, historically known as PRPC (PegaRULES Process Commander), dynamically translates these declarative and procedural rules into optimized Java classes executed within an enterprise Java Servlet container (such as Apache Tomcat, IBM WebSphere, or Oracle WebLogic).

To achieve true enterprise-scale reuse across diverse business lines and geographic operating units, Pega organizes all application assets using the Enterprise Class Structure (ECS).

---

1. Core Platform Architecture: Engine, Clipboard & Schemas

To architect solutions effectively, a System Architect must understand what happens behind the scenes when a user logs in and interacts with a case.

The Runtime Processing Model and the Clipboard

Every user interaction is represented in memory by a Requestor session. The Pega engine allocates a dedicated in-memory hierarchical structure called the Clipboard for each active requestor. The Clipboard functions as the working memory (RAM) of the application, holding all active data objects, case properties, user session attributes, and cached reference tables.

The Clipboard is structured into four primary page categories:

1. User Pages: Pages created by application execution, such as pyWorkPage, which represents the currently open case and holds all its properties (e.g., .CustomerName, .LoanAmount).
2. Data Pages: Read-only, editable, or savable cache pages (prefixed with D_) populated from internal or external systems of record.
3. System Pages: Pages managed by the Pega engine describing the current operational context, including pxRequestor (user identity, client ip, access roles) and pxProcess (JVM-wide environment parameters).
4. Linked Pages: Read-only pages loaded automatically by the engine via property-to-class foreign key references.

Dual Relational Database Schema: PegaRULES vs. PegaDATA

Pega splits its physical persistence layer into two distinct relational database schemas to separate application code from transactional data:

---

2. The Enterprise Class Structure (ECS) 5-Layer Hierarchy

The Enterprise Class Structure (ECS) is Pega's foundational design pattern for organizing rules into reusable layers. Like an inverted pyramid, generic capabilities reside at the bottom and are inherited by increasingly specialized layers above.

+-------------------------------------------------------------------------+
|                         ENTERPRISE CLASS STRUCTURE                      |
+-------------------------------------------------------------------------+
| [5] IMPLEMENTATION LAYER: Specialized, deployable business apps         |
|     e.g., UPlus-Retail-AutoLoan-Work-AutoLoan                           |
+-------------------------------------------------------------------------+
| [4] FRAMEWORK LAYER: Generalized, reusable industry workflow templates  |
|     e.g., UPlus-Retail-LoanFW-Work-Loan                                 |
+-------------------------------------------------------------------------+
| [3] DIVISION LAYER: Segment-specific policies, SLAs, and accounts       |
|     e.g., UPlus-Retail-                                                 |
+-------------------------------------------------------------------------+
| [2] ORGANIZATION (ENTERPRISE) LAYER: Enterprise-wide shared data/assets |
|     e.g., UPlus-Data-Customer, UPlus-UI-GlobalTheme                     |
+-------------------------------------------------------------------------+
| [1] PEGA PLATFORM LAYER: Core out-of-the-box engine rules & classes     |
|     e.g., Work-, Data-, Assign-, Rule-, @baseclass                      |
+-------------------------------------------------------------------------+

1. Pega Platform Layer

Contains the built-in system rules, system engines, and base classes provided by Pegasystems (e.g., @baseclass, Work-, Data-, Embed-). This layer forms the root of all inheritance and cannot be modified by application developers.

2. Organization (Enterprise Shared) Layer

Contains assets, data definitions, and user interface elements that apply across the entire enterprise, spanning all business units and subsidiaries. Typical rules placed in the Org layer include:

• Enterprise Data Classes (e.g., MyBank-Data-Customer, MyBank-Data-Address).
• Enterprise single sign-on (SSO) authentication rules and corporate directory integrations.
• Global corporate branding assets, logo sets, and enterprise design tokens.
• Enterprise-wide regulatory compliance rules (e.g., global GDPR/CCPA data privacy handling).

3. Division Layer

Represents a specific branch, subsidiary, or line of business within the conglomerate (e.g., MyBank-RetailBanking- vs. MyBank-WealthManagement-). Rules defined here apply to all applications within that specific division, such as division-specific general ledger accounting codes, regional escalation SLAs, or division-wide approval thresholds.

4. Framework Layer

Contains generalized, reusable business applications and domain logic designed to be extended rather than run directly. A Framework provides an end-to-end functional model (e.g., a generic LoanApplicationFW or ClaimsProcessingFW) containing case stages, data structures, and standard workflows. While a framework application can be executed for testing, production cases are not instantiated directly in framework classes.

5. Implementation Layer

Contains the concrete, customized applications deployed to production for specific business units or regions (e.g., MyBank-RetailBanking-USMortgage-Work-HomeLoan). The Implementation layer specializes the framework by overriding specific rules—such as localized pricing tables, jurisdiction-specific compliance steps, or regional branding—while inheriting all baseline workflow logic from the framework, division, and organization layers.

---

3. Class Types: Abstract vs. Concrete & Class Groups

Every class in Pega must be declared as either Abstract or Concrete.

Abstract Classes

• Naming Rule: The class name must end with a hyphen (e.g., MyBank-Data-, MyBank-Loans-Work-).
• Instance Rule: An abstract class cannot have persistent instances stored in a database table or created on the Clipboard as top-level case instances.
• Architectural Purpose: Serves purely as a structural template and parent class for inheritance. Abstract classes define properties, rules, and logic that child classes inherit.

Concrete Classes

• Naming Rule: The class name does not end with a hyphen (e.g., MyBank-Data-Address, MyBank-Loans-Work-AutoLoan).
• Instance Rule: A concrete class can have instances created in memory and saved to a database table.
• Architectural Purpose: Used for actual case types, persistent data records, and administrative configurations.

Class Groups (Work Pools)

A Class Group (commonly known to business users as a Work Pool) is a special administrative classification that combines related concrete work classes together so they share common storage and identification conventions:

• Shared Database Table: All concrete classes belonging to a class group persist their case instances into the same physical relational database table (defaulting to pc_work).
• Shared Key Generation: The class group manages unique, sequential case identifier generation (e.g., C-1001, L-2045), storing the prefix in the class group definition.
• Locking & Containment: Enables parent cases and child cases to coordinate transactional locking and assignment routing within the same work repository.

---

4. Class Inheritance: Pattern vs. Directed

When the Pega engine needs to find and execute a rule (such as a Data Transform or a View), it uses two independent inheritance techniques to traverse the class hierarchy: Pattern Inheritance and Directed Inheritance.

   PATTERN INHERITANCE (Namespace Prefix)           DIRECTED INHERITANCE (Explicit Parent)
   Follows hyphens backwards in class name         Explicitly configured on Class Rule Form
   
   Apex-FinServ-Mortgage-Work-Refinance ---------> Work-Cover- (Explicitly declared parent)
              | (drop -Refinance)                             |
              v                                               v
   Apex-FinServ-Mortgage-Work-                  Work- (Standard Pega Platform Work class)
              | (drop -Work-)                                 |
              v                                               v
   Apex-FinServ-Mortgage-                       @baseclass (Ultimate ancestor of all classes)
              | (drop -Mortgage-)
              v
   Apex-FinServ-
              | (drop -FinServ-)
              v
   Apex-

Pattern Inheritance (Algorithmic / Hyphenated)

Pattern inheritance is automated and based entirely on class naming syntax. The Pega engine examines the class name and sequentially strips off characters from right to left, stopping after each hyphen (-) to identify ancestor classes.

• If a case is executing in Apex-FinServ-Mortgage-Work-Refinance, pattern inheritance traverses to Apex-FinServ-Mortgage-Work-, then Apex-FinServ-Mortgage-, then Apex-FinServ-, and finally Apex-.
• Pattern inheritance reflects your enterprise organizational hierarchy.

Directed Inheritance (Explicitly Configured)

Directed inheritance is explicitly configured on the class rule form using the Inherits from (Parent Class) field. It allows a class to inherit directly from any other class, bypassing the hyphenated namespace.

• For example, Apex-FinServ-Mortgage-Work- explicitly designates Work-Cover- as its directed parent.
• This connects custom application classes to out-of-the-box Pega platform engines (such as Work-, Data-, Assign-, or @baseclass).

How Rule Resolution Interleaves Pattern and Directed Inheritance

When Pega searches for a rule, it evaluates both inheritance paths according to the class configuration. By default, Pattern inheritance is evaluated first, followed by Directed inheritance at each tier, until the ultimate root class—@baseclass—is reached:

1. Search the target class: Apex-FinServ-Mortgage-Work-Refinance.
2. Follow Pattern inheritance by stripping the final segment to search Apex-FinServ-Mortgage-Work-.
3. If not found in the pattern ancestor, examine that class's Directed parent (Work-Cover-).
4. Traverse Directed ancestors (Work- -> @baseclass).
5. If the rule is found at any step in an accessible ruleset version, the engine stops searching and executes that rule instance.

---

5. Enterprise Implementation Scenario: Apex Corporation

Consider Apex Corporation (Apex), a global financial services enterprise building a new digital Mortgage Refinancing system.

Class Structure Mapping

• Organization Layer: Apex-
  • Data types used across all subsidiaries: Apex-Data-Customer, Apex-Data-Address.
• Division Layer: Apex-FinServ-
  • Policies applicable to all banking and lending: Apex-FinServ-Data-CreditScore.
• Framework Layer: Apex-FinServ-MortgageFW-
  • General mortgage processing case type: Apex-FinServ-MortgageFW-Work-Mortgage.
  • Contains 85% of all core business processes, document collection steps, and underwriting workflows.
• Implementation Layer: Apex-FinServ-USMortgage-Work-Refinance
  • Specializes the framework for United States regulatory requirements (e.g., Fannie Mae compliance, US tax verification forms) and specific interest rate calculation tables.

If the US Refinance case references the customer's credit score property .CreditScore, the engine resolves it from Apex-FinServ-Data-CreditScore. When it triggers the approval flow, it executes the shared process defined at Apex-FinServ-MortgageFW-Work-Mortgage, unless the US team has created an overridden version directly in Apex-FinServ-USMortgage-Work-Refinance.