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.

When the initial deployment is complete, all environments are in sync and have the same application ruleset stack and versions. After this point, business users can start making changes to the next-best-action artifacts in the BOE and deploy these changes to other environments through the business change pipeline.

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.

Here is an example of how a business change is initiated from the BOE and then promoted to the other environments.

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 Business Change is the overlay application. The application is built on UBank 01.01 (the enterprise application) with the BusinessChange ruleset and the UBank-Artifacts ruleset. The current version is 01-01-01. BusinessChangeRM is a branch of the BusinessChange 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 BusinessChangeRM 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.