Specialization design considerations

Always follow object-oriented principles to ensure rules are extensible. For example, use parameterization and dynamic class referencing (DCR) to support specialization in the future.

When considering specialization, be aware of the following items:

• A specialization layer need not be specific to one type of application. Instead, a specialization layer can support multiple applications across an enterprise.
• Circumstancing, pattern-inheritance, and data modeling techniques may eliminate the need to define a specialization layer for an application.
• A specialization layer can be composed of multiple built-on applications.

A framework layer "Is A" type of reuse layer. The term “framework” has a particular meaning. “Framework” means an application that spans every case type that an implementation application would use. A “framework” represents an entire layer by itself. An implementation application’s work pool class would extend the framework application’s work pool class.

The term “implementation” application has been used to refer to any type of application other than a framework application. An “implementation” application may or may not be built on a framework application. The term could apply to a reuse layer application that is not a framework application. Applications that are composed by leveraging smaller, special-purpose applications would be considered “modular.”

An application that is deployed by a CI/CD pipeline to a production environment would be called a “Production” application. A Production application "Is A" special type of “Implementation” application. It is improbable that a Production application would be used as part, or all, of another application’s reuse layer.

Most development efforts can achieve the minimum lovable product (MLP) by developing a production application built on top of an Enterprise application layer. The enterprise application is initially made on top of the Pega Platform™ layer. That enterprise application can then be extended to be built on top of one or more Pega foundation applications.

A framework-less application is the best approach in the following scenarios:

• The enterprise does not span multiple regions where business rules vary dramatically.
• The enterprise is interested only in completing the implementation of a framework developed by a vendor. The enterprise does not need or want to extend its application.
• The enterprise has divisions that develop division-unique applications.

In special cases, the development effort may require a reuse layer on which one or more applications are built.

This diagram shows the specialization of an application across different regions in North America. The procedures and policies specific to a region are layered on top. Every time the system interacts with a user or advances a case, it selects the policy and procedure that is most specific to the situation at hand. For example, only those policies and procedures that are specific to French-speaking Quebec need to be defined in that layer. For all other regional policies and procedures, the more generic layers beneath are consulted in order.

A reuse layer on which one or more applications are built makes sense in the following scenarios:

• The enterprise spans multiple regions where business rules vary dramatically and most of the core functionality will be reused across the enterprise.
• The enterprise wants to target distinct customer types while leveraging a core application. Business rules vary dramatically between customer types.