Making Decisions a Central Part of a SOA
If we accept the premise that improving the management of decision logic in applications is a key factor to enabling business agility, then decisions need to be handled in ways that allow for the SOA principles of modularity, reusability, and ease of integration. Traditionally, decisions within applications are defined as rules that are hard-coded directly in the application - rules are defined as "if-then-else" conditions, and these can become very long and difficult to define for complex decisions. Also, as decisions change over time, the embedded rules must be located in the code and modified. It is easy to see how this approach impedes business agility, especially as the frequency of change increases.

At this point, let's introduce a different way of dealing with decisions. Business Rules Management Systems (BRMS) allow decision logic to be separated from application code so that decisions can be managed and maintained more easily and multiple methods of defining complex decision logic will be allowed. BRMS allows decision logic to be defined and understood in three ways:

• The set of underlying conditions (expressed as if-then-else, decision tables, decision trees, or scorecards)
• The associated decision metadata (input/output parameters, rule service packaging, effective/expiration dates, etc.)
• The organizational hierarchy of where a decision is used and its interrelationship with other decisions (aka rule flow)

In this way, decisions can be managed as information assets, allowing them to be understood in the context of the overall business objectives, not just as isolated conditional code.

BRMS is essential to SOA because it enables business agility and provides demonstrable value to IT modernization initiatives. Business policy is separated from core application code so that it can be easily understood in terms of its context and usage and it can be easily changed and deployed as needed, so that rules can be shared and reused in and across applications.

Let's take the example of an insurance carrier. Underwriting insurance policies is typically handled by multiple systems that manage various types of policies, such as auto, home, commercial, and others. But in these systems, there may be common rules for handling corporate procedures, governmental regulations, fraud analysis, and more. At the same time, each business unit has unique rules such as eligibility restrictions, pricing, etc.

By using BRMS, the decisions that define how policy submissions are evaluated and approved can be defined and stored in a rules repository containing both the instructions and context of the rules. Individual rules or associated sets of rules can be packaged as services (known as transparent decision services or TDS), which are invoked by the underwriting system at specified points. The underwriting system passes the TDS a set of input parameters that are then processed against the rules in runtime through a rule execution server. The output of the TDS execution is sent back to the underwriting system so it can proceed to the appropriate next action, event, or process activity.

Now, let's consider that a governmental regulation is added in one of the localities where this insurance carrier operates. By running a simple set of queries, any affected rules can be identified and updated, and the associated services can also be identified, tested, and redeployed if needed (e.g., if a new input parameter is required). If the rule requires a change to take place on a certain date then this condition can be easily defined as part of the rule metadata and the same TDS can be used both before and after the effective date.

A New Model for Business and IT Collaboration
Today, companies across many industries have successfully enabled actuaries, product marketers, and other business groups to manage decision logic with minimal IT involvement using BRMS. How did they do it? What can we learn from their experience?

At the heart of successful BRMS projects is a set of work and communication practices that defines a new form of collaboration between business and IT. This collaboration relies on three key infrastructure components: a shared language between business and IT, a set of tools for modeling and communicating decision logic, and a governance process that ensures safe collaboration.

Building a Common Language Between Business and IT
The ability for business and IT to communicate clearly with each other on how business decisions should be automated in operational systems is paramount to improving agility. Over the years, decision logic has been overlooked as a business asset and, as a result, it has been underserved from a technology perspective. Too often, the language of decisions is COBOL, C++, or Java code. As companies grow into new regions, diversify their channels or launch new products, the code has evolved to follow new regulations, tax laws, or price adjustments. Eventually, this code becomes so complex that the business rules are hard to find and comprehend, making changes slow and error prone. More important, the participation of business users is nearly impossible.

With BRMS, the logic of a decision service is modeled and maintained using a combination of structured English-like statements and high-level modeling abstractions based on a vocabulary that the business can understand. The structure of a pricing policy is most effectively expressed and communicated as a decision table rather than as nested "if-then" Java statements. The complexity of risk scoring decisions is best understood as a set of scorecards. Once defined, those artifacts can then be automatically parsed and executed by a runtime engine. Now business stakeholders can interact and contribute to the definition, modeling or validation of application logic. Changes can be turned around quickly. Risk of misinterpreting the company policies and strategies is greatly reduced.

The Right Tool for Each Stakeholder
Each stakeholder involved in maintaining business rules needs tools that correspond to their skill level and the context in which they perform this maintenance task. Too often, subject matter experts are expected to interact and model their knowledge-using tools, which are primarily designed with IT users in mind. For business stakeholders to be involved in maintaining business rules, their management environment must be more focused than traditional development tools. They also need to provide a safe environment for experimentation and anticipation of the impact of a business rule change. For instance, providing a set of common business rules templates, which restrict the scope of behavior changes to common business contexts, is a safe and easy way for business users to introduce new logic into a decision service. In addition, templates enable QA to rapidly generate new test cases for any given rule changes. Typical rule authoring tools in BRMS are based on a set of Web-based graphical editors or, even better, based on Microsoft Office.

Conversely, developers, QA, and system administrators need to understand the effect of decision logic changes on the service and its service-level agreements. In particular, IT needs the proper tools to understand and manage dependencies with the underlying data models, the testing and deployment processes, and the monitoring of the service performance. One of the keys to ensuring proper integration of a business-lead decision management process into the software application maintenance process is for the IT tools to be based on standard development environments (e.g., Eclipse and MS Visual Studio) and administration tools.

The level of involvement of business experts in the maintenance of decision logic depends, of course, on many factors, such as the frequency of changes, expected turnaround time, and engagement procedures between IT and business groups. While some organizations give business experts a read-only access to decision logic for review and validation, others have successfully transitioned the full ownership of business rule lifecycles to the business. Simple but efficient rule governance principles can help turn that vision into reality.