Application overlays

In a Pega Customer Decision Hub™ project, the initial implementation begins in the development environment.

During this phase, the project team conducts workshops to establish a data model, identify gaps, and leverage industry-specific accelerator components that can help to reduce the implementation time. A system administrator then runs the Customer Decision Hub setup wizard in the development environment to build all the necessary artifacts to start the implementation process.

The setup wizard creates four key applications:

• An implementation application for Customer Decision Hub (the enterprise application).
• An implementation application for 1:1 Operations Manager (1:1 Operations Manager extension).
• Two overlay applications for supporting business changes: Standard release and Fast release.

The following figure shows how the applications stack after the completion of the setup wizard:

The implementation applications support the technical development and extension of the Customer Decision Hub and 1:1 Operations Manager enterprise applications. In this first phase, typically, all development takes place in enterprise applications.

An application overlay is an application that is built on top of the enterprise application. It specifies the extent to which business users can modify the decisioning application to adapt to changing business conditions and requirements.

The application overlay exists strictly to support the change management process after the migration of the application to the business operations environment (BOE). These applications are not for use in development or production environments.

The standard release application (OLSTDRCDH) allows the business content team to continuously add new actions and treatments, usually planned and following a strict release schedule.

The fast-release application (OLFRCDH) is for making urgent, unplanned changes to live content in the production environment, with high priority and a flexible release cycle.

The change management process is a collaborative effort between operations, business, and technical teams. In this process, the goal is to deploy efficient and agile business changes to the production environment without interfering with technical enterprise deployment cycles.

Pega 1:1 Operations Manager extends the standard revision management features of Pega Customer Decision Hub by providing a simple process where a non-technical team member triggers a business-as-usual change request by using a transparent user interface.

In the BOE, Team Leads, business users, and NBA Specialists use Pega 1:1 Operations Manager for high-volume, fast-paced content development while Next Best Action Designers use Customer Decision Hub to make low-volume modifications to rules that are available as part of the revision management process.

Before the start of change management, the System Architect, with the help of the Lead Decisioning Architect, adds a set of rules to the application overlay as revision records. These revision records are included in the revision management process and are available in BOE to implement business changes. Once the rules are added to the revision ruleset, you cannot modify the rules in the development environment. Only in the Business Operations environment can you modify the rules through the change management process.

Rules that non-technical users commonly modify are good candidates to be part of the revision records. You can include the artifacts such as prediction rules, decision strategies, NBA configurations, and so on, that you developed during the implementation phase. Do not include rules that are automatically managed by the 1:1 Operations manager in the revision management.

In the BOE, each business requirement translates into one or more change requests. The project team processes and completes these change requests. All change requests are associated with a single revision. After all change requests go through unit testing, you can complete the revision and deploy it to production. The system stores all updated rules that are associated with the revision in a branch ruleset referred to as the revision branch. As a best practice, use Deployment Manager to orchestrate the deployment process. However, you can deploy the revision through other means if necessary.

During deployment, the Deployment Manager moves the revision branch to the development environment, where the updates will be merged into the enterprise application. The system creates a new version of the enterprise application and automatically updates the application definition with the new merged ruleset version. The application is then packaged and deployed to higher environments, such as staging, BOE, and production.