We do a lot of decision management projects, helping clients adopt the technologies and approaches they need to succeed with digital decisioning and decision automation. One of the key technologies for these types of projects is a Business Rules Management System (BRMS). Sometimes, we get push-back on using business rules because existing business rules projects or past business rules experience have soured a company’s perception of the effectiveness of the technology. Our view is that this is because consultants and others misuse this powerful technology.
With that in mind, here are five reasons to fire your business rules consultant before they sour your view of this valuable technology.
1. They want to do rule harvesting
When a business rules consultant says that you should invest in a rule harvesting effort, fire them.
Rule harvesting involves making a long list of all the rules (in a business, a document or an existing system) and is an utterly useless task. It creates a big bucket of rules, all at different levels that are mostly very technical. If someone tries to implement these rules directly, the resulting mess will take too long and cost too much to be effective.
Even if you take a decision-centric approach to designing the solution, the list will turn out to be useless because it takes longer to match the list to the decision than it would do to analyze the decision using the source material. As we said to one company “you might as well burn the money you’re spending on rule harvesting, at least then you’d be warm”.
Instead, look for consultants who will talk to the business about the decision you are trying to automate first, model out how that decision should work and only then capture the rules needed to make that decision in the context of that model. DecisionsFirst™ as we like to say.
2. They call it a rule engine
If your rules consultant uses the term “rule engine” (rather than a rule management system), fire them.
This is a key sign they think execution matters more than management and that they think “old school”. Many rules consultants grew up on more limited products, where the rule engine was the key component. Improved hardware performance, better algorithms and a better sense of what rules can be used for have all made the engine itself an irrelevance in 99% of projects. What matters is not how you execute the rules (all products do a good job of this), but how you manage them.
Instead, look for consultants who are focused on how to manage and update the business rules you need to make your decision – rule management and decision management. They need to know how to deploy your rules as stateless, side-effect free decision service but its much more important they know how to help you manage your rules.
3. They put off business user enablement to phase 2
When a rules consultant says that IT is going to manage the rules in phase 1 and that business user enablement will come in phase 2, fire them.
Business user enablement – empowering the business to manage their own rules – happens either in Phase 1 or in Phase Never. You must begin as you mean to proceed: once you release a set of rules into production that are managed by IT, the business will assume that IT is managing this system just like all the others. Plus, the rules will have been developed in a way that only programmers can love. Nothing you do subsequently will change this. In addition, most rules consultants underestimate what is really required for business user rule management.
Instead, look for consultants who deliver business user management of the rules immediately. The best business user rule management environments are structured using a decision model (to give business owners a map of the decision-making), focus each group of business stakeholders on just their own rules, provide point-and-click governance and version control, and come with really good impact analysis tools so the business can see what a rule change will do before they deploy it.
4. They smush process and rules in one project
When a rules consultant says they are going to define the process and write the rules in a single, integrated development task, fire them.
Business rules are for decisions, not processes. Documenting and executing the rules in a process is not an effective use of business rules technology. Entangling the rules with the process steps results in lots of little packets of rules being coordinated by an overcomplex process. Spaghetti code by another name.
Instead, look for a consultant who will formally manage decisions and focus business rules technology on automating those decisions. Decisions can and should be invoked from your process, but modeling and managing them explicitly encapsulates the decision-making complexity (and the rules) to keep the process clean and simple.
5. They want to use ORs, ELSEs, ELSEIFs…Oh My!
Finally, if the rules your consultant is writing have ORs and ELSEs or ELSEIFs, fire them.
This is programmer-thinking and makes for complex, hard to manage rules. You rapidly start having to count parentheses and understand predicate logic to read the rules and that excludes most of your business owners who just don’t want to invest that much time. If they use ELSEIFs or long first hit decision tables, that’s more of the same.
Instead, look for a consultant that uses a decision model to decompose the decisioning you need and focuses on using representations like decision tables that support independent rules, each with a simple set of conditions. Encapsulation not entanglement, ease of reading not clever logic.
Our DecisionsFirst approach begins by engaging the business directly to build a decision model using the Decision Model and Notation standard. We iteratively capture the rules needed to support this model (along with any analytic insights or algorithms that are part of the decision). We use decision tables as much as possible to simplify the rule representation. We deliver a business user continuous improvement and decision management environment in phase 1 that has simple, decision-centric rule editing for business users supported by impact analysis and simulation as well as a dashboard to see how decisions were made in production and how well that worked out so business users know what to change.