Specialization design considerations

Applications have a generalized purpose. Prior to Pega Platform version 7.3, a Pega application was considered one of the three following types:

• Non-production framework application
• Standalone production application
• Non-production non-framework application.

After multiple built-on applications were added in Pega Platform version 7.3, a Pega application was considered one of the four following types:

• Production
• Enterprise
• Reuse
• DevOnly

Pega Platform version 7.2 and earlier 

A framework layer "Is A" type of reuse layer, and the term "framework" has a particular meaning. "Framework" means an application that spans every case type an implementation application uses. 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 can refer to any type of application other than a framework application. An "implementation" application might be built on a framework application, and the term might apply to a reuse layer application that is not a framework application. Applications that are, instead, composed using smaller, special-purpose applications are considered "modular." 

Pega Platform version 7.3 and later

An application deployed to a production environment would be called a "Production" application. A Production application "Is A" particular type of "Implementation" application. It is improbable that a production application acts as part, or all, of another application's reuse layer; it is possible, however. 

Whereas a production application is at the top of an application stack, the "Enterprise" application is at the bottom of the stack, assuming that there are no additional components. The Enterprise application begins where Pega Platform-provided applications, such as PegaRULES, end. The Enterprise application is at the root of a potential "Enterprise layers (plural) Hierarchy." Each Division can have its own division-wise base application that is built on the base application of the layer beneath it.  

An application that is neither a production application nor an enterprise hierarchy application and is designed as a built-on application is the "Reuse" application. The Enterprise layer, or "Org" layer, can own a set of applications on which any application above can build. A division layer can do the same and have applications on which any application in the same Division can build. You can develop reuse applications top-down, starting from a set of production applications. Those reuse applications are not reusable Org- or Division-wise; they are only for reuse in a specific set of production applications. 

The fourth type of application is for use in a development environment only; a "DevOnly" application. A DevOnly application is any application that tests and supports the development of any application that is ultimately deployed to a production environment. You can use a DevOnly application to mimic REST services with which a production application interfaces. A DevOnly application is where the development of various automated tests (unit, API/integration, suite/regression) occurs. 

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 created on top of the Pega Platform layer, as shown in the following figure. That enterprise application is extendible and can be built on top of one or more Pega foundation applications, as shown in the following diagram:

A component is a Rule-Application where pyMode=" Component." Rulesets comprise a component; Component can mention other components or applications as prerequisites. Use the Components landing page in Dev Studio to create and manage components.  

It is typical for the component ruleset to use the Application Validate mode. In the application stack, components can exist under the application that references it and depend on that application's code, such as data models, libraries, and reusable data transforms and activities. 

Similar to regular reuse applications that are designed to be built on, the Enterprise layers (Org/Div/Unit) can include their own reusable components. Likewise, a Production Apps Layer can have its own reusable components. 

Pega Platform supports multiple built-on (MBO) applications, which means any application can be built on one or more modular applications.  An application built on multiple applications can extend classes from each built-on application and combine and enhance the functionality that the individual built-on applications provide.

Modular applications are cohesive in that they express a single purpose. Modular applications used as built-on applications are relatively simple and easier to understand, document, maintain, and reuse. A typical modular application might only encompass one or two reusable case types (journeys). The journeys are applicable or reusable in combination with other case types to create more complex composite applications that express specialized intra-case type relationships and dependencies.   

This Pega Community Tech Talk video Multiple built-on applications contains a demonstration and detailed discussion of multiple built-on applications. The MBO-flattening algorithm uses the lowest position or precedence of any repeated application and then uses the highest version of that application within the flattened application stack.

A Directed Acyclic Graph (DAG) is a tree structure in which a node can have more than one immediate ancestor or parent. There is no loop-back to where a circular path, closed loop, or cycle forms. 

A many-to-many (M:M) relationship is an example of a DAG. The Link- class in Pega Platform forms the base for several classes that support M:M relationships, such as Link-Attachment. The same reuse application can have multiple built-on applications on which you can build multiple other applications.  

As a best practice, avoid repeating the same application on the same path from a production application down to the enterprise application. But multiple paths from a production application can reach the enterprise application. And each path can have a different version for each application along the path, including the version of the enterprise application, and the path continues further. Different enterprise application versions can be built on different application versions of Pega Platform. 

The following figure shows the Application Dependencies View that you can create by using the Data Model Viewer in App Studio. The view rotates the Situational Layer Cake™ view counterclockwise by 90 degrees. Applications that belong to different horizontal layers in the Situational Layer Cake view are now displayed in the same column. For example, the second column from the right contains two sibling Division layer reuse applications and an enterprise production application. In the third column from the right, division 2 has decided to extend "Ent App 1" to its own "Div 2 App 2" production application. The third column from the right also contains two enterprise reuse applications and two division reuse applications, one for division 1 and the other for division 2.

Check your knowledge with the following interaction: