operational (1)

This blog is the part of a multi blogs story published by Aymeric Affouard, Guillaume Arnould, Khadija Souissi and Leif Pedersen. Here are the links to the previous entries:

Part 1: Is there a future for Analytics on IBM Z?

Part 2: IBM Db2 Analytics Accelerator

Part 3: Machine Learning on z/OS

Business Decisions are Everywhere…

Now, let’s start with a little background about where Business Rules Management fits in the overall business environment.

It’s pretty simple: Automated business decisions are everywhere – they can be compliance-related decisions, marketing or sales-related decisions, operational decisions, to name a few …  While each of these examples seems distinct and separate from the others, each is focused on decisions that take place in business systems and which organizations are looking to automate whenever possible.

Another important similarity between each of these is the variability that exists from one customer, transaction or process to the next.  The correct decision can vary based on geography, product, contract, or a number of other conditions.

Finally, in addition to the need to automate business decisions across different functions of the organization, there is unrelenting pressure to evolve – that is, to change the details of those decisions over time. 

These are just a few other examples… How often does an insurance carrier need to update underwriting rules to stay current with its competition?  How frequently does an online retailer’s up-sell/cross-sell tactics change?   Have you ever had exactly the same commission plan 3 years in a row?  The appropriate or correct decision today will not necessarily be the same in the future.

Automating highly variable business decisions, and managing changes to them, are at the heart of the business rule management system value proposition.

Traditional Approach for Managing Decision Change

Decision logic within systems is also referred to as “business rules” – you can think of conditional 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 rules are typically found inside application code, in the form of if-then-else statements, although they may also be stored elsewhere for documentation purposes (such as in procedural manuals and other documents); in other parts of an organization they might be embedded in process models, or even they may even be in the minds of subject matter experts who need to be involved in dealing with specific operational situations.

In order to effectively manage change, organizations need to be able to easily and dynamically adjust business rules; this allows systems to behave with more intelligence, precision and consistency, enabling increased automation of activities, transactions and processes, and customizing actions based on situational context.  Unfortunately, when business rules are embedded within application code, the ability to make changes to it is difficult and costly. 

By having business rules scattered and embedded in all different places, organizations find themselves under pressure to deal with change and the constant evolution of decisions.  There is, however, a better way to deal with business rules…


Redefined Application Change Cycle

By separating the business rule life-cycle from the mainline transaction flow, development lifecycle enables transaction flow-based solutions to gain the same benefits as other rule-based applications. The initial release of the solution would include both transaction flow and business rule components.


As the transaction flow-based solution is in production business policy changes may require changes to the business rules currently executing in the solution. When these policy changes are implemented in changed or new rules, these can be redeployed into production without the need to redeploy the main transaction flow.

Multiple changes to business policies and their rule implementation may occur between major deployments of the parent transaction flow. When a change is made to the main transaction flow that requires a redeployment, the changes to the business rules can be synchronized with the base transaction flow.


What is Decision Management?

First off, decision management is a business discipline. It allows organizations to automate, optimize and govern their repeatable business decisions. The people that care most about decision management are business people. Decision management is an extension of the decisions business people would make if they had unlimited time to make those decisions. Technology is the enabler that makes it possible to capture, change and govern decision logic in a controlled and scalable way. Technology also allows these decisions to be automated and called in real-time by processes, applications, and other business solutions.

9524603865?profile=originalThe key element on this picture is the Decision Service. A Decision Service is an independent, externalized service that can be invoked from anywhere in the enterprise. Supporting Decision Services are two key types of Decision Management, 1) Operational Decision Management and 2) Analytical Decision Management.

Operational Decision Management is based on business rules and events. Operational decisions rely on known business expertise such as corporate policies and external regulations. Operational decisions also rely on enterprise knowledge, otherwise known as corporate best practices (explicit expertise that defines how we run our business) and know-how (implicit knowledge used in running the business that hasn’t been codified).

Analytical Decision Management is based on predictive analytics and optimization.


IBM Operational Decision Manager

IBM ODM provides a wide range of platforms so customers can choose a topology to meet their current needs as well as plan for future growth.

9524604276?profile=originalDecision Center provides an integrated repository and management components for line-of-business subject matter experts to directly participate in the governance of decision logic. Through the capabilities of IBM Decision Center, business and IT functions can work collaboratively, aligning the entire organization in the implementation of automated decisions and accelerating the maintenance life-cycle as they evolve based on new external and internal requirements. The Decision Center can reside on a different platform than the Decision Server. 

Decision Server provides the run-time components to automate decision logic on mainframe systems, enabling the response of precise decisions based on the specific context of an interaction. With IBM Decision Server, data can be processed against hundreds or even thousands of business rules in order to determine how to respond within both front-end and back-end systems. Decision Server on z/OS offers multiple deployment options, allowing the customer to choose the option that is most efficient for the given situation and “fits in” with the current architecture.  The next slide discusses these deployment options.


Business Rules and Predictive Analytics Are Complementary

While most engagements will lead with one or the other, expectation is that customers will need both. Determining where to start is a matter of priority. If you already have one or the other, start there. Always build on what you have today.

Ask yourself what your priority is (automating what you know versus predicting what you don’t)

If you have complex operational requirements that must be met immediately – hundreds or thousands of rules, workflow management – then Operational Decision Management (ODM) may be a better place to start.

If you are able to continue with current operational methods while gradually layering in predictive capability, Analytical Decision Management (ADM) may be a better fit.

If you don’t have enough data for modeling, consider starting with rules as input to a modeling process.

This Blog continues here :

Part 5: Modernizing Applications by using API’s

Read more…