More options

Rating

Abstract

This IBM® Redbooks® Solution Guide describes how to build a decision management solution with IBM WebSphere® Operational Decision Management V8 that can be incorporated into a business process management system.

Related Publications

Contents

Automate, govern, and improve operational decision making across business processes and applications for better business outcomes

Make more profitable decisions with real-time detection of opportunities and risks

Implement changes easily, reliably, and securely in order to meet new market demands or policy requirements

This IBM Redbooks® Solution Guide describes how to build a decision management solution with IBM WebSphere Operational Decision Management V8 that can be incorporated into a business process management system. Decision management is illustrated in Figure 1.

Figure 1. What is decision management?

Did you know?

WebSphere Operational Decision Management supports both business rules and events, but do you know the difference? A business rule application receives data synchronously, responds synchronously, and is stateless. By comparison, an event rule application is called asynchronously, can trigger an asynchronous response, and might be stateful if it correlates the current event with any previous events.

An example of a business rule is:

if the value of the claim is greater than $1,000 then set manager approval to mandatory

An example of a business event is:

if the number of claims of the customer within the last month is greater than 4 then send a request to the call center to contact the customer

Business value

Almost every business application must implement some form of business rules. Traditionally, business rules have been implemented in a programming language such as Java or COBOL. Programming the business rules into an application leads to a number of concerns and problems that arise in development and maintenance of the application. For example:

The rules written in a programming language are not accessible in a form that is understandable to those who define the rules, namely the business users.

A number of applications might implement the same policies. Having the rules tightly embedded within one application makes it harder for other applications to access the rules.

At times, there might be no standard for business rules, which causes applications to implement the rules inconsistently.

Resources are required to develop, test, and analyze programming of the rules. The process can become costly in real dollars and time to implement.

It can be difficult to produce meaningful assessments when auditing rule execution to ensure that it supports business requirements.

Simulating new rules is often time consuming, which affects the ability of the business to react quickly.

A decision management solution resolves these issues by providing a single source of truth for an organization's business policy. This enables the organization to streamline the development, testing, simulation, and auditing of its policies. A decision management system should be constructed in a way such that non-technical business users can easily view, maintain, and test rules, often with little or no assistance from technical resources.

WebSphere Operational Decision Management embodies all of these qualities and is an ideal decision management solution when combined with a business process management system.

Solution overview

In many enterprises, business process management and decision management are complementary capabilities. Simply put:

A business process tells you what to do.

Decision management tells you how to do it.

Sometimes organizations attempt to map business processes without using decision management. If the decisions that drive these processes are simple and infrequent, and if the decisions do not interact with other systems, then it is possible to embed your decision logic within a process. However, implementing complex decisions within a business process without some form of decision management can lead your processes to become large, complex, and difficult to understand and maintain, as shown in Figure 2.

Figure 2. Complex business process with embedded decision logic

Adding decision management to the process can help reduce the complexity of the process by simplifying parts of it that are decision services. At the same time, removing the decision logic from the process enables that logic to be reused elsewhere within the enterprise. Figure 3 shows how it is possible to extract decision services portions of a business process to create a decision management solution. As you can see, this new solution would call on three decision services:

Eligibility

Risk Scoring

Offers and Promotions

Figure 3. Business process simplified by extracting decision logic

Extracting the decision logic provides a core business benefit in that the business rules and event rules can be managed by the business users. This represents a large cultural change for many organizations because it allows business users to make system changes without requiring the involvement of the IT department.

Solution architecture

The components of WebSphere Operational Decision Management are shown in Figure 4 and described in the sections that follow.

Figure 4. WebSphere Operational Decision Management V8

Decision Server

Decision Server is the runtime component where business rules and event applications are installed and executed. Typically, Decision Server is hosted in a Java based application server, and is packaged with WebSphere Application Server. It can also be installed and run on other application servers or without an application server, albeit with limited capabilities.

Decision Center

Decision Center is a repository where rules are recorded and stored. It provides the governance capabilities and interfaces that enable business users to work directly with rules. You can use WebSphere Operational Decision Management without using Decision Center, but doing so means that your business users will not be able to manage and change rules directly in the tool. Both the Decision Center Business Console and the Enterprise Console enable business users to manage rules directly in WebSphere Operational Decision Management.

Decision Center Business Console

This console provides a socially aware, web-based interface that enables business users to author, edit, organize, and search for rules in a collaborative environment. It is meant to coexist with the Enterprise Console, and offers the following features:

Simplified navigation to quickly access the projects and elements you want to work on.

Simplified editing of action rules and decision tables.

A view of what changes have been made to projects that interest you.

The ability to see and post comments on recent changes made by other users, and attach files to these posts.

Simplified search, available from a search box.

The ability to take snapshots of the current state of a project or its state at the time of a previous change.

Decision Center Enterprise Console

This console is more sophisticated than the business one because it provides support for users who are involved in day-to-day management and testing of rules, such as:

Rule Designer is an Eclipse-based integrated development environment (IDE) for developing business rule applications. It is used by a Rules Developer who has Java development experience along with business rule development experience.

The highest level organizational unit within Rule Designer is a Rule Project, which consists of:

An eXecutable Object Model (XOM) that represents the basic data structures upon which rules will be created.

A Business Object Model (BOM) that maps the business vocabulary to the XOM.

Rules that can exist in one of the following forms:

Business Action Language (BAL) rules, which are formatted as IF - THEN statements and are constructed using the vocabulary that is described in the BOM.

Decision Tables, which consist of one or more input columns and one or more action columns. Typically, they are used instead of BAL rules when there are large numbers of rules that are similar in structure and vary based only on the parameters.

Decision Trees, which are rules that have built-in decision branches to deal with more complex decisions than can be easily represented by a decision table.

Ruleflows, which confirm the order in which rules must execute, and can contain branching logic. There must be at least one ruleflow in a project (for example the main ruleflow) because this is the entry point to rule execution.

Event Designer

Event Designer is an Eclipse-based integrated development environment (IDE) for developing situational awareness applications. It is used by an Event Developer who has Java development experience along with complex event processing experience.

The highest level organizational unit within the Event Designer is an Event Project, which consists of:

An Event, which is a message that is to be processed and that can come from many sources, such as a database, a file system, a JMS queue, or a web service.

Event Objects, which describe the data that is associated with the event. The event object is used to populate data inside a business object.

Business Objects, which are temporary objects that are created at the time of an event in order to evaluate whether that event matches any event rules. Business objects can be made persistent, thus enabling rules to correlate events that happen over periods of time.

Event Rules, which are IF - THEN statements that are written in Business Action Language (BAL) based on the vocabulary described in the Business Objects. They enable patterns of events to be matched.

Action, an outgoing message that can be triggered upon the success of an event rule. It can send a message to many different channels, such as a database, a file, a JMS queue, or a web service.

Action Object, which describes the data inside the business objects that are associated with an event.

Usage scenarios

Decision management can be used in the context of other applications or business processes in various ways. The usage patterns in this section show how decision management can be used within the context of business process management.

Business process calling business rules

Business rules are typically called from a process in the same way any external, stateless service would be called: the process sends data to the decision service and receives a synchronous response. Because the decision service is stateless, all the information required by the decision service must be passed from the process. A number of design decisions must be made when using this pattern, such as what degree of processing should be done within the business process and what should be done within the rules. As a general principle, minimizing the number of calls between the business process and the decision service is desirable because it minimizes performance hits. The design should also focus on keeping activities that are primarily process focused, such as human workflow and system interactions, within the business process; and those that are decision focused within the decision service. Figure 5 shows an example of how a business process can interact with the Decision Server at run time.

Figure 5. How rules and business processes interact

Triggering a process based on a business situation

Business events can be used to detect various situations (that is, conditions such as possible fraud or a new opportunity) that require prompt action. It is common for any follow-up action resulting from such a business event to be a process. This pattern is shown in Figure 6.

Figure 6. Common sense-and-respond pattern

Integration

The decision management capabilities of WebSphere Operational Decision Management can be integrated with a number of IBM products, including:

IBM Business Process Manager: Business Process Manager enables an enterprise to choreograph processes and the process steps across disparate applications, people, and systems. As described here, you can integrate business rules and events from WebSphere Operational Decision Management into these choreographed business processes.

Special Notices

This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a client responsibility and depends upon the client's ability to evaluate and integrate them into the client's operational environment.