Back to Contents of Issue: August 2003
|
|
by Lance Webb |
|
NOT SO LONG AGO, when multi-tier computing architectures were first gaining momentum, the standard design consisted of three tiers: a client, an application server that ran the business logic and a database server. But many years after the three-tier model was adopted, extensive business logic was still frequently placed on both the clients and the databases.
In the late 90s, the role of this middle tier underwent important changes due to the incursion of the Web: application servers emerged as the central platform, to which clients and databases provided specific interaction and support. This new model -- currently favored by many enterprises -- required a clearer concept of business logic.
An emerging and workable definition breaks business logic into two fundamental types of computing: the application of business rules and the execution of data processing. The latter consists of the typical process of preparing transactions, analyzing data and generating reports. Business rules, however, are fast becoming a specific solution domain with important characteristics. Not least of these is that by encapsulating business logic in rules, a clean separation between the data, logic and presentation layers is possible.
Business Rules in Computing
Industries reliant on rule processing include credit card companies, mortgage bankers, insurance companies, hotels and travel agencies, transportation industries and financial services. In addition, industries that rely on event management, such as telecommunications and supply-chain management, also use rule processing to identify exceptions.
Rules, as commonly implemented in IT settings, are nothing special to look at. They frequently take the form of a series of if/then/else statements strung together with and/or logic. Although conceptually simple, a large number of rules can become unwieldy very quickly. The main reason for this is that business rules can factor a virtually unlimited and surprisingly complex number of possibilities.
Rule Engines Ride to the Rescue
By facilitating the articulation of business rules, BREs moved the formulation of new rules out of the domain of specialists --and even out of the hands of IT and programmers -- to the business itself and specifically to business analysts.
This migration from IT has been further facilitated by the design of some Business Rules Management Systems (BRMSs), such as ILOG's JRules, that enable analysts to formulate their own vernacular by which they can articulate the rules in familiar terms. To help analysts do this, these BRMSs feature capabilities such as built-in tools for managing rules and their metadata, rule-versioning management (which is a necessity for installations with large numbers of frequently changed rules to manage) and security features.
By pushing the technology onto the desktop of business analysts, BRMSs help software developers enjoy a tremendous boost in productivity. BRMSs also offer other benefits. BRMSs make it easy to see which rules are executed for which conditions. This gives a complete audit trail for tracking how the solution is making decisions.
What to Look for in a BRMS
For more information about ILOG visit:
|
Note: The function "email this page" is currently not supported for this page.