Business change pipeline

In this video, you will understand how a business change pipeline facilitates change management in Customer Decision Hub applications by promoting business changes from the business operations environment (BOE) to other environments in the project.

A typical decision management project includes five environments. An orchestrator manages and automates the deployment process of artifacts to the candidate environments. A development (System of Record) environment develops enterprise capabilities. A staging environment tests the changes and analyzes their technical impact. A business operations environment (BOE) makes business changes. A production system provides real customers with the latest and greatest artifacts.

All application pipelines use a repository to move generated artifacts from one environment to another.

In a new project, you set up enterprise capabilities and core structure of the Customer Decision Hub application in the development environment. When the core development comes to a mature state and it is tested, you then deploy the application to all other environments.

Ensure that you make ongoing changes to next-best-action artifacts, such as changes to actions, treatments, models, next-best-action designer configurations, contact policy, and similar artifacts in the business domain, in the BOE. The changes are managed through revisions and are packaged automatically for you when you use 1:1 Operations Manager and Revision Management.

Consider UBank, a retail bank, that has five environments, including one orchestrator and four candidate systems, to deploy changes through the business change pipeline.

In the development environment, note that OLSTDRCDH is the overlay application. The application is built on CDH 01.01 (the enterprise application) with the OLSTDRCDH ruleset and the CDH-Artifacts ruleset. The current version is 01-01-01. OLSTDRCDHRM is a branch of the OLSTDRCDH ruleset. This is branch to which you merge business changes. At this point, the staging, BOE, and production environments are all in sync.

After the initial deployment is complete, the change management starts, and business users have completed their initial sprint. All the development is stored in the OLSTDRCDHRM branch in the BOE. When the Revision Manager deploys the change through the business change pipeline, the rules in the branch are packaged and moved to the repository to which all the environments have access.

For example, when the business content team on the UBank creates a new action in the 1:1 Operations Manager application in the BOE, the rules that are associated with the action are added to the branch. When the Revision Manager deploys the change, the rules from the branch are packaged and moved to the repository.

Then, the artifacts that are related to the new revision are imported and merged into the development system. Then, a new version of the enterprise application is created with the merged rules. A new application package is created for the enterprise application and sent back to the repository. This package is created from a predefined product rule, which is configured as part of the business change pipeline.

As the next step, the application package is deployed from the repository to the staging environment, and the enterprise and the overlay application versions are updated.

Next, the application package is deployed from the repository to the BOE, and the enterprise and the overlay application versions are updated.

Finally, the application package is deployed from the repository to the production environment, and the enterprise and the overlay ruleset versions are updated.

In the production environment, the change is activated in two stages. In the first stage, the production environment application ruleset stack version is updated, but a user action is required before the change can be deployed. The revision manager logs in to the BOE to enable a set of users who can view business changes. If the test users confirm that the changes are fine, you can make the actual change available to all other users. You achieve this two-stage deployment by using a second set of access group that is prefixed with rollback. During consecutive deployments, the original access group and the rollback access group are rotated.

Once the deployment through the business change pipeline is successful, the new version of the enterprise application with the new version of the overlay application ruleset is available in all the environments.

Typically, business changes can be one of two types: standard release and fast release revisions.

Regular business changes consist of one or more change requests. After individually implementing these change requests, when they are ready for deployment, the Revision Manager deploys all the change requests together as a release. This is called a standard release.

However, you might need to implement some unplanned business changes that are of high priority. These deployments are called fast releases.

Examples of fast release change requests include:

1. Fixing a typo in the action that was deployed to production (updating an existing action).
2. Deactivating an action from production (updating an existing action).
3. Communicating with customers in an emergency (creating a new action).

With fast release revisions, the business content team can implement and deploy critical business changes without having to wait for other change requests to be implemented and ready for deployment.

As a best practice, create two business change pipelines: one for the standard release and another for the fast release.