Change management

In Decision Center, you can manage changes to rules over time through the creation and management of branches. The recommended way of managing changes is through releases and activities within a decision service.

Releases and activities behave as branches and subbranches of your decision services, but with some special considerations.

To understand how changes are managed under this approach in the Business console, consider the following sequence, and then read the sections that follow:

You complete a release, signifying the end of that release, and then deploy its content as a decision service.
You start a new release that is based on an existing, completed release.
You change rules in a release by using change activities, in which one or more participants work.
When all the change activities that are related to the release are complete, you validate the release, and then complete it.

Releases

Because rules change over time, Decision Center uses releases to capture and trace all the changes that are related to a purpose and period in time.

The purpose is a set of business-driven goals, and the time is a beginning date and an end date. A release tracks and manages the changes that are made by its participant users and the validation of these changes (see Governance principles.)

Each new release stems from an existing release. Work occurs on the release while it is open, and ends when you complete, approve, and deploy the release.

The following image shows how releases evolve over time, and that the content of a closed release can be merged into an open one:

Diagram shows releases that change over time.

You cannot edit a release directly. You must create and work in change activities of the release. You can make as many change activities as are needed to carry out your objectives.

Change activities

Decision Center uses change activities to manage the work of participants who are collaborating toward a goal, in the larger context of a release.

In a change activity, participants create, modify, or delete rules and get these changes approved (see Governance principles.)

Each change activity stems from a release. The change activity contains the version of the rules that are found in the release at the moment when the change activity is created. When a change activity is complete, Decision Center merges it back into the release.

You can create many change activities for a release. When all the change activities are approved, a validation activity can occur on the release.

If you create a change activity before an existing one is completed and merged, the same rule might be subject to change in both activities. To avoid such conflicts, a rule that is being edited in a change activity is locked until the activity is completed and merged.

The following image shows how different change activities merge back into the release when they are completed:

Diagram shows different change activities in a release.

Validation activities

You create and manage validation activities in the Business console, and use them to track and manage a validation of the content of the release. This approach can be manual tests that are entered in a test plan, automatic tests through test suites, or simulations.

It is not possible to run a test suite or simulation directly from the release. You must use a validation activity to run a test or simulation on the version of the rules that are contained in the release.

When all the validation activities are completed, the release can be approved and completed, at which point deployment can occur.