State Farm presented at IBM InterConnect 2017 on their challenges with large scale deployment of IBM Operational Decision Manager (ODM) – IBM’s Business Rules Management System. State Farm has a set of specific things it wants out of its BRMS:
- Well defined artifact lifecycle for auditing
- Rigorous deployment process support for confidentiality and consistency
- Self-service so authorized users can work 24×7
This is a pretty technical topic as State Farm is a large scale user of rules and IBM ODM. They have >500 rule projects with rulesets that vary from 100 rules to 10,000, some invoked every few minutes to very large volume batch jobs. Some of the decisions are trivial but others have big legal implications and must be 100% right. 45 different teams with 430 users of Decision Center are working on projects with over 80 deployment targets on Linux and Z/OS hosts.
They need RuleApps – the deployable units – to have well defined content, be accessible, controlled on need-to-know and governed appropriately for its criticality. Each RuleApp version is built once to ensure consistency and decouple deployment from the Decision Center editing environment. They are then promoted through the test and production servers. Its also important to manage the system users and business users appropriately.
Key precepts then:
- RuleApp builds that are promoted for real use come from Decision Center
- Well-formed RuleApp version baselines to track content
- Self-service tooling to manage RuleApp, XOM, builds etc
- Keep users our of the RES consoles – make it so they don’t need to be in the console
The automation underlying this has been evolving and is now moving to Decision Services and the Decision Governance Framework as well as working only in Decision Center. UrbanCode is used to manage the deployment automation, accessing the Decision Center and other ODM APIs, storing the compiled artifacts and managing the solution. State Farm originally built this themselves but newer versions have UrbanCode plugins.
State Farm really wanted to manage the executable object model – the XOM – so they could make sure the XOMs needed by RuleApps were deployed and available. Newer versions of IBM ODM allow you to embed the XOM in the RuleApp deployment so it is self-contained and not dependent on the correct (separate) deployment of the XOM.
End to end traceability is the end goal. Baselining the RuleApp means you know which rules and rule versions are in the RuleApp. In theory all you need to know is the ruleset that executed and the baseline of the RuleApp deployed – this tells you exactly which rules you executed. Decision Center tracks who deployed which RuleApp to where and when, linking the deployment to the RuleApp baseline. But to get this detail to the Ruleset level you need to add an interceptor to add the baseline details to each ruleset.
Versioning is critical to this traceability. An intentional versioning scheme is a must and deployment is done by replacing the old deployment explicitly so that version numbers are managed centrally. State Farm embeds version information in names. Most users just deploy asking for latest version, and this works automatically, but this explicit approach gives control and options for using named versions when that is needed.
Lots of very geeky ODM info!