A Case for Business Consumers of Information Technology
To the business consumer of information systems, the relationship with the IT personnel who build and maintain those systems can be a paradoxical experience: on the one hand, a partnership with IT delivers significant productivity benefits by automating routine tasks and improving access to information. On the other, the process of building automated systems often requires freezing business policies into software systems, limiting the business sponsor’s flexibility to adapt their operations to dynamic market conditions, individual customer demands, or changing regulatory environments. This article analyses the inherent disparity between business and IT and how implementation of business rule management systems can bridge the gap between the two.
Introduction
The relationship between business and IT has often been fraught with misunderstanding, frustration and even hostility. Part of this disconnect between the IT organisation and business groups is a natural disparity between the work cycles of the two groups.
To the business, the IT system development cycle appears to be a long, drawn-out process. Further, once the policy managers approve the requirements, it is often a leap of faith that the implementation is faithful to those requirements. It is not easy for policy managers to follow their requirements through the implementation process once they are translated into technical forms. In the implementers’ defense, what they receive as requirements is often not sufficiently detailed and precise; many requirements are “refined” in the development process, at best with the concurrence of the business people; at worst, at the discretion of individual programmers.
More importantly, though, once the translation is accomplished, the process for changing a business policy requires going through the same complex consultation and translation process for the changes. Thus, the policy changes become entangled with a software development cycle that is driven by a host of technology and resource issues, and is thus insufficiently responsive to the business sponsors’ needs. In effect, the owners of the business policy lose control over its expression and evolution when it is handed off to be embedded in a software solution, and never regain control.
However, business rule management systems (BRMS) enable a giant leap forward in bridging the gap between business people and IT. Using BRMS, the business people define their business policies and business rules and provide a clear communication between the policy managers defining the requirements and the developers implementing the application system solution.
Business people have control on exactly how their business rules are being executed, and, perhaps more importantly, the system is designed to facilitate change when business rules change. In traditional information systems, the business policies get hard-coded into the application. When changes need to be made, the entire software development life cycle must restart – understand the requirement, design it into the system, make sure it doesn’t adversely impact anything else, implement the change, test it and deploy it. IT rarely wants to go through this process for a single change, so requirements must be bundled into reasonable work efforts, further slowing down the process.
With a BRMS, the business logic, which is the part most likely to require constant changes, is separated out and can be changed without impacting the remainder of the application. An assessment of the impact of the change on other business rules must still be done, but this is much simpler than a full system impact assessment. A single change can be assessed, implemented and tested in a very short timeframe, often hours. You do not have to wait until you have additional changes to make the effort worthwhile.
Once the problem is stated in this way, the solution becomes clear: the expression of business policies and the ability to change them need to be rigorously decoupled from the technology that implements them, allowing:
· Business policy experts to manage and evolve business policies using the methods and vocabulary they are most familiar with
· Technology experts to manage and evolve technology using the methods and vocabulary most suitable to their tasks.
This separation of concerns is what a BRMS does. A BRMS is a suite of tools that policy managers and software engineers use to build systems in which business policies are abstracted out of software code, where they can be directly authored, modified and managed independently of the underlying software system.
Business Policies and Business Rules
Every organisation has people responsible for setting the policies by which they do business. In this context, a policy is a statement of guidelines governing business decisions. An insurer may have an underwriting policy, for example, that says “an ‘underage applicant’ for insurance on high-powered sports cars is not eligible for coverage.”
A policy statement like this is not sufficient to form the basis of an automated decision. Someone has to translate the policy into more specific statements that spell out the details of how the policy is enforced. We call that person a policy manager. In the insurance example, the policy manager is an underwriter.
The specific statements that enforce the policy are business rules. Business rules are translations of the policies into detailed conditions and actions that unambiguously enforce the policy. We start with understanding the business process, business decisions and information included in the specific domain of the business policy. The understanding of the information will lead to the writing of a vocabulary that will be used in writing of the rules. An object model will be developed by software developers and mapped to specific data sources within the software infrastructure, but to the policy manager, the model remains an abstraction that describes their decision-making domain.
The business rules expand upon the policy, by stating the detailed circumstances under which it is applicable and the actions that enforce it. One policy can translate into many business rules.
Even one policy domain, such as personal auto insurance underwriting in our example, can require hundreds or thousands of rules, constantly changing over time, and differing across jurisdictions (or, for other domains, customers, products, regions or any other partition of a policy domain). We call the process by which a company manages changes to policies and their enforcement, the business rule life cycle.
Implementing Rule Changes According to Business Rule Life Cycle
The business rule life cycle can be driven by a variety of non-technology demands. For example:
· Market Dynamics: Successful businesses need to be able to change their policies in response to market changes.
· Regulatory Change: In financial services, insurance, and other highly regulated industries, business rule changes can be demanded by the review cycle of regulatory agencies, or by randomly timed regulatory changes from regulators and courts.
· Customisation and Personalisation: More and more businesses are enabling their applications to behave differently for different classes of customers or for individual customers.
All these drivers require a high degree of flexibility and responsiveness in translating policy into actionable rules. The result is that it can be very difficult to “marry” the resulting business rule life cycles to a traditional software release schedule. A business rule application mitigates this problem, by allowing separate cycles for software development and rule management, each with its own drivers and timing.
Author Rules in Business Language
Separating the business rule life cycle from the application development cycle enables a more timely response to business change. However, to also empower the policy manager to enact these changes directly, a BRMS has to provide another important service: a means of expressing the business rules in a format and language that is familiar to the policy managers, and easily manipulated by them.
There are two elements to meeting this requirement:
· Specification of a business language that can unambiguously express the policy manager’s intent, yet remain familiar and easy to manipulate.
· Translation of this language into something “executable” by the software application.
Business Action Languages
In many cases, these two elements can be met by means of a straightforward mapping between business vocabulary and technical software artifacts.
Software developers typically express their understanding of the information required to run a business in terms of an object model. An object model is a formal means for expressing concepts (like Customer, Order, and Item, for example), their relationships (a Customer can have multiple Orders), their content (a Customer is described by a Name, Address, a Customer Class - either Platinum, Gold, or Silver), and operations that can be performed on them (adding a message to an Order). The software developers will implement the object model to allow programs to manipulate the data. All the terms in the object model can be translated into a vocabulary that the policy managers can use when writing business rules. Combined with a simple if-then syntax (IF some set of conditions are true THEN a certain action should be taken), the policy manager can express business rules in statements that are still in business vocabulary but are precise and can be automated. We call this combination, of the business vocabulary mapped to the object model and the syntax, a business action language.
Sometimes it makes sense to express a rule as an if-then statement, but often it is more useful to express a set of rules that involve the same conditional terms in either a table or tree form. A decision table is defined by the set of conditional terms as column headers with each row representing a single rule and the result of each rule in the final column.
A decision tree also combines a set of business rules into one graphical display, but rather than each rule being a row, each rule is a path through the tree, branching at each conditional term. The density of the tree depends on how many possible values there are for each condition – with a few (e.g. true/false), a tree is a good display choice; with many (e.g. each of 50 US States), a table is often more readable. Both decision tables and decision trees are extremely useful for viewing multiple related rules at once, to ensure that you have addressed all scenarios and that the rules makes business sense as a group.
Manage Rules Throughout Their Life Cycle, from Creation to Retirement
The advantages gained by the ability to quickly identify the rules that need to change due to a change in business policy can translate into a competitive advantage for organisations. It can help simulate the proposed change prior to going into production and then implement all the rule changes in the timeframe, as required by the business. The business rules by which an organisation implements its business policies define how the business operates and are valuable assets thus should be managed accordingly. This means:
· Organising rules in a way that is logical to the policy manager
· Making rules accessible to the policy manager and searchable by relevant criteria
· Versioning rules and maintaining an audit trail
· Analysing rules for consistency, completeness and business efficacy
· Testing the implementation of rules to ensure it is faithful to the business intent
· Simulating rule changes to understand the impact before implementation
Rule Organisation
A typical enterprise has many policy managers who are responsible for thousands of rules. To make this efficient, a BRMS needs to provide simple, transparent capabilities for organising rules. Rule Organisation takes place in a repository that manages all rules for one or more projects. Typically, business rules are grouped by high-level content areas which are then broken down further by tasks or decisions. For example, a property and casualty insurance company might start with lines of business (Fire, Auto, Property, etc.) and then have Rating Rules, Pricing Rules and Claim Processing Rules under each.
Search
To effectively manage policies implemented as large numbers of rules, a BRMS provides the ability to search the rule repository for specific rules, based upon criteria other than organisational structure of the repository. A BRMS enables the assignment of additional metadata properties (built-in or customised to your own needs) such as who authored the rule, when the rule was last modified or the effective date range for the implementation of the rule.
For example, a regulatory compliance officer for the property and casualty company using the physical organisation and metadata mentioned above, could collect and inspect all the rules for Thailand in effect for a given date, across all lines of business and coverage types, by issuing a query for those specific rules.
Versioning and Auditing
One key requirement of policy management is the ability to track individual rules and sets of rules as they change over time, and to verify the state of a rule as of any given transaction. A BRMS facilitates this type of audit, by keeping each version of a rule in the rule repository, and tracking when each version was deployed and active. The versioning system may also track the identity of each individual who changed a rule, as well as require annotation of the changes. In this way, the BRMS creates an automated audit trail for policy changes in the organisation.
Analysis of Rules
Business policies can be quite complex, and the formalisation of the expression of the rules that implement a policy enables more systematic analysis of dependencies, consistency and faithfulness to the business intent. Having rules in a formal syntax, the BRMS can highlight where the result of an action in one rule is used in the condition part of another rule – since the second is dependent on the first, you know changing the first will impact the second. If you have long dependency chains, the ability to highlight the dependencies further down the chain is crucial to understanding the total impact of changes. A BRMS can also identify inconsistencies and redundancies in your rules:
· Whether the rule is self-inconsistent (because it specifies conditions that cannot be true, for example)
· Whether rule conflicts with another rule
· Whether the rule is redundant (because it is equivalent to another rule, for example)
· Whether a set of rules has gaps in the scenarios addressed
Finally, having rules organised and formally expressed enables the policy manager to review sets of rules to ensure they really do result in the appropriate set of actions. A BRMS cannot make this determination for the policy manager, but it can lay out the information in a manageable way.
Testing
Policy managers authoring rules in a BRMS need to have tools that permit them to verify that the rules they write actually work as required. In its simplest form, that calls for a means to answer the question “if I run my rule on these specific values, will it fire and produce the expected results?” This might be called “unit testing” for rules.
It is also necessary to test rules in aggregation, to determine if, collectively, they implement fully and correctly the intended policy. This requires the ability to specify a complete rule set, and a complete set of input data, and again verify that the results are as expected. This can be called “functional test” of rules. Finally, because even with constantly evolving policies, businesses require stability in most of their functions, there needs to be a mechanism for verifying that a proposed new rule set satisfies standing constraints on its functionality. This may require running many complete input data scenarios against a candidate set of rules, and evaluating the aggregate results. This is “regression testing” of rules.
All three testing types are supported by an enterprise BRMS.
Simulation
One utility of a BRMS is that, because policies are given a precise operational form, as rules, a proposed set of policies (set of rules) can be evaluated rigorously to determine if it yields the desired results. One version of that is the regression testing of rules mentioned above, but it is also possible to use a BRMS to do more prospective verification of rules. Suppose, for example, an insurer’s underwriting goal is to accept 80 percent of tendered risks, without exceeding a specified aggregate exposure index. A BRMS “simulation” capability would facilitate this as follows: underwriting managers would craft detailed policies with the intent of meeting this goal, and translate these into a “candidate” rule set. This candidate rule set would then be run against all application received in, say, the last month, with the results of each evaluation being recorded. Finally, key performance indicators, including the percentage of yield, and the aggregate exposure index would be computed on the results, permitting the underwriting manager to discern whether the particular policies written into the rules would have met the overall business goal.
What to Look For in a BRMS
There are some important features a business user should look for in a BRMS:
· Address the needs of business and IT: A BRMS should support tools designed specifically for policy managers that isolate them from the concerns of application developers, and have at the same time, tools that support and simplify the developers’ task of integrating the BRMS into software applications.
· Provide domain-appropriate rule artifacts: As discussed above, there are many ways to express a business rule. A good BRMS should support those that are most natural for a given business, or provide a means to extend and alter its default rule languages to accommodate the business’ specific needs.
· Address the need to manage the entire business rule life cycle: Typically, a successful business rule application will eventually encompass hundreds to perhaps tens of thousands of rules, which will undergo constant modification and extension as policies change. To be fully effective, a BRMS must support the policy manager at every step in the business rule life cycle, in order to make that large collection of rules intelligible, verifiable, and manageable.
Conclusion
Managers responsible for policy in decision-rich enterprises have benefited enormously from information technology. But as the pace of change has increased, and the reach of automation has been extended, traditional software applications have proven their inability to deliver the flexibility and agility these managers require. Applications constructed with BRMS, on the other hand, can deliver that flexibility and agility, and enhance the entire policy management infrastructure of the enterprise at the same time.
Lim Chin-Keng
As a PLSM Director of Borland Software APAC, Chin is responsible for the adoption and deployment of Borland’s enterprise software solutions in the region. Prior to this role, Chin led a team of solution managers and consultants in BEA and helped companies to define and architect distributed application infrastructure to meet their business requirements. Chin is also a technology evangelist and key spokesman for the region. |
