Decision automation
The ability of an operational system to handle change relates directly to the decisions that are applied by the system. Every transaction, order, customer interaction, or process depends on decisions, which are defined by external and internal conditions and requirements. Change affects the decisions that are automatically applied by business systems.
Extracting decisions from your application code
Business policies define the decisions that are used in various operations. For example, decisions determine prices for insurance and loans, eligibility for health services, and product recommendations for online purchases. Typically, business policies are coded in applications as if-then statements, but they can also be elsewhere in procedural manuals or other documents.
Operational Decision Manager uses business rules to represent business policies. The following example is a typical business policy:
A customer who spends a lot of money in a single transaction must be upgraded.
Capturing this policy as a business rule is a two-step process:
- Formalize the vocabulary that expresses the policy as a conceptual object model.
- Represent the logic of the business policy as if-then statements.
After the vocabulary is created, the policy can be written as a 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 or security aspect, you can combine business rule management with capabilities for handling such an aspect. For example, rules can apply the following policies:
- Customers who spend a lot of money must be routed to a preferential service.
- Customers who spend a lot of money require more security for their transactions.
Expressed in business rules, a business policy is packaged as a decision service that can be called by a client application. Several applications can use the same decision service, and because the decision service is external to the applications, future changes to the policy can be reflected in the business rules without changing client application or process code.
Managing decisions
Because decision management is separate from application code, business experts can define and manage the business logic. Decision management reduces the amount of time and effort that is needed to update the business logic in production systems, and increases the ability of an organization to respond quickly to changes in a business environment.
Operational Decision Manager provides complete components for designing, developing, and deploying decision services. The IT cycle consists of developing and maintaining this infrastructure. After the infrastructure is set up, distributed business teams can start collaborating through a web-based environment to create and maintain the decision logic.
Decision Server provides the development and runtime components to automate the response of highly variable decisions that are based on the specific context of a process, transaction, or interaction.
Putting decision management in the hands of business users
With Decision Center, business users can manage decisions that are directly based on organizational knowledge, with limited dependence on the IT department. Business users get various degrees of access, which can range from review only to complete control over the specification, creation, testing, and deployment of the business logic. Business and IT functions can work in collaboration. The entire organization can align in the implementation of automated decisions. The maintenance lifecycle accelerates based on new external and internal requirements.
The lifecycles of decision service development and management can evolve in parallel. Decisions can evolve as needed by the business context, without putting an extra load on the development of the business rule application. Each time the business rule application evolves, the decision management environment synchronizes with the development environment.
With this separation, decisions and application architecture can be managed asynchronously. For example, developers can develop a new version of a decision service in response to changing application infrastructure and core business requirements. At the same time, policy managers can work on new decisions that are delivered in response to an evolving market or a changing regulatory environment.
Operational Decision Manager components for decision management
The following diagram shows the components that Operational Decision Manager provides for decision service development, rule management and authoring, and the execution environment.
In addition to working on different timelines, developers and business users must have tools that reflect their different skill sets and views of the application. For example, developers are accustomed to the Java™ world. They use source-code management systems to work simultaneously on separate copies of a project without interfering with each other.
Business users do not work on the details of application development, but they are interested in testing and managing decisions. They need tools to author, organize, and search for rules in the context of the overall policy.
With developers and business users working in their own environments at their own pace, the work of these two groups must be synchronized and merged.
Finally, both developers and business users require access to an execution environment to test, validate, and roll out to production rules for new and changed business logic.