What are business rules?
Let’s start with Wikipedia:
A business rule is a rule that defines or constrains some aspect of business and always resolves to either true or false. Business rules are intended to assert business structure or to control or influence the behavior of the business. Business rules describe the operations, definitions and constraints that apply to an organization. Business rules can apply to people, processes, corporate behavior and computing systems in an organization, and are put in place to help the organization achieve its goals.
Viewed that way, a business rule is a type of integrity check; like a function you can call to see if you can proceed any farther, or to determine which branch of a fork to take. That’s a bit more restrictive than I’d like, but it’s a start.
A second definition draws its inspiration from functional programming: It breaks a complex business process down into a set of simpler subroutines that can call even simpler subroutines, in a manner similar to functional decomposition. At some point, things become simple enough that you can resolve them without further decomposition. We could call those business rules, I suppose.
ServiceNow looks at business rules in terms of triggers in a database – in other words, automated logic that kicks in when something happens. That certainly fits many automation systems popular today:
A business rule is a server-side script that runs when a record is displayed, inserted, updated, or deleted, or when a table is queried. Use business rules to accomplish tasks like automatically changing values in form fields when certain conditions are met, or to create events for email notifications and script actions.
…but it’s really limiting in scope, and like previous two definitions, it’s more technical than logical.
Ultimately, though, I think this definition from Leonardo Consulting isn’t half bad. They essentially say a business process covers what should happen and who/what will do it, but business rules consist of the details about how something is done. The business rules could be embedded directly in the process (making the design rather large), or could be invoked from a catalog of sub-processes.
Separate the What from the How
From a workflow point of view, I want to separate the “what” logic from the “how” – because the expertise in one area is not the same as in another area.
Think about changing the oil in your hard-working farm tractor. There are experts in oil changing – some might be from the tractor’s manufacturer, with documentation on their website. Others might be independent tractor repair shops who have recorded step-by-step videos on YouTube. That’s the “how.”
And then there’s you and your farm. It’s up to you to determine the appropriate time to change the oil. Perhaps it’s every three months, according to the calendar; perhaps it’s after so many hours of running the engine; perhaps it’s before storing the tractor for the winter. It’s up to you to set those criteria, and then the “change the oil” process will trigger when appropriate. That’s the “what.”
How about another example: your company has recently merged with another company. You’ve been merging the capturing/handling of sales leads into a single process, but customer data is still being kept in two very different CRM systems, and will be for the forseeable future. How to manage lead data in Salesforce vs. Microsoft Dynamics would be two very different “how”s. What to do with a lead up to the point of interacting with one of the two CRM systems is “what”. Actually, how to determine which of the two CRM systems may well be a “how” in and of itself.
Citizen developers vs. domain experts
The oil-changing how-to videos and professional documentation were created by highly trained mechanics whom you may never meet. Call them domain experts. On the other hand, the when/who decision about changing the oil, and assigning that task to someone, that came from you, or your farm equipment manager. Your day job is to run a farm, not to become a tractor guru. Call such people citizen developers.
There are powerful parallels to business rules in your workflow system. The “how” processes in your workflow library can be created by modeling experts, consultants, or IT programmers; they might be part of a standard toolkit, or programmed upon request if there’s no such building block already in the library. Because those “how” workflows are meant to be used and reused in many situations and by many separate departments, it’s worth investing the time to ensure they are high quality: Defect-free, performance-optimized, and well documented.
Those reusable modules can then be used by people in line-of-business departments – the citizen developers, as we often call them. They have a lot of work to get done, and they can see your business process management systems as a way of getting that work done. If the “how” business rules don’t exist, or it’s too complex to get them made, your end users won’t be empowered to model their business process. But provide them with the tools they need – and the essential knowledge about how to use those tools – and they will leverage workflows to make business processes automated, efficient, and repeatable.
The Who and When Factors
One would think that who will be involved in a process is something the citizen developer handles in “what” workflows. For example, which farmhand changes the oil in a tractor, or which account manager follows up with a lead exactly three days after it has been registered.
But it turns out that “who” is just as important inside of a “how” process. Some steps in tractor maintenance might require procuring more oil, which wouldn’t be known until it’s time to change that oil. Someone may have to approve it. The sales leads example? When posting a lead, the “how” process might check to see if the lead is already registered, and if there’s a not-quite-identical name match, it may be necessary to ask a human to decide if the new and existing lead are the same or different.
The question of when also shows up in both places. We’ll normally think about deciding when something should happen as part of a “what” process authored by a citizen developer, but domain expert-authored “how” processes may sometimes contain deadlines, and can even be registered to react to changes in data rather than waiting to be called by a “what” process.
Cooperation and Interdependence
In the sales leads example above, the people who know how to prospect and convert leads into opportunities have a different skill set than the people who regularly interact with CRM software. Each needs to be able to depend on the other to author their part.
Moreover, the greater the level of domain expertise, the greater the responsibility to provide a catalog of “how” workflows that can be used over and over again by multiple citizen developers. Registering a sales lead in a CRM system might be used by a booth expo process, a telemarketing process, and a web campaign process.
Final Things to Keep in Mind
I moved as quickly as I could from talking about business processes/business rules to talking about “what” and “how” processes. That’s because, ultimately, they’re all processes. Moreover, one person’s “how” is another person’s “what”. Every process automation should (ideally) be designed with reuse in mind.
Breaking larger processes into reusable, interdependent processes not only scopes the work to the person best suited to understand it and/or the appropriate department (to avoid political squabbles), but it makes a big difference in comprehension.
A giant process diagram containing all of the “what” and “how” details is very, very difficult to understand, let alone create, let alone improve. You could certainly say that a single 100-step process is no more or less complex than a set of ten 10-step processes, but the human mind wants to focus on one thing at a time. Smaller diagrams facilitate focus. And analysis. And improvement.
About Mike Fitzmaurice
Mike Fitzmaurice is the Vice President of Workflow Technology for Nintex, the world leader in workflow and content automation, and is its subject matter expert and chief spokesperson for workflow, business transformation, and technology matters.