Are BPM and BRM combinable? What is the return on investment? What challenges do typically arise in the project? There are many questions and issues that arise in a BRM project. We have summarized 10 interesting lessons learned from business rules management projects.
Disciplines are compatible
Business rule engines must be flexible and scalable to integrate with different IT environments. Whether you focus on service-oriented architectures (SOA), business process management (BPM), or other applications, the business rules management (BRM) approach brings more flexibility into your systems and more agility into your business. However, the variety of disciplines sometimes brings more confusion than clarity about how they work together. Of course, BRM, BPM and SOA can be brought together. With BPM you manage and implement processes and workflows, with BRM you manage and implement business logic and SOA allows you to efficiently implement BPM and BRM.
Various BRM maturity levels
Implementing and maintaining business rules are parts of a life cycle in which you continuously improve the system. At each iteration, you should clarify the degree of implementation. Are rules documented in corporate policy PDFs? Are rules hard-coded in applications, maybe even intertwined with other logic? Or are your business rules managed with a business rules management system (BRMS): stored centrally, deployed consistently, automated and reused as rule (web) services (Central Rule Engine)?
Automate business rules reasonably
It does not always make sense to implement each rule in the business rule engine. Talk to experienced professionals to identify the optimal solution for automation. A rule can also be captured in a database table and / or application. Consider various aspects such as data format and availability, rule type, change frequency, frequency of repetition, complexity, relationship to the workflow or process. A basic overview of when business rules management is particularly useful can be found on this website.
Find the right tools
Do a proof of concept and make sure you have the right resources and people available. Focus on the business capabilities of the tools, on integration aspects and governance functions. Clarify how BRM tasks will be split between business and IT roles later on and involve these users early on to identify their requirements. ACTICO Rules has proven to be a highly efficient BRMS because it covers the entire business rules management life cycle.
If you are interested (or critical) in the division of roles between business and IT in a BRM project, you might want to read this blog post.
There is not the only right way
Starting with business rules management can be done in different ways – but always top-down. Do not get too deep into the rules when you make the “cut” between the processes and rules. In addition, integrate your project development method into business rules management.
The DMN (Decision Model and Notation) standard is a relatively new standard for modeling and implementing business rules. Especially when you start a BRM project, DMN with its top-down approach can help you get the overall picture right, first, and only after that dive into the more technical business rules implementation (learn more on DMN and watch the video).
It’s a cultural shift
A key lesson learned from business rules management projects: BRM is almost always a paradigm shift in software development. IT departments will be reluctant to “give up control” while, in reality, IT only gives up the business logic. What helps you is a clear definition of roles and expectations. And the skeptics from the IT department may find it helpful to think: Finally, they can focus on “real” IT challenges instead of implementing business requirements day in day out. This blog post highlights some more interesting points on the topic.
Rule harvesting is time consuming
Rule harvesting is largely a manual process and therefore time consuming. For most of the rules are distributed across different places: buried in the minds of employees, in documents and in the application code. So try to bring the right people to the rule-harvesting workshops. And accept that you do not immediately come to 100 percent. Focus on the simple path, first, and then on other (exception) paths. Be aware that rules may exist that conflict with others – but no one has noticed so far.
Agility now or later
The entire process requires a lot of lead time (e.g. rule harvesting). Therefore, the return on investment (ROI) is not immediate or evident. Start small to show the ROI and share success stories. Talking to companies that are already successfully using BRM can also help. By the way, on our website you will find a fact sheet for the ROI calculation.
Ambiguity & domain jargons
Each department and even team uses its own jargon and certain acronyms. This often leads to confusion in business rules management projects. It is helpful to have the fact model available to all stakeholders. Be clear, precise and, above all, aware of the context as you harvest the rules.
Some people simply don’t get it!
Business rules management can be pretty abstract. This already starts with the term “business rule”. Avoid ambiguity when using the various terms commonly used in BRM and clarify the benefits of the BRM. The main solution is to educate everyone involved through meetings and trainings, technical papers or forums. A look at the tooling also helps to better understand the BRM approach (example video).