Marc Kerremans’ presentation on business rules management started out looking at where rules exist in an organization, and how they are used. In many cases, rules are still embedded within applications — such that changing a rule requires changing the underlying code — or are implemented in a manual and sometimes ad hoc manner. Gartner defines business rules as “implicit and explicit business policies that define and describe a business action”, where implicit rules are those embedded within applications.
He discussed how rules can differ greatly within a single organization based on factors such as geography and the associated local regulations, and how a business rules management system — which manages rules explicitly and externally from business applications — can add value in managing all of the complex rules across an organization.
He also looked at who owns and manages business rules:
- Line of business managers determine the most volatile rules that may need to be changed to meet business agility needs, define the rules required, and author/change less complex business rules.
- Systems architects author more complex rules, and test rules to assure that the system is performing as required.
- Business analysts discover and author new rules based on their analysis of the business health, and create and simulate rule scenarios.
Since 2004, BRE and BPM have evolved from distinct and separate markets to an integration of BRE in many BPMS, to the current state of business rules management systems (BRMS) that go beyond simple business rules engine functionality. Typically, a BRMS contains:
- Rule execution engine, including execution, sequencing and chaining of rules, and event-based execution.
- Rule repository, where rules are stored for access by design tools and at run time. This includes security and version control to prevent unauthorized changes to the rule definitions.
- Rule modeling and simulation, for what-if analysis. This will show effects such as dependencies between rules, and performance tracking.
- Monitoring and analysis of historical and real-time rule usage, including reporting and audit trails.
- Rule management and administration, working in concert with the repository, to manage security, promotion between development, test and production environments, and track changes and performance.
- Rule templates to provide a quick start for specific vertical industry rule sets, and horizontal rules sets such as compliance.
- Rule integrated development environment, which provides a graphical, model-driven environment for authoring, testing and debugging rules. This may include wizards for easy creation of rules by business managers/analysts, and collaboration tools.
As with BPMS, not all vendors will cover all of the full range of functionality equally well. There are some open source BREs that provide only the engine functionality, such as JBOSS and NxBRE. Most of the commercial vendors, such as Corticon, Fair Isaac and ILOG, are either migrating to the full BRMS functionality or are already there. There’s also an overlap of BPMS that provide BRE functionality: Pegasystems is the most commonly-cited player here since their BPMS is actually built on a rules platform, but other BPMS vendors provide rules that can be separated from the processes to at least allow reuse across multiple processes, although not across non-BPMS applications.
Agility is the primary reason that organizations look to BRM, which can manifest as awareness (accessing and presenting the right information through rules-based event monitoring), flexibility (rule modeling and simulation to handle expected change), adaptability (rapid rule modification to handle unexpected change) and productivity (executing the right policies and procedures).
There are other reasons for implementing BRM besides agility, of course: improving the quality and consistency of business decisions, improving revenue opportunities by fine-tuning pricing rules on the fly, improving customer satisfaction through greater customization, and better regulatory compliance and governance through the use of audited rules and increased visibility into how decisions are made.
Kerremans went through a number of best practices for getting started with BRM, such as analyzing rule volatility, and establishing a process for making changes to rules. As much as possible, try to work with natural language representations of rules so that business managers are comfortable with the authoring environment, although some level of structure to the language (“rules speak”) will be necessary.
He also discussed the different types of rules technology, including inference-based and event-based rules engines, before finishing up with some recommendations on developing a business rules management strategy. As with BPMS, many larger organizations will end up with multiple BRE tools to cover their entire strategy, so don’t assume that you’ll be working with only a single vendor in this space.
For you business rules aficionados, note that I’ve change the business rules category on this blog to BRM, instead of BRE.