Occasionally, after delivering a design proposal for the use of Business Rule Management System (BRMS, or ‘rule engine’) in relation to a specific business problem, we’re asked:

“We like the idea of using business rules for this, but is the use of a commercial BRMS really warranted? Our rules are really simple. Couldn’t we make do with a home grown product, perhaps based on a database or spreadsheet?”

This is a fair question and it deserves a considered answer.

In this article I discuss the value proposition of BRMS, the pitfalls of clients attempting to develop their own tools to fulfil this function and how this approach can, in the long term, be more expensive than buying a commercial product.

Introduction

When we present design solutions involving commercial BRMS components, a few of our clients initially express the views:

• that their rules are really simple and can be represented by a few tables (say in an Excel sheet, or a database);
• they have no appetite for the advanced features offered by BRMS, for example RETE based inference;
• their rules could be maintained and ‘executed’ a simple bespoke system; and
• that this would be a ‘simpler’ and much cheaper solution.

This is usually a well-meaning proposal, usually driven by the concern that the license fees of a commercial BRMS will be excessive, that selecting such a tool will lock them into a specific vendor or that BRMSs are overkill for the problem at hand (typically that BRMS provide too many superfluous features). The clients accept (all or most of) the value proposition of business rules, but either do not accept the value proposition of BRMS, or feel that a bespoke solution can deliver them more efficiently.

As an aside, if the cost of BRMS is an issue for you, consider the approaches outlined here.

Value Proposition of Business Rules

The value of the business rules approach is based on:

• Visibility: the ability to extract business logic (the semantics of critical business decisions or constraints) from an IT system and express it as a separate artifact, in plain business English, that can be understood by the business SMEs (and even external regulators) with no help from IT; and through this…
• Control: the ability for SMEs to review, or even modify, test and release business logic in this form – thereby cutting out the error prone indirection through IT; and through this…
• Agility: the ability to turn around changes very quickly because a full software release cycle is not required for many types of changes.

In short, Business Rules empower the business SMEs to understand their business logic directly (by expressing it directly in business form, rather than burying it in technical source code). They also help SMEs to evolve the business logic of their systems more quickly – essential given the pace of change in business today. Business Rules assume, facilitate and manage change.

There is a lesser application of rules, technical rules, in which only technical staff (IT) see and maintain them. We refer to this as ‘lesser’ because it is little more than system configuration using a domain specific language and misses much of the return on investment of business rules. Only the latter provides a equal partnership between IT and business SMEs in managing change.

We don’t address the value proposition of technical or business rules further here as it is not the focus of this article. Please look here for more details.

Value Proposition of Business Rule Management Systems (BRMS)

The BRMS provides a context for business rules to be developed and to be executed. Some people also refer to them as ‘rules engines’, but this is misleading as BRMS do a great deal more than execute rules. In addition to the above, the value of the BRMS is:

• Expressive Power and Flexibility: the ability to support and administer powerful business rule abstractions such as a variety of rule types (e.g., English language, decision tables, decisions trees), varied condition and action clauses, powerful business vocabularies and domain specific languages (DSLs) and rule reuse, chaining, sequence, inference and inheritance – with the goal of making rule sets as small and as fit for purpose as possible, thereby reducing the cost of maintenance;
• Consolidation: supporting the concept of a single rule repository in which (a potentially large number of) rules can be amassed and managed, adding such concepts as rule metadata, format templates, reports and queries, validation on rule entry, preservation of mutual rule integrity, duplicate rule checks, run time and build time traceability – the goal here is to maximise the quality, integrity and consistency of larger rule sets;
• Governance: controlling access to rules by the definition of a varied user community with different privileges and permitting the rule lifecycle process to be audited and controlled to enforce accountability for change and 4-eye review. This is essential for enterprise adoption of rules and rule changes at any scale.
• Architectural Integration: allowing the deployment of rules into a wide variety of target architectures.
• Traceability: allowing the application of all rules to be captured so that behaviour and the (rule) rationale for said behaviour can always be justified after the fact.

The BRMS, as an execution environment for rules, does support inference (including the famous RETE algorithm). This is a means of combining rules effectively by promoting a declarative (rather than an imperative) definition of rule sequence and allowing the sequence to be determined dynamically as rules fire. This is useful in certain problem domains, but it is not the major reason for using a BRMS.

As the name implies, BRMS provide management of business rules through consolidation and governance (see above). It is a means of managing the complexity of rapidly changing, large rule sets that are collaboratively developed across teams.

BRMS show their value when:

• the product of the number of rules and the number of collaborating rule authors exceeds 200 and
• the number of change events exceeds 3 per week.

Managing without a BRMS

Can you adopt a business rules approach without a means of managing rules? In our view: No. Unless you have a trivial number of rules and they change very infrequently, or you allow only IT to access rules and maintain them like code (the technical rules scenario outlined earlier), you will quickly drown in a confusing morass of email change notifications, duplicate rules and production incident reports. It would be analogous to trying to develop complex software without version control and automated build facilities.

Can you adopt a business rules approach without a BRMS? In our view: Yes. But you need to have some software to manage the rules and without a commercial BRMS, you need to develop this yourself. Note that we classify open source BRMSs as ‘commercial’ because, although they are more cost effective than the market leaders, their enterprise deployment still entails support costs.

Building Your Own Business Rule Management System

If your requirements are simple, as in the example at the beginning of our article, it may be tempting to consider developing your own rules management system based on database, spreadsheet or some other technology. After all, few projects could be simpler than representing simple business rules as a series of database tables and allowing some users to view or edit them, surely?

This approach would seem to offer the following advantages:

• Low cost: one avoids the high licensing fees charged by most BRMS vendors
• Low complexity: you only develop what you need, avoiding the excessive functionality and sophistication offered by some BRMS tools
• No Vendor ‘lock in’: you avoid becoming beholden to a vendor company
• Easy Integration: the product is tailor made for your architecture, so integration costs are minimized; furthermore, you are not obliged to perpetually upgrade a vendor’s product according to their schedule.
• Customization: the tool is precisely tailored to your users’ needs, surely a better fit than any vendor solution could offer?

However it is our experience that some of these benefits are illusory:

• It’s Not Cheaper To Develop Your Own Toolset: it is very easy to underestimate the cost of developing your own rule management software. Databases and spreadsheets are actually very poorly equipped to represent rules and extra functionality will be required to plug these gaps. These omissions may be realized up front by your requirements analysis efforts, but worse, and much more likely, they will emerge as your rule authors start to use your home built tools, leading to scope creep. Typical gaps include:

• Ability for business users to view, edit and test business rules in a business facing environment
• Ability to integrity check rules to ensure there are no duplicates, overlaps, gaps or inconsistenciesas the user enters them
• Ability to support an agile business vocabulary or domain specific language
• Facility to represent rule conditions based on enumerations, text pattern matching, set membership and inequalities (these are hard to represent in a database without needless duplication)
• Opportunity to enforce (and change) rule execution sequences
• Ability to reduce rule set size and repetition by allowing rule reuse and specialization through inheritance
• Functionality to compare different versions of rules and to audit their change
• Automation of the rule development lifecycle (e.g., enforcing reviews and testing) and auditing this
• Ability to support collaborative editing and testing of rules
• Automated regress testing of rules
• Definition of different user communities and their privileges.

You will need to pay for the analysis, design, development and testing of all of these. It is our contention that unless your requirements are severely and permanently simple, the total cost of developing all the of the functionality that you will eventually need far outstrips the cost of commercial BRMS.

A typical, perpetual, multi-node, BRMS license costs the same as 15 man months’ effort from an offshore team. For our experience you cannot develop such a tool in this time scale.

• BRMS Can Be Made Cost Effective: there are cheaper open source BRMSs and means of making the adoption of BRMS less expensive. Also the return on investment of commercial BRMS is higher than bespoke software.
• Vendor ‘lock in’: as your home built tool evolves, you will be locked in to a vendor: your own development team or offshore development partner.
• Customization: the ability to have a tool precisely tailored to your needs can backfire because it lowers the threshold at which users will demand more functionality. Consequently you may find yourself chasing more frivolous requirements and change requests just because the perceived barrier to customization is lower.

In addition, there are many inherent disadvantages of developing your own tool:

• Lag Time: with a commercial BRMS, only a training programme stands between your team and realisation of business rule benefits. If you develop your own tools your time to market is increased as you need to analyse, design, develop, test, train users and maintain your own software in addition to your rules.
• Isolation: most vendor tools have wide user communities and are backed by large multi-nationals – expertise is commoditised: you can easily procure consultancy from the market, even offshore packages. However, in a user community of one you are isolated and exposed to the churn and economic stability of your own development partner.
• Lower Quality: most vendor tools are exposed to rigourous testing, both during development and in the field, by other consumers. However, your self-built system only has your team as beta-testers and you must factor in the costs and delays of this exposure.
• Limited Growth Potential: your current business rules requirements may not merit much of the sophistication a BRMS can bring – but your requirements are likely to grow as you see how useful business rules can be and to what other applications they can be put.

Ultimately, building your own business rule management system fails the common sense test: you would not contemplate the development of any other commodity software package – a database, ETL engine or operating system, for example – why on earth would you develop your own rule management system?

Conclusion

Although convinced by the value of business rules, fear of excessive cost or complexity may deter you from investing in commercial BRMSs. Be aware however that there are many hidden costs in developing your own solution, enough to make it more expensive (in the long term) than the commercial alternative.

We would strongly recommend that you direct your efforts to making your commercial investment as cost effective as possible and maximizing its return, rather than developing your own rule management software.

Useful? Please share: