BPM.com

             

Articles

Business Rules Management

If business management creates and maintains the policies that drive competitive advantage, why can't business create and maintain the business logic that represents these policies?

Business change is a fact of life for companies and results from new product initiatives, compliance with new regulations, back-office efficiency needs, or changes in market conditions. New policies and procedures are created to respond to these changes. However, management is not measured on its creation of policy, but rather on its accountability for successful execution.

Companies rely on business applications for this successful execution, and business change often means change to these applications. Business logic within applications is the bridge between policy and execution.

It's often said that a chain is only as strong as its weakest link. In the chain of creating business-driven and flexible software applications to execute business, the weakest links are within the process of the capture, validation, and change of business requirements for business logic. These weak links produce the crippling business mistakes and business errors, such as gaps, ambiguity, conflicts, incompleteness and inefficiency that cause pain throughout an organization.

According to the Standish Group, a market research and advisory firm specializing in strategic software, nearly one-third of IT projects are canceled before completion. Over half the remaining projects are considered 'challenged' and will cost almost double their original estimates with fewer features and functions than originally specified. The firm cites the top-three causes for business errors and mistakes:

1. Incomplete business requirements
2. Changing business requirements
3. Lack of business user involvement.

Business Error Costs
Testing for business errors and mistakes in the late stages of software development, as it is done today, is a poor substitute for preventing errors in the earlier stages of a project life cycle for one reason: Cost (see Figure 1). Software errors cost an estimated $60 billion annually, according to the National Institute of Standards and Technology (NIST), a unit of the U.S. Commerce Department. According to Oracle Corp., the cost of finding and fixing an error in the production phase of application development is often a thousand times more expensive than if it had been prevented during the scoping phase of the project life cycle.

In addition to internal delays with lost productivity and revenue, it's often customers who painfully uncover errors, leaving companies exposed to significant financial or legal liability. Recently, Multidata Systems International Corp., a leading provider of radiation oncology products and systems, discovered it may be facing total damages in the range of $14 million to $28 million for 28 deaths resulting from incorrect gamma ray dosages for their cancer therapy product. This 'business mistake' has been linked to business logic errors within the software that controlled administration of the dosages.

Other examples include:

- Consumer lending: A bank error causes a minor amount overdue discrepancy for a customer, triggering a bank late fee, which after several months is reported to a credit bureau. The result is the customer's credit record becomes damaged. Thousands of dollars per customer are spent reversing what was originally a simple business logic error. A business logic gap allowed this kind of damage. The total cost impact on the financial services sector from an inadequate software-testing infrastructure is estimated to be $3.3 billion.

- Insurance claims: A mistake is made due to a gap in claim adjudication business logic and a worker's compensation claim is paid. The error is detected later, but by law, the insurance company is responsible for the continued payment for the disability for the working life of the employee. As many as 25 percent of all filings may have some element of impropriety. The National Insurance Crime Bureau estimates that workers' compensation fraud alone costs insurers $5 billion each year. This, according to Stanton Long, is billed back to employers in the form of at least $6.5 billion of premium.

- Billing errors: A customer of a telecommunications firm moves their office and has its numbers ported. The provisioning occurs correctly but the bill has the wrong tax jurisdiction, causing the customer an overcharge of $135,000 because of a gap in the tax business logic. The customer disputes the entire bill and holds up millions in cash flow until the error is corrected. According to the Rand Associates, 80 percent of carrier invoices have billing errors. For a firm with 10,000 employees, billing errors alone could add up to as much as $1.5 million in losses per year.

Defining requirements is fraught with problems due to the inflexibility and gaps in the tools currently used by participants in different roles throughout the process. Process mapping tools, such as Microsoft Visio, are helpful for business people, but too conceptual for the results to be useful for IT. Unified Modeling Language (UML) tools, typically used by IT, effectively capture the detail and technology information that IT works with, but are far too complex and specialized for business people to understand. There's no linkage, common language or ability to trace the business motivation and objectives with the detailed final documentation and execution. This makes collaboration on changes time-consuming, frustrating, complex and error-prone.

Benefits of a Rules-Driven Approach
A business rules approach offers a promising solution to these errors, process problems and their costs. According to the Business Rules Group, an independent standards group of business and IT professionals, a business rule is a directive, intended to influence or guide business behavior, in support of a business policy that has been formulated in response to an opportunity, threat, strength or weakness. A business rule is expressed as an English language-like statement that satisfies the needs of both users and IT. Both can easily understand business rules, and IT can easily convert them as needed into executable computer code. A business rule consists of decision criteria for evaluation and a corresponding action to be taken when the decision criteria are satisfied. For example: "If a customer has good credit, then assign a credit rate of 6."

Business rules are also extremely cost-efficient. In his article 'The Living Transaction', Presley Becerra estimates that one rule typically represents the equivalent of 100 lines of source code, which would take a developer two days to develop, using more traditional methods.

A business analyst can easily write 10 business rules per day, meaning that a business-rules approach can help development efforts realize a twenty-fold gain in productivity. Finally, since the business rules engine automatically generates the execution code on demand, the business rules approach provides greater agility to meet changing market conditions.

Despite the compelling benefits of business rules, they can be difficult to maintain. Problems arise when different business rules combine to produce results that weren't anticipated during the modeling phase. The complexity in the chain of dependencies across functions and multiplied by the volume of business logic makes it nearly impossible to spot all the contradictions, loopholes and vulnerabilities that may exist.

A conflict error, for example, occurs when two business rules share the same decision criteria but call for different actions:

- If a customer has good credit, then assign a credit rate of 6.
- If a customer has good credit, then assign a credit rate of 8.

These rules, however syntactically correct, contradict each other; they would cause the arbitrary assignment of a credit rating of 6 to some customers and 8 to others. This intermittent kind of business logic error is extremely difficult to diagnose with even sophisticated testing tools. After the system goes live, it may be months until the error is detected and corrected. During that time, the company may need to cope with unknown losses of customers or unprofitable accounts.

Another type of business logic error is a gap in coverage. Rule coverage is incomplete if the conditions of all the rules in the rule set don't together account for all possibilities. For example, corporations are organized around 'separation of duties' to avoid fraud. Sensitive transactions are decomposed into several smaller steps, which different individuals execute. Perpetrating a fraud would require collusion of several individuals. These steps and the authority of individuals are best represented as business logic. However, how would gaps in coverage within the business logic be found? Many such loopholes aren't found until it's too late. The National Association of Certified Fraud Examiners reports that workplace fraud costs businesses more than $400 billion a year. The average organization loses about 6 percent of its total annual revenue to employee fraud and abuse.

Most rules products typically don't assist in identifying and resolving any potential business rule errors, such as conflicts and gaps that may occur. At best, they show a log file of rules that the engine executed in production. The discovery and diagnosis as to the cause, identity, and resolution of errors is entirely manual today and requires highly skilled and trained personnel, usually with six to 10 years of rules expertise. Even with this formidable expertise, rules specialists typically are hindered by their lack of knowledge in the specific business problem. Ironically, business analysts, who are often regarded as being close to the industry and customers' needs, are nevertheless marginalized due to the age-old barrier of technical expertise required.

Prevent Business Mistakes Across Both Rules and Workflows
Business Process Analysis (BPA) software, with rules management designed specifically for the needs of both business analysts and IT, automatically uncovers and helps resolve errors at the time of modeling, such as conflicts, collisions, gaps, overlaps and redundancy (see Figure 2). Some companies are beginning to offer basic rule management capabilities; however, the future will be with those that extend this capability across the combination of both rules and workflows natively within a single modeling tool. Representing business rules within the context of workflow processes not only provides business analysts with a comprehensive and intuitive view of a business process, but also enables error detection to be propagated across both rule and process interactions. This advanced business logic management encompasses analysis of process elements to identify missing input or output information that's needed for a rule or process to execute as well as rule dependencies on the process elements. Alternatively, advanced business logic management will detect information defined in the process that will never be used, identifying the incompleteness of a model or the potential 'disconnects' between contributors.

The effects of changes can be propagated throughout the business process to indicate upstream and downstream impacts. Business analysts also can visualize the relationships between different process elements by viewing a cross-section of the process organized by the chain of dependencies that exists between the different model elements rather than the logical flow. Global rules provide an opportunity to define formula and sequence-type business rules that apply to all processes in an organization and to help establish corporate policy. Whenever new processes are created and the process is analyzed, the formula and sequence enforcement is applied.

Business analysts can spend less time troubleshooting and more time implementing changes in business rules based on customer feedback, regulatory changes and competitive actions. The exciting thing about business rules is that a business rule engine can generate executable code automatically to create a working application. This means that models validated with rules management are free from the distortion of business and technical errors and can now be used to run different business scenarios to document a business case.

Managing Rules: Reusable Rules, Updates and Versioning
Many business rules in current systems are duplicates, resulting from copies of sections of programs or rule sets being made over time; for example, to address variations on existing products. Rules analysis also detects individual rule errors contained in different rule sets throughout a business process. This enables new techniques for further reducing complexity so analysts can focus on business solutions. Just as a complex mathematical equation can be factored into its basic prime elements, rules can be organized into reusable rule sets. The rule management system can then validate the interactions between these reusable rule sets.

Having all business rules in one place provides a comprehensive view of a business process and further leverages the power of rule management. A true business logic management repository should provide a centralized storage of a full range of business logic regardless of the execution environment. Version control, access control and other features track changes and updates, manage the deployment of processes and foster collaborative efforts. The repository should have the ability to translate and distribute rules to other environments for execution and avoid the maintenance costs associated with duplication of business rules in parallel locations, such as the same data validation rule used in Web, telephone and e-mail interfaces.

Managing Rules
With the elements of analysis, organization and visualization, the skill level required to use these new innovative tools is now similar to that of an Excel spreadsheet. In fact, the rule-writing interface has the familiarity of an Excel spreadsheet to provide a business analyst the ease of use of that product.

Other key characteristics of a solution with rules management include:

- Ability to tie the business purpose of a rule set to the individual rules that combine to achieve these goals

- Governance of business rules to assign stakeholders, stewards, governing party and reviewers, so that a committee can be organized to manage the change process

- Ability to trace rules to document the linkage of the source, status, confidence and forms of the business rule to facilitate committee review and approval

- Support for manual activities to capture exception-handling as part of a process improvement feedback loop.

Looking Ahead
Returning to the question, if management creates and maintains the policies in an organization, why can't business create and maintain the business logic that represents these policies? In the '70s and '80s, computers, word processors and scheduling software enabled managers to type their own memos and manage their own appointment calendars. This reduced costs, improved efficiency and shortened business cycle time. In fact, the composition of the workforce has restructured to provide more meaningful, productive jobs. A similar transformation is in process today to enable businesses to manage the creation and maintenance of business logic that drives applications. A new flexible infrastructure technology, business rules-driven Business Process Management (BPM), is poised to have the same enabling impact on corporate America's infrastructure and workforce.

 

 
About The Author: Steve Minsky

 

Steve Minsky
Steven Minsky founded RulesPower in May 2001 and has 17 years of rules, workflow, and integration technology experience. Previously, he worked for Kodak Eastman Software and Apple Computer. He earned a master's degree from the Wharton School of Business, an M.A. in International Studies from the Lauder Institute at the University of Pennsylvania, and a bachelor's degree in Engineering from Tufts University.

 

 

BPMN 2.0 Handbook

Co-authored by BPM.com's Nathaniel Palmer, and with a forward by Dr. Bruce Silver, the BPMN 2.0 Handbook offers both the business and technical perspectives written by the standard's authors, leading implementors, and most respected experts; The 47-page excerpt contains the complete Forward, Introduction, BPMN Glossary, and Making a BPMN 2.0 Model Executable; authored by Nathaniel Palmer and Lloyd Dugan. Free to registered BPM.com members.
Click Here to Download