Designing decision services
This chapter describes the goal of operational decision management to enable you to represent and manage high-value business decisions, and to make them executable in the context of an IT-based business solution. This decision-making capability can be considered a service in the context of a service-oriented architecture (SOA).
The IBM Operational Decision Manager (ODM) platform provides many artifacts to support the definition and the structuring of decision services, both in the context of the rule authoring phase (by using rule projects and rule packages artifacts) and the rules deployment phase (by using artifacts such as rulesets and RuleApps). This chapter describes how to use these constructs to structure a decision service.
This chapter covers the following topics:
5.1 Concepts
This section describes some of the essential concepts used when discussing the organization of decision management.
5.1.1 Decision service
A decision service is a collection of rule projects that contain business rule artifacts (such as action rules). Within each rule project are rule packages that group rule artifacts in a functional hierarchy. Rule flows orchestrate the execution order of rule packages to determine the execution sequence of rule artifacts in response to a decision request.
IBM Operational Decision Manager groups rule artifacts, flows, and parameters in an executable unit called a ruleset. This ruleset has a defined signature in terms of inputs and outputs. The ruleset signature is exposed as a service directly via Java invocation or via SOAP/REST. The service can be used as the interface for testing activities.
A decision service is the unit of deployment of decisions in ODM. Business solutions call decision operations as a service. The decision service is managed, delivered, and deployed by decision governance.
The decision service contains the following components (Figure 5-1):
Deployment configuration One or more destinations of the servers to which the service is deployed.
Decision operations Defines one or more signatures for calling the decision service.
Business logic The rules implementing the services.
Business object model The vocabulary on which the business logic is based.
Figure 5-1 Decision service
The deployment manager manages the deployment configuration for the decision service. Each deployment configuration lists the associated decision operations and target servers, and defines the version policy for numbering the operations. A business solution calls a decision by using the name and version number of a decision operation.
The business user works with decision services in the Business Console. The
Business Console provides governance services for managing, testing, and deploying decision services. Changes to the rules in a decision service are coordinated within a business release.
Business Console provides governance services for managing, testing, and deploying decision services. Changes to the rules in a decision service are coordinated within a business release.
Decision operations
The decision operation defines which rules from a given branch are part of the ruleset. A decision operation includes all of the settings needed to define the contents of a ruleset and its parameters. You choose which decision operation to use when creating a test suite, simulation, or deployment configuration.
Client applications interact with a ruleset by using input and output parameters. These parameters are defined in the signature of a decision operation.
The parameters of a ruleset can have three directions:
•Input: The parameter value is provided as input to the ruleset on execution.
•Output: The parameter value is set by the execution of the ruleset and provided as output from the ruleset at execution completion.
•Input/output: The parameter value is provided as input to the ruleset on execution and its value can be modified by the ruleset and provided as output at execution completion.
You create the parameters from any of the ruleset variables that are available in the projects that are part of the scope of the decision operation. Ruleset variables are internal to a ruleset and provide a way to exchange data between rules, functions, and tasks.
Ruleset content
In the decision operation, the ruleset content is defined by specifying the following information:
•The source rule project. All the rules and variables contained in this project and any of its dependent projects become eligible to be included in the ruleset. This is usually the name of the decision service project.
•Ruleflow. The ruleflow to include in the ruleset and which is used for the orchestration of the execution of the rules.
Advanced configuration settings:
•A query to filter the rules so that only a subset of the rules of the source rule project and its dependent projects are included in the ruleset. Typically, this is used to include rules from specific folders of a project or according to a rule property such as status. You write queries in the Queries tab of the Business Console.
•A validator to filter the rules. A validator can be written in Rule Designer to select the required rules. If you specify both, the query is processed first, then the validation
is applied.
is applied.
5.1.2 Execution object model
The execution object model (XOM) (Figure 5-2) is the model against which you run rules. It references the application objects and data, and is the base implementation of the business object model (BOM). BOM Rule projects reference the XOM.
Figure 5-2 Executable object model
5.1.3 Business object model
You use the business object model (BOM) to make business rule editing easier by providing tools to set up a natural language vocabulary. With this vocabulary, policy managers can describe their business logic in a business rule language.
The BOM is the basis for the vocabulary used in business rules. It is an object model similar to a Java object model, and contains elements that map to those of the XOM.
BOM-to-XOM mapping defines the correspondence between the BOM and the XOM used at run time.
5.2 Project hierarchies
To offer the best flexibility over time and to make it easier to maintain and test rules, configure decision services in a rule project hierarchy. Projects can then be configured to refer to one another.
The project hierarchy should be used for the following functions:
•Separating decision service projects and decision operations from rule projects
•Grouping business rules by subject area, region, or another grouping that makes business sense to reduce the overall number of rules in a single project
•Separating BOM from business rules to allow BOM reuse among multiple rule projects
•Separating BOM entries by subject area to limit the size of the BOM to avoid potential performance issues
For example, if a client application calls different decision points, you should arrange the project structure to organize each decision operation and its ruleflow in a project. In addition, organize its unique rules in a separate rule project for that specific task. Furthermore, you can keep the BOM required for this specific set of rules separate to specify the vocabulary that is available only to those rules. This chapter describes some common project hierarchies.
The BOM is an entity that is reusable across the different operations of a service, and sometimes part of it reusable across the overall organization. It is also an entity that evolves less frequently than the rules during the decision lifecycle. Thus, it often makes sense to define a common BOM project for the decision service.
As a convention, no other artifact than the BOM is defined by this project. Any decision service involves at least one such BOM project, but there can be more than one depending on the complexity of the BOM and the scope of the decisions. These BOM projects are referenced (directly or transitively) as needed by all other rule projects to support the definition of the rule artifacts.
In Decision Center, releases apply to all of the projects in the hierarchy. Organizing an efficient project hierarchy enables you to manage rule change and deployment per
specific project.
specific project.
5.2.1 Diamond-shaped project hierarchy
In a diamond-shaped rule project organization, the decision service project contains a ruleflow that uses rules from other rule projects in the hierarchy. The rule projects share a common BOM that is kept in another rule project (Figure 5-3).
Figure 5-3 Diamond project structure hierarchy
5.2.2 Our sample project hierarchy evolution
|
Important: It is always easier to perform the restructuring of projects in Rule Designer before having synchronized with a Decision Center database. Doing so after synchronization requires careful planning and the execution of specific steps to avoid issues later.
|
To demonstrate how a project can evolve over time, we walk through the evolution of the project hierarchy for the sample decision service that we use throughout this IBM Redbooks publication.
We first start with one decision service and a single operation in that decision service, this service uses the rules in the Loan Validation Check project (Figure 5-4).
Figure 5-4 Loan Validation Service organization
Over time we might want to add new projects that share the same BOM and variables. To achieve this, we need to restructure the Loan Validation Check project and to separate the two main artifacts that it contains: The rules and the BOM.
Complete the following steps:
1. In Rule Designer, we create a Loan Validation Base project and move the BOM and variables to this new project and add the dependency from Loan Validation Check to Loan Validation Base.
2. We can then also create the two new projects required for organizing the rules: Loan Validation Determination and Loan Validation Scoring (Figure 5-5).
Figure 5-5 Loan Validation Service Organization - Refactored
3. The final step of our reorganization requires the addition of a second operation that has additional return values in the response of the call to the service: The score and the grade (Figure 5-6).
Figure 5-6 Loan Validation Service Organization - Final
Figure 5-6 shows the rule project structure for the Loan Validation Service.
The Service is separated into two operations:
•Loan Validation Production Operation
•Loan Validation with Score and Grade
The two services are virtually identical except that the second one returns two more parameters that contain the score and the grade for the loan application. They run the same ruleflow (loanvalidation).
5.3 Folder structure
To make it easier for rule authors to quickly and intuitively navigate to an existing rule or to a location where they can create a new one, rules are organized using a rule packages hierarchy. The packages hierarchy allows you to group rules that are logically related by a business dimension.
For example, the folder hierarchy follows the same steps as the decision process, and each package ends up being associated with rule tasks in the ruleflow. Subpackages can then be divided along other business dimensions, such as a specific product characteristic or the geography in which the rules apply.
As an example of the structure of the folders by business dimension, Figure 5-7 shows that the Loan Validation Check project contains a validation folder that contains two subfolders: One for the borrower rules and one for the loan rules.
Figure 5-7 Folder structure of the Loan Validation Service
As an example of the structure by steps of the decision process, we first need to look at the ruleflow that orchestrates the overall execution of the rules in Figure 5-8 on page 70. Then we can go back to Figure 5-7 and see the folders corresponding to each of the rule tasks (validation, computation, eligibility, and insurance).
|
Tip: It is advised that each project has a unique folder hierarchy. This can easily be achieved by creating a uniquely named root folder.
Tip: When building ruleflows, it is not recommended to have rule tasks select individual rules or decision tables. The rule task should select the folder, so that if new rules are added to the folder, they are automatically included in the ruleflow.
|
5.4 Orchestrating ruleset execution
Rules apply decisions, but they do not have a defined sequence or succession. A ruleflow organizes rules into a sequence of decisions by assembling the rules into a group of rule tasks that uses a set execution pattern.
Each rule task is evaluated to produce a result, or decision. All of these results and decisions are combined to produce a single business decision, which is represented by a ruleflow. Ruleflows also specify conditional transitions between rule tasks.
The transitions determine how, when, and under what conditions to use each rule task (Figure 5-8).
Figure 5-8 Ruleflow of the Loan Validation Service
5.5 Advanced topics
This section provides additional details about some of the more advanced topics.
5.5.1 Adding projects
Refactoring projects is straightforward when performed in stand-alone Rule Designer, and ideally the design of the project structure is completed in Rule Designer, before being synchronized with Decision Center.
After a decision service has been synchronized to Decision Center, refactoring projects and adding new projects to a decision service can be a bit complex. This process is described here as a reference for readers who might want to experiment with the steps described earlier in this chapter.
Steps to add a project
We have described steps in the evolution of the design of a decision service, we think it is helpful to provide the steps required to add a project in a decision service when it is already synchronized with Decision Center:
1. Import the branch/release of the decision service that you want to add the new project to into Rule Designer from Decision Center.
2. Create/import the new project that you want to add to the release/branch of the decision service.
3. Right-click the new project and connect it to Decision Center.
4. Publish this new project to Decision Center (this creates it in the main branch).
5. Add the dependency to this new project to the main project of the previously imported decision service.
6. Synchronize the decision service again, publishing the new dependencies (the .ruleproject file update).
7. Refresh (leave the Decision Artifacts page and return).
5.6 Conclusion
This chapter provided guidance on designing decision services so that your project can evolve as easily as possible over time. We learned that the following general practices help accomplish this goal:
•Separate the BOM project, Rules projects, and Decision Service project to provide the best flexibility over time.
•It is easier to manage permission at the project level, which means that separating rule projects by business domain is a good practice.
•Rule packages and folders are used to group rules that are logically related so that it is easier for an author to locate the rules they need to work with.
•Establishing the design of your project organization needs to be done early and in Rule Designer to avoid later refactoring.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.