As business rules direct how an organization engages with the market, the ability to change focus as market forces dictate is of paramount importance to any company wishing to remain successful. Organizations are therefore seeking architectures for their enterprise systems capable of supporting an adaptive business model in which business rules are truly dynamic.
Unfortunately, traditional systems suffer a number of limitations when it comes to supporting dynamic business rules:
It is worth considering each of these points in further detail.
Business rules are a dynamic attribute of any enterprise system, yet traditional development methods hardcode business logic using general-purpose, third-generation languages, of which Java is an example.
This approach fails to meet the adaptive model businesses are demanding, because hard-coded rules are immutable, and changes can be effected only by rebuilding all or part of the system. Defining rules in this way does not reflect the dynamic nature of the rules themselves. Moreover, the use of a language like Java requires the services of a software engineer to apply all of the necessary changes. Potentially, the business expert could make such changes.
Rule Definition Languages
Although the if ... then ... structure of the business rule at first appears well suited to languages such as Java, this is unfortunately not the case. Java necessitates the services of skilled software engineers for implementing and changing business logic. Such changes are arguably best applied by those most skilled in the logic being defined: the domain experts. It can therefore be argued that business rules should be defined using a specialized natural-language syntax that enables business experts, as opposed to software experts, to build and maintain the rules.
Addressing the language issue from a different tangent, Java, as we know, is an object-oriented language. However, languages from a very different paradigm exist that are constructed specifically for the implementation of rule-based systems. These languages employ a declarative paradigm, as opposed to an imperative one, and originate from research projects into artificial intelligence (AI)based systems. In upcoming sections, we look at the application of these specialized languages for the definition of business logic.
Tight Coupling of System and Business Logic
In traditional systems, the software that enables the application to operate and the software responsible for implementing the business logic become intertwined. This scenario further exacerbates the difficulties inherent in enabling domain experts to maintain the all-important business logic. The business expert must understand the operation of the entire application in order to accurately separate business functionality from application functionality.
The reverse is also true of the software engineer, who is required to be expert not only in the architecture of the system but also in the business domain itself. An architecture that supports the clean separation of the two concerns of business and system would enable the responsibilities for the development and maintenance of the system to be divided between the business and the software experts.
A company may find that as part of its wider IT portfolio, business rules are repeated several times in numerous different systems. This situation is not uncommon in large organizations and often occurs where systems overlap in terms of functionality. This situation can also arise during the transition phase as new systems are introduced to replace legacy systems.
Rule duplication significantly increases the total cost of ownership for an organization and adversely affects its propensity for agility. Changes to business processes must be effected across several different systems, thus incurring additional expense in terms of cost and time.
To address these issues with defining business rules, software vendors are turning to rule engines, a technology that was previously the preserve of academia and the computer scientist.