Processes
IBM Operational Decision Manager (ODM) provides powerful capabilities to govern changes to business rules, but does not prescribe the precise orchestration of these capabilities. It is up to individual organizations to implement these processes. Processes describe the interaction between actors in the decision governance workflow. Actors could be human or automated (scripted). Processes also implement the integration of the decision governance workflow with IT Governance.
The goal of processes is to manage and control business policy change, and to ensure that all stakeholders are united in delivering IT and business releases. There are three process types:
•Processes that define business releases, including activities such as rule authoring, rule testing, rule deployment, rule retirement
•Processes that require technical changes, including activities such as Java execution object model (XOM) maintenance
•Processes that require a mix of business and technical changes
Processes for your organization can be affected by the following factors:
•Your users, roles, and responsibilities.
•Whether your processes are technical or business led.
•The “safety” of your rules. Can they be deployed directly by business users, or do they go through a full system test cycle before deployment?
•Service level agreements (SLA) for change. Are changes delivered the same working day, or are they delivered in monthly or quarterly cycles?
We explore some suggested processes to give you a starting point for defining your own initial IT release processes, business processes, and technical change release processes.
This chapter covers the following topics:
6.1 Introducing the business release process
A business release contains one or more changes to the business policy. Business releases contain change activities and validation activities. A single business release contains one or more change activities and zero or more validation activities, as illustrated in Figure 6-1.
Figure 6-1 Components of the business release
A change activity is a modification to a single business policy approved by the change control board (CCB)1.
A validation activity determines the test criteria for the change activities within the release. When all validation activities have passed, the release can be approved and deployed. A single release contains zero or more validation activities.
6.1.1 Change activities
A change activity is the smallest management unit of change. It is initiated by the Change Control Board in the following situations:
•Response to market conditions
•Response to new requirements and regulations
•Corrections to existing decisions
These situations initiate a change activity that is justified, prioritized, and tracked by the business to provide visibility and traceability. A leading practice is that a change activity should be as granular as possible, and that it corresponds to a single goal.
Each change activity can affect one or more business rules. The change activity has a status that provides a view of where this change activity is in its lifecycle. See “Change activity lifecycle” on page 87 for more details.
6.1.2 Validation activities
Validation activities ensure that the goals of the change activities are met and verified. If the validation fails, the change activities are rejected and the activity is revisited. A validation activity is not required if you choose to use the approval step within the change activity to perform validation.
The following validation activities exist:
•Peer review, including verifying the difference between current and previous versions of the rules from an IT and QA point of view.
•Rule review and validation from a business point of view, verifying that the rule meets the goals defined in the change activity.
•Simulation and comparison of the results to previous releases to ensure that the results are expected.
•Non-regression tests.
•User acceptance tests.
•Integration testing with external systems that interact with the decision service.
Validation activities are addressed in more detail in section 6.1.2, “Validation activities” on page 75.
6.2 Documenting processes
The documentation of processes helps formalize the communication and responsibilities between the actors involved in the processes. It provides traceability for auditing and reporting. It ensures that information flows faster to more people.
The documentation can also be used as a communication and training tool for new team members. It reduces the knowledge loss when other team members leave. Documented processes provide a baseline that can be used for process improvement for your organization.
6.3 Sample processes
There are many processes to consider in the governance of decisions, and this chapter provides examples that can be used as a starting point for organizations to build their own internal processes. The processes shown in the following sections can be used as inspiration for the change processes your organization can put in place.
To keep it as simple as possible, assume that a release contains only one activity. Then we can enlarge and consider a process containing multiple activities.
Consider some possible processes for each type of release discussed earlier:
•Process to create the initial release
•Process for subsequent IT releases
•Process applying to the business release
•Process applying to the technical release
6.4 The IT Centric Process
In the IT Centric process, we distinguish between the initial release, and subsequent IT releases.
|
Notes about the initial release: The first publishing of a decision service to Decision Center creates an initial, closed release in Decision Center.
In a Business Centric process, subsequent changes to the decision service in Decision Center take place in releases that are created from this initial release. The initial release is not typically deployed to production because it has not been tested by the business.
In an IT Centric process, the initial release may be deployed to production because it was typically tested before being synchronized with Decision Center.
|
6.4.1 The initial IT release
The initial release is IT Centric and is the starting point of the decision service lifecycle. It contains initial business rules, decision service, and supporting application infrastructure.
The IT department consults with the business to ensure that the rules are understood and maintainable.
This release might not necessarily be the first live deployment, because the business might need to make further changes in Decision Center and produce a business release before going live.
The initial release is the starting point of your decision service lifecycle, and is required whether you choose to implement decision governance or IT governance.
Figure 6-2 The initial release
The main contributor of the initial release is the Rule Developer who works in Rule Designer, as illustrated in Figure 6-2. They develop the technical rule artifacts, the rules, and the decision service. The first version of the decision service can be deployed from Rule Designer to Rule Execution Server. In this release, business users access the rules in Decision Center, but in view mode only. They are not granted the permission to make any changes.
This phase is the right time to practice and tailor the decision governance process, and to train the business to ensure that they are ready for making changes.
We can formalize the steps for such an IT Centric cycle:
1. The business SMEs define the rules matching the business policy, and pass the requirements to the Rule Developers.
2. The Rule Developer develops rules and the decision service in Rule Designer.
3. The Rule Developer publishes the decision service to Decision Center for business users for review.
4. Business users access the rules in Decision Center, but in read only mode.
5. When business users identify a need to change the rules, they notify the Rule Developer by using requirement documents. The Rule Developer implements the changes in Rule Designer, and then publishes the updates to Decision Center, where the business users have an up-to-date copy of the rules. Versions are maintained in Decision Center this way, but change is driven from Rule Designer.
6. The decision service is deployed for the first time from Rule Designer to Rule Execution Server.
|
Note: The previous sequence of steps can slightly differ if we consider, in the decision governance perspective, as described in Chapter 7, “Decision governance framework” on page 85, that the business users validate the initial IT release by performing validation activities in a new release created from the initial IT release. Refer to section "7.2.2, “The first IT release” on page 90 for details.
|
The previous sequence of steps is illustrated in Figure 6-3.
Figure 6-3 Steps of initial release Creation
In the initial IT release, because all rule authoring and management is performed from Rule Designer, this IT Centric cycle is appropriate for Rule Developers familiar with programming languages and development environments. There is only IT governance in the initial release, so there is no role-based permission management for business users.
6.4.2 Staying in IT: IT release for subsequent releases
If your organization chooses to use IT governance for all subsequent changes, Rule Designer remains the tool for all releases. The rules source of “truth” is the source code control repository. If the business users identify a need for changes, they provide their feedback to IT by using requirement documents. IT processes the changes in Rule Designer in subsequent releases. Each new release is built upon the previous completed release.
The different steps of building a technical release in an IT Centric cycle are shown in Figure 6-4.
Figure 6-4 Subsequent technical release process
6.5 The business release
The business release is where the business takes over from IT after the initial release. Each business release is enforced by the decision governance features of ODM, and follows a strict workflow to ensure that changes to business policies are constrained, tested, and correct. Business releases can be deployed frequently to reflect up-to-the-minute business requirements.
Figure 6-5 The business release
The main actors of the business release are the business owner and the team. The team can consist of business analysts and rule authors, or just rule authors.
The business owner and the team reviews the rules from the Business Console, and if they identify the need for change, they change rules in the Business Console, given their access rights. These depend on the permissions enforced in Decision Center. Decision Center is the source of “truth” for the rules, and the business drives deployment to Rule Execution Server from the Business Console, as illustrated in Figure 6-5.
We can formalize the following steps for such a business release:
1. The initial release was created, as shown in 6.4.1, “The initial IT release” on page 76, and a new release was created from this initial release.
2. The business user updates and creates rules in the Business Console.
3. The deployment manager deploys the decision service to a test Rule Execution Server where business users validate the rules.
4. After validation is complete, the deployment manager deploys the decision service to Rule Execution Server from Decision Center or, more typically, generates a decision service archive from the Business Console and places it in a shared location where the deployment team then deploys it to the Rule Execution Server.
In this type of release, because all rule changes are driven from the Business Console, there is no possibility to modify the XOM, so rule changes cannot concern any model update or return type changes. Only rule logic changes can be handled, based on an existing BOM model.
6.5.1 Simple business rule change
The process in Figure 6-6 shows the minimum set of activities required to implement a simple business rule change.
For example, this process is used to make a simple change to a rule or a decision table. For example, if a production issue is found and must be fixed quickly. A new release, called “Bug Fix-xx Release” will be created from the current release, and the fix will be implemented in this release. The creation of the release is not represented in the diagram. Only the development and testing activities are represented.
Figure 6-6 Business simple rule change process
Here are some notes about this process:
•The change activity is assumed to include the rule author’s validation to prove the change works.
•The business validation activities can only start after all of the change activities are approved.
•The deployment of the test fix occurs immediately after the validation is approved.
•The change is considered simple enough to not require a second validation step before deployment to production.
6.5.2 Complex business rule change process
This process describes activities to be undertaken if the release requires complex changes to business rules, but does not require technical support from IT.
The complex business rule change process includes an extra validation step performed in a user acceptance testing environment, as shown in Figure 6-7. Some organizations might have a different second validation step, but multiple validation is a common practice.
Figure 6-7 Business complex rule change process
6.6 The technical release
At some point, technical changes need to be applied to the decision service, such as enhancements to the Business Object Model or to upgrade ODM. In its simplest form, this cycle requires the business to stop work and allow IT to synchronize their changes to Decision Center. If regular business releases are required, this is not feasible. A more realistic approach is to allow both business and IT to work in parallel, as shown in Figure 6-8, and use the advanced synchronization and merging capabilities of Decision Center to handle conflicts between IT changes and business changes.
Figure 6-8 The technical release
The following actors are the main actors in this type of release:
•The Rule Developer, who performs and implements technical changes in Rule Designer
•The business users (rule authors, business policy analysts), who continue to apply business policy changes in Decision Center.
At some point, when the Rule Developer has sufficiently debugged and tested the decision service in Rule Designer, he synchronizes the decision service with Decision Center and use the merging features of Operational Decision Manager to reconcile his changes with the changes that the business team has made. Decision Center allows fine-grained reconciliation between the IT and the business versions. Specifically, it offers capabilities to update, override and update, publish, or override and publish each project element that has changed.
Figure 6-8 on page 80 shows the process that you can formalize with the following steps:
1. Before performing any change in Rule Designer, the Rule Developer synchronizes (updates) the latest decision service projects from Decision Center to his development environment.
2. The Rule Developer implements technical rules changes in Rule Designer, for instance performing XOM changes or updating the rule flow.
3. The Rule Developer publishes the decision service to Decision Center in a new release called IT release, for business users’ review.
4. In the meantime, business users might have been creating additional releases in Decision Center.
5. Business users review the latest technical updates and, if they are happy with them, merge their latest business release to the IT release. If the changes are complex, they might require assistance from IT.
6. After the Business changes have been merged with the IT changes, the IT release goes through the regular testing cycle before being deployed to the production environment.
The previous steps are represented in Figure 6-9 on page 82 and Figure 6-10 on page 83. As the resulting diagram is wide, it was split into two diagrams for clarity of reading. Figure 6-9 on page 82 shows the development phase, while Figure 6-10 on page 83 shows the following validation and deployment phases. Links were used in the diagrams to show the next steps.
Figure 6-9 Technical release Process, Development Phase
Figure 6-10 Technical release Process, Validation and Deployment Phase
6.7 Conclusion
We have provided four types of processes that can occur in changing business rules, namely the initial release, the IT Centric release, the business release, and the technical release. The processes shown in this chapter can be adapted by readers to make them appropriate for their organization. Some organizations might decide to add more steps and create additional processes to handle the reality of their environment.
1 In SCRUM terminology, it is the Business Owner who creates change activities after reviewing the backlog.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.