Operational Decision Manager combines decision making and change detection tools to provide a business rule management system that is easy to evolve, trace, audit, and test.
Operational Decision Manager includes two main components, both components are available on distributed and z/OS® platforms:
- Decision Server for managing decisions and detecting events
Decision Server provides the runtime and development components to automate the response of highly variable decisions based on the specific context of a process, transaction, or interaction. You can monitor a business network to discover and take action on event-based data patterns, and then process this information against hundreds or even thousands of business rules in order to determine how to respond within front-end and back-end systems.
- Decision Center for putting decision management in the hands of those who drive the business
With Decision Center, business users can manage decisions and events directly based on organizational knowledge and best practices, with limited dependence on the IT department. The degree of dependence can range from a limited review by business users of the business logic implemented by developers, to complete control over the specification, creation, testing, and deployment of the business logic by business users. Business and IT functions can work in collaboration, aligning the entire organization in the implementation of automated decisions and accelerating the maintenance lifecycle as they evolve based on new external and internal requirements.
The following figure shows the components that Operational Decision Manager provides for rule application development, rule management and authoring, and the execution environment on both distributed platforms and z/OS.
From business policy to business rules
Business policies are statements that are used to make decisions such as pricing for insurance or loan underwriting, eligibility approvals for social or health services, or product recommendations for online purchases. Business policies are typically found inside application code, in the form of if-then statements, although they may also be stored elsewhere for documentation purposes, such as in procedural manuals and other documents.
A business policy can be expressed as several business rules. Here is an example of the kind of business policy that might be familiar:
Customers who spend a lot of money in a single transaction need an upgrade.
The process of capturing rules consists of formalizing the vocabulary required to express the policy as a conceptual object model and representing the logic of the business policy as if-then statements.
After the vocabulary has been created, the above business policy can be implemented with the following business rule:
if
the customer's category is Gold
and the value of the customer’s shopping cart is more than $1500
then
change the customer's category to Platinum
When a business policy also has an IT policy or security policy embedded in it, you can combine business rule management with additional capabilities to handle the business policy aspects. For example, customers who spend a lot of money should be routed to a preferential service or customers who spend a lot of money require additional security on their transactions.
In the form of business rules, the business logic can be packaged and called from the application code as a business rule application. Therefore, changes to the business policy do not require changes to the application or process code.
From event pattern detection to event rules
An event is an electronic signal indicating that a change in the state of the business has occurred. Orchestrating business events so that the right applications run at the right time for the right purpose is a challenge that can be particularly difficult with the large variety of business systems currently running in the enterprise. A wide range of technologies is also employed, ranging from batch processing applications to client/server, and to browser-based intranet and internet applications. Orchestrating the processing of the events that occur in these systems, as well as the events that occur manually, might potentially mean major system redesign and many months of modifications, tests, and deployment.
A rapid business systems orchestration requires an alternative approach to complex and expensive redesign and redeployment of existing systems is required. The solution is to implement a Business Event Processing layer that sits across existing systems, takes advantage of functions already developed in those systems, and manages the complex interactions (business events) that can occur between those systems. This layer of architecture is known as Business Event Processing. The Business Event Processing layer communicates significant events in one business system to other systems that require the information to respond to the critical event.
In large organizations, tens of millions of events occur everyday, but not all events or event occurrences are of equal importance. Providing insight requires the ability to determine when a pattern of seemingly unrelated events from one or more sources has occurred and then to coordinate the execution of the responses to that pattern of events.
Business Event Processing is the ability to sense when a business event or event pattern has occurred (or not occurred), indicating an actionable business situation, and to coordinate the right response or action, at the right time.
Event rules help detect, and respond to, event patterns among like or related events, missing events and aggregate events. Event rules also relate the pattern detection to a context and apply a dimension of time to the pattern. So, for example, the following logic can be created:
if events A and B occur and event C does not occur in <time frame>, then do actions X, Y and Z after time frame
For example, on a retail web site, if a customer adds a book to a shopping basket (event A) and views the delivery information page (event B) but does not complete the purchase at the online checkout (event C) within one week, then send an E-mail to this customer (action X). After one more day has passed, update the customer favorites database with the book details (action Y), and send a message to the Sales department to tell them this customer did not complete the purchase (action Z).
By using predefined logic that describes how business systems are to interact, the event runtime can notify those systems in real time so that they take the appropriate action.
Why use decision management
Business events and Business Rule Management Systems (BRMS) are highly complementary technologies that in combination enable intelligent and responsive decision automation. These technologies enable organizations to flexibly build solutions that can detect and react to data patterns as they occur within a specified time period, and then provide the appropriate automated decision response to transactional and process-oriented business systems.
The combination of business events and business rules increases business agility and decision automation capabilities to achieve consistently better business outcomes and maximize resources and value. A decision management solution enables businesses to reuse sources of insight:
- Historical data
- Predictive knowledge
- Simulation and events
Operational Decision Manager enables business users to manage decisions and make changes in a very short timeframe, increasing enterprise responsiveness to unforeseen events, as well as shortening response times as a result of higher levels of automation.
Why use decision management in z/OS applications
The extraction of business decisions from COBOL applications and moving them into a decision management system offers several advantages:
- More effective application development and maintenance with less
business risk.
You can apply the benefits of decision management incrementally into your CICS®, IMS™, and batch COBOL applications to reduce the business risk.
- Reduction of duplicated functionality.
Duplicated functionality causes a company to spend more time and more resources than needed maintaining applications.
- Sharing decisions across applications and platforms.
If your enterprise has previous knowledge and investment with Business Rule Management Systems (BRMS) and WebSphere® Business Events it can start application modernization projects to assess how existing business rule and business event applications can address the need to respond more rapidly to emerging opportunities on z/OS.
To manage agile solution delivery, it is essential to be able to understand line of business applications in terms of the business rules they implement and the effect of rule changes on key business processes. Operational Decision Manager provides the framework to develop business applications so that business policy makers can create, update, and maintain the business decisions.