Asking this question is in a way answering it. After all, if they were completely interchangeable, we wouldn’t need to elaborate. Making the distinction between business rules and processes is quite crucial, especially with the potential value of big data and AI knocking on our doors. Allow us to explain.

Processes versus rules

While rules generally focus on ‘what’, processes are commonly oriented towards ‘how’. Business rules describe for example what needs to be done, what criteria must be applied and what policies must be enforced. Business rules therefore focus on the value that needs to be created in/through a process. Processes on the other hand describe in what order (how) activities should be executed to create the desired value or outcome. It is therefore not a matter of either one or the other; they work in unity. The trouble with business rules however is that they are often not clearly and explicitly defined and are ‘scattered across the organization’. Even employees involved in defining and modeling processes often have a hard time making business rules that govern these processes explicit, or simply ignore these rules altogether. We can’t even blame them as most of us have been, and still are, educated in a process-oriented view. Those of us who do manage to see the bigger picture are – quite literally – exceptions to the rule.

Rules-driven software

Knowing the difference and understanding the relationship between the two concepts has serious consequences for software development as well. Luckily enough, the founders of USoft were well aware of this right from the start. Knowing that processes depend on and are defined by a variety of factors, making them prone to change, they decided to develop software based on business rules rather than processes. After all, unlike processes, business rules tend to remain more stable over time. Hence, the software itself also remains much more stable, is easier to manage and can be adjusted a lot easier and faster in case of changing circumstances and demands. The fact that several of our clients have worked with the exact same software for over fifteen years speaks volumes.

Aviation example

If you look at aviation, for example, you can easily establish a set of universal rules determining whether or not a passenger can board a plane. These factors include showing a valid ticket and ID, passing customs and security and checking in on time. If one of these criteria is not met, a person cannot travel. How these criteria are translated into processes and procedures may vary from one airport to the next. By absorbing all relevant data associated with the rules into one single model, we free ourselves from the burden of further and detailed process modeling to incorporate local conditions as a central element in our software solutions. This approach has provided us with a competitive edge that we are more than willing to share with you. But only if this doesn’t violate one of your business rules of course… For more information on how to ‘play by the rules’, feel free to contact Hans Canisius any time.