Rule Engine Fundamentals
All rule-based engines are similar in that they allow various roles within an organization to author, save, deploy, and interact with business rules in a centralized manner, while also allowing disparate applications to consume the rules in a managed, service-oriented manner. As such, most rule-based engines provide a rule editor, which lets people author and save business rules; a shared rules repository for persisting and looking up rules; a high-performance rules engine for executing rules in the repository; and administrative tools for deploying, retiring, and migrating rules from one rule repository to another.
How We Got Here
Since the dawn of computing, our predecessors and contemporaries alike have been hard at work chipping away at the same problem: how to break apart the monolith by decoupling as many components as possible without sacrificing performance. Ever since the first computer, the trend has been constant. Computing has moved from sprockets and dials to assembly languages and onto procedural, object-oriented, component-oriented, and service-oriented designs, which further lubricate interaction between constituent parts of a system. Each of these evolutionary technologies has ushered in refined architectures such as two-tier, n-tier, and service-oriented architecture.
|The industry has widely accepted that it's best practice to separate the data layer from the business layers.
The industry, in building scalable systems that are also maintainable, has widely accepted separating the data layer from the business layers as best practice. The user interface and business layers have evolved as well, making the logical separation of user interfaces and business layer physical with the advent of distributed component technologies. Even platform and vendor coupling has proven to be undesirable. Today components can communicate with one another using messaging standards sanctioned by non-proprietary standards bodies such as W3C and Oasis.
With business rules being such a critical part of any application architecture, there are likely great opportunities for decoupling business rules from the main application or process layer. Often, the idea behind decoupling is that the less one component or service knows about the other, the more each component or service is free to change and evolve. The same is true for business rules—and this is the heart of the case for using a rule-based engine.
Why Use a Rule-Based Engine?
A rule-based engine isolates business rules from the application making the rules eminently reusable. Because business rules are (or should be) organizationally universal (as opposed to application specific) rule-based engines can provide unprecedented reuse (another goal of decoupling) of business rules.
|Software product development teams also include stakeholders, line of business managers, business analysts, and quality assurance analysts, to name just a few.|
In addition, business rules that are visible to mere mortals (non-developers) are much better understood, and this transparency introduces higher accountability within teams. In software development, a team is comprised not just of developers and architects; software product development also includes stakeholders, line-of-business managers, business analysts, and quality assurance analysts, to name just a few.
A recent report in CIO Magazine found that up to 70 percent of CIO budgets are spent on maintenance. Even conservatively, if you assume that half the maintenance costs are attributable to business rules maintenance, it is likely that upward of 35 percent of IT budgets gets spent managing business rules. A recent report by IDC supports these numbers. According to IDC, three-year net ROI for organizations deploying rule-based engines is in excess of 100 percent through 25-80 percent reductions in development costs. The report goes on to cite increases in profitability and decision-making outcome of up to 50 percent.
|According to IDC, three-year net ROI for organizations deploying rule-based engines is in excess of 100 percent through 25-80 percent reductions in development costs.|
The reason for the increase in productivity and ROI is simple. Separating business rules from programming code allows non-programmers to maintain business logic without writing code. Even for the most talented developers, writing code is expensive and error prone (if you have any doubts about this assertion, please see Test-Driven Development). The ability for interdependent team roles to have a hand in business rule management naturally reduces the time, risk, and effort inherent to programming changes to business rules in a vacuum. Shared business rule management leads to reduced development schedules and lower maintenance costs.
In addition, extracting business rules and making them available to the wider team promotes visibility and understanding of business policies and procedures, which serves to promote consistent decision making, which in turn leads to increased profitability. Fair Isaac, a leading rule-based engine vendor, corroborates these assertions, reporting that in interviewing hundreds of customers throughout the world, “a 25 percent compression of development time is quite common, along with cost savings for developing new applications of up to 80 percent and maintenance of applications of up to 75 percent."
Another great benefit to isolating business rules is that it makes them eminently testable. This is a core value that any Test-Driven Developer holds dear. You can think of a business rules engine as a way to provide a different kind of dependency injection to your applications.