The Best-of-Breed Rules Engine Fairy-Tale for Governments

Rules engines often come with big promises to government departments:

Isn’t your government business all about rules and decision making ? Do you want to get rid of hard-coded legislation and policy? Do you want to get rid of IT geeks needing long time to change coding for every minor policy change? Do you need agility at low cost? Do you want visibility of all your rules in a central repository?

“Yes, yes, yes” is the answer of the government business; “Finally someone who talks our language”.
Unfortunately, the implementation often stops when policy and legislation is modelled and tested by pushing excel sheet content into the stand-alone rule engine. Do not get me wrong, I am a big fan of the rules engine approach, but how good is an approach where a rules engine is being sold by it-self into a fragmented legacy environment? And is this really a cost-effective approach?
Done “green-field” without a solid platform approach, the fairy tale often ends quickly with a hangover. People fell so much in love with the concept of a central rules repository that they forgot how data-hungry rules engines are. Input from an excel sheet and output into an excel sheet is hardly a use case mirroring reality.

Sure any modern rules engine can be called from – and can call – web services, but calling services across systems is often far too slow for many high volume government processes. In addition, rules engines are not only data-hungry in the sense of data consumption, but also in terms of modelling and data modification. A rules engine needs tight integration into many aspects of your IT landscape.
Let us look at a typical government example “rule-based form processing”:
1. First, you need to define form fields. Your rules engine should know those form fields without copying the form definitions across your IT landscape for rules engine consumption. If the data fields of the forms change, you should not have to tell the rules engine about those changes.
2. Then you design your rules for your form (pre-population, validations, calculations and alike). Often those rules need to read additional data on your processing platform. So again, data should not be transferred to the rules engine. The rules engine should be able to make real time decisions real-time in the operational (and not a secondary analytical) system.
3. When processing your form (e.g. during an assessment) the data transport between the form and the rules engine should come out-of-the-box.
4. It should be possible to reinstate a form process in case an error occurs half-way through the process. The rules engine must be able to detect that some of the rules for this “processing object” (e.g. a tax registration) have already been processed – so do not process them again.
5. When the rules get complex, it is important to understand and audit the sub-results the rules engines calculated in order to come to a specific result. Such tracing capability is not only crucial during the testing of the rules, but is also sometimes legally mandated. So integrated rules engines need to link processing objects with rule traces.
6. Whatever technology you are using, if you need to overcome system boundaries between your operational system and the system hosting your rules engine, you will quickly experience performance issues in case you need to process thousands of assessments calling the rules engine for each individual processes object.
While the points above are just examples, governments must evaluate a “fully integrated platform rules-engine” approach before deciding for a “non-integrated best-of-breed rule engine”.
With the digital core of S/4 HANA, you can not only run a data-integrated rules engine, but also use modern digital tools such as predicted analysis without moving data around your system landscape. Furthermore with SAP Decision Service Management is out-of-the-box integrated into many SAP applications. Let us know if you want to learn more.