Best practices for enterprise class structure
Defining the enterprise class structure (ECS) is a critical task for an Application Architect because it establishes the foundation for scalability, reusability, and maintainability. ECS is the architectural blueprint that organizes rules within the Pega Platform™. It provides a hierarchical framework that governs the structure of business applications, which enables the reuse of common policies and procedures and supports specialization.
ECS is the primary mechanism for managing inheritance and sharing assets across an application portfolio. A clear and logical structure ensures that applications are part of a cohesive, maintainable, and scalable enterprise ecosystem.
A well-designed ECS supports Situational Layer Cake™, which enables specialized application behavior for different contexts (for example, jurisdiction, channel, or customer type) without duplicating Rules. By creating reusable assets in lower layers, organizations can quickly deploy new situational applications by adding or modifying Rules in higher, more specific layers. ECS is essential for governance and agility in enterprise Pega development.
Apply the following core best practices in your ECS design process:
- Start with the data, not the process
- Determine the true enterprise scope
- Design for specialization with Situational Layer Cake
- Implement strict and clear naming conventions
Adhering to these best practices is necessary for building a successful and sustainable enterprise application on Pega Platform. A well-structured ECS supports reuse, specialization, and governance across applications.
Start with the data, not the process
Avoid starting with Case Types and Processes. Begin by identifying the core business objects, the fundamental nouns that your business relies on, independent of any single process. For example:
- Data classes represent things.
- Work classes (Case Types) represent the work you do with those things.
A New Loan Case Type (Work-) references Customer (Data-) and LoanProduct (Data-). Define core Data- classes at the highest appropriate layer, typically the Organization layer, to act as the single source of truth across all applications.
Determine the true enterprise scope
The “E” in ECS stands for enterprise, but not every Rule belongs at the top layer. Placement depends on the reusability of the solution across the organization. Use the following questions to determine the correct layer for a class:
| Question | If yes, place in | If no, place in |
|---|---|---|
| Is this class/Rule reusable across the entire organization, regardless of division or application? (For example, the Employee Data Object.) | Organization layer (YourOrg-Data-Employee) | A lower, more specific layer |
| Is this class/Rule reusable only within a specific line of business or division? (For example, Claim data for the Insurance division.) | Division layer (YourOrg-Ins-Data-Claim) | A lower (Implementation) or higher (Organization) layer. |
| Is this class/Rule specific to a single application? (For example, a Travel Approval Case Type for a Travel and Expenses application.) | Implementation layer (YourOrg-App-Work-TravelApproval) | The most specific layer. |
Design for specialization with the Situational Layer Cake
ECS should enable specialization, not just inheritance. Structure your class hierarchy to reflect how your business creates process variations (for example, by country, product line, or customer tier). Include business dimensions in class names. For example, instead of Work-Claim, use YourOrg-Claim-Work-Auto and YourOrg-Claim-Work-Home. This approach supports shared organization policy at YourOrg and claim logic at the Claim level, and specialized logic for Auto and Home
Even if you have only one situation today, design ECS for future scalability. Adding a new variation (for example, Motorcycle claims) is easier if the structure is already in place.
Implement strict and clear naming conventions
Consistent naming enables pattern inheritance and improves readability. Follow the Organization-Division-App-Work-CaseType pattern. The Work- class in your Case Type hierarchy should be a class group, which stores all instances of that Case Type (and its child classes) in a single database table.
Use clear, unambiguous names. For example, NewHire is better than NH. Anyone reading the class name should understand its purpose.
Check your knowledge with the following interaction: