Pega - Enterprise Class Structure (ECS)

Every rule in Pega belongs to a class, and classes inherit from each other. If that tree is designed carelessly, teams end up copying rules, fighting over shared ones and struggling to reuse work. The Enterprise Class Structure (ECS) is Pega's recommended way to lay the tree out in layers so that reuse is easy and change stays safe.

The idea

Put things that are common to many applications high up in the tree, and things specific to one application low down. Lower classes inherit from higher ones, so a rule written once at the top is available everywhere below.

Typical layers

Layer	Example class	What lives here
Pega platform	Work-, Data-	Rules that ship with Pega. Never edit them
Organisation	MyBank-	Rules shared by the whole company, such as logo, standard properties, common security
Division	MyBank-Retail-	Rules for one business division
Framework	MyBank-Retail-FW-	Reusable case types and processes for a line of business, for example a generic loan process
Implementation	MyBank-Retail-Mortgage-	The application that uses the framework, with local changes

Under each layer you normally find the same two families of classes: -Work- for cases and -Data- for supporting data such as customers, products and addresses.

The diagrams

A worked example

MyBank has a mortgage application and a personal loan application. Both need a Customer data type and a credit check process.

1. The Customer data class goes in the organisation layer, so every application shares it.
2. The generic loan case type and credit check go in the retail framework layer.
3. Each application, mortgage and personal loan, extends the framework in its own implementation layer and adds only its own differences.

When the credit check changes, the fix is made once in the framework, and both applications pick it up.

Benefits

• Reuse without copying.
• Clear ownership. Each team knows which layer it may change.
• Simpler upgrades, because your rules stay out of the Pega layers.

Mistakes to avoid

• Building everything in one class and copying rules into each new application.
• Putting a rule too high. If only one application needs it, keep it in that implementation layer.
• Changing Pega's own classes. Override the rule in your own layer instead.

Interview tip

List the layers from platform down to implementation, say what belongs in each, and give the shared Customer example. Related: Class Group and the Class structure label.