Business agility in IBM WODM

Business agility depends on responsive, intelligent decision automation. Operational Decision Manager helps manage decisions separately from business applications, and with more flexibility and responsiveness to the changing needs of the business.

The ability to deal with change in operational systems is directly related to the decisions that they are able to make. Every transaction, order, customer interaction, or process depends on decisions, which are in turn dependent on particular internal or external requirements and contexts. Every change therefore affects decisions, many of which are handled automatically within business systems.

Extracting decisions from your application code

Business policies are statements that are used to make decisions. These decisions can determine pricing for insurance or loan underwriting, eligibility approval 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. However, they can 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 happens in two steps. The first step consists in formalizing the vocabulary that is required to express the policy as a conceptual object model. The second step consists in representing the logic of the business policy as if-then statements.

After the vocabulary is created, the 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

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 decision service. Therefore, changes to the business policy do not require changes to the application or process code.



Managing decisions

When 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 required to update the business logic in production systems, and increases the ability of an organization to respond to changes in the business environment.

Operational Decision Manager provides an environment for designing, developing, and deploying business applications that are based on 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 runtime and development components to automate the response of highly variable decisions that are based on the specific context of a process, transaction, or interaction.







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 happens in two steps. The first step consists in formalizing the vocabulary that is required to express the policy as a conceptual object model. The second step consists in representing the logic of the business policy as if-then statements.

After the vocabulary is created, the 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 that is embedded in it, you can combine business rule management with capabilities to handle the business policy aspects. For example, the following business policies can be handled as rulescustomers 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 decision service. Therefore, changes to the business policy do not require changes to the application or process code.



Managing decisions

When 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 required to update the business logic in production systems, and increases the ability of an organization to respond to changes in the business environment.

Operational Decision Manager provides an environment for designing, developing, and deploying business applications that are based on 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 runtime and development 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 have a varying degree of dependence, which can range from a limited review 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 required 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, application developers can develop a new application version 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, changing regulatory environment, or new patterns of events.



Operational Decision Manager components for decision management



The following figure shows the components that Operational Decision Manager provides for rule application development, rule management and authoring, and the execution environment.




In addition to working on different timelines, developers and business users also expect to work with different tools, reflecting 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 concern themselves with the details of application development, but are interested in testing and managing decisions. Therefore, they need tools that can help them author, organize, and search for rules in the context of the overall policy.

With developers and business users that work 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 a rule execution environment to deploy rules to enable testing, validation, and rollout to production of new and changed business logic.