The widespread implementation of service-oriented architectures has shown that we have moved past the early adoption phase. The name of the game is to create a set of modular software applications that can work together and allow each component of the system to focus on what it does best. While the decentralized SOA application environment provides a great deal of flexibility, it also creates a new set of challenges. How can organizations effectively manage the consistency of business decisions delivered through various applications? And how can organizations reliably implement changes to business decision logic across all their services?
A BRMS gives you a highly effective and efficient mechanism for managing decision logic and acting as a conductor in order to align decision behavior. The key to a BRMS is the use of a centralized rules repository, within which resides the decision logic that applications use. Not only does a BRMS fit within a service-oriented architecture, it can act both as an intermediary between applications and as the decision management component for application behavior implemented as a set of services. A BRMS define business decision logic as rules stored in the rule repository. Individual rules are then combined into rulesets, functional blocks defining decision logic for a subtask. Rulesets can be combined in a procedural decision flow or ruleflow to conditionally use the assigned rulesets in a sequence that achieves a desired business decision. This combination of ruleflows, rulesets and individual rules are utilized within rule-based services (rule service) that are used to guide the decision logic for a specific business process. Rule services can be combined and are made executable within a decision service. Decision services use the BRMS rule engine to process the inputs from operational system applications through rule services, as well as processing data (from separate data sources) and analytic models (embedded within rule services) as required in order to return the optimal decision output back to the client application. These services can be orchestrated using something like Oracle's BPEL tool (which has a defined interface for "Decision Services")
The differentiation between individual rules, rulesets, ruleflows and rule services provides the highest level of flexibility in the reuse and sharing of decision logic across multiple services. As the functionality across each service is different, so too is each service’s use of rules. Several services may require a common rule or ruleset, but each may have its own unique set of related rules or decision processes that need to be associated with that specific rule. Allowing this reuse of rules across services can speed their development and reduce the cost of maintenance above and beyond the improvements that come from a services-based orientation.
The services you need to deliver on the vision of SOA need to be dynamic, configurable, platform-independent and easy to evolve as business needs change—the “guts” of a service can be easily evolved without changing its interfaces and, thus, the interactions of other services with it. Business rules are ideally suited as a way to build these highly configurable services. Additionally business rules offer a way to manage the complexity of assembling these services into applications or processes. This allows changes in how the business operates to be quickly implemented using business rules, resulting in new or changed combinations of services without the need to edit low-level code.
The use of a business rules management system within a service-oriented architecture provides clear benefits through the separation of decision logic from application functionality. Using a BRMS ensures that disparate applications behave consistently, are able to automate complex decisions and quickly adapt to changing business requirements. Business rules management systems also offer organizations the ability to incrementally transition from legacy systems to a service-oriented architecture. In particular, those organizations with large numbers of rules, rules that change often or very complex rules will benefit, as will those that must demonstrate compliance with complex or extensive regulations.
There are some answers to FAQs on my other blog.