Best Practices In Rule Governance
By James Taylor
Well here I am at DIALOG 08, ILOG's user group. The show passes the " Kemsley" test because there is wireless Internet access throughout the event, enabling me to blog live.
First session was from Pierre Berlandier of ILOG talking about business rules governance. The session was packed - despite the option of playing golf instead of attending, with 50 or so people in the room.
The key role of a business rules management system or BRMS is to facilitate change - indeed I think it is fair to say that the best measure of success for a BRMS is the extent to which business policy changes can be rapidly and effectively into production. A BRMS promotes agility and clarity among a disparate group of stakeholders (business, IT, QA, analysts), improving communication. However it can be too easy to modify the system and there can be too much communication - who changes what, when, how does it get undone etc. Can end up with problems in ownership, accountability, traceability, accuracy and trust. Rule Governance is the critical "shield" around a BRMS to make sure that rules and managed effectively by a collaboration or IT and business. Four things are required:
• Identify Stakeholders
• Assign roles and responsibilities
• Define processes to manage expectations and control policy change implementation
• Create an entity to manage and update processes
You need to end up with a well defined orchestration of the rule life cycle for the particular BRMS being used and for the particular context in which it is being used. Pierre identified three challenges:
1. Staffing the various roles
It is not considered a priority initially and most folks are multi-tasking. You must have a plan that is realistic about resource availability!
2. Internal politics
Fights over control and problems with mutual trust - many IT departments have terrible relationships with their business users.
3. Lack of BRMS experience
Hire outside help (like me) and take an incremental approach
He pointed out that, in general, you should target the production phase as this is where it is really going to matter. You can use the initial phases to practice and refine your processes. So what steps should you take? Pierre laid them out thus:
1. Develop the organization Map
Consider creating a business rule management team at the application and/or enterprise level. Acts as a liaison and owner of methodology as well as prioritizing changes.
2. Rule Set Access Control
For a given decision point in the application you need to look at the rule sets. Who owns each rule set, which users can review and author it and so on.
3. Rule Life Cycle
What status can a rule have and who can move rules between these statuses - needs role definitions and appropriate repository queries to find rules in each state. Keep it as simple as possible.
4. Deployment Plan
Procedures, production monitoring, etc.
5. Process Maps
Change management (authoring, deployment, testing, retirement) and execution control (reports and KPIs for production).
Ultimate goal is help fulfill the promise of a BRMS as the technology alone will not reduce barriers between business and IT nor develop a sense of accountability. I should say that none of this is really particular to ILOG's rules products - anyone implementing any BRMS has these issues. |
0 comments:
Post a Comment