Eric Charpentier, an independent rules consultant who has also been blogging from BRF, gave a presentation on business rules governance and management. He makes a distinction between governance and management, although that is primarily in the level: governance deals with the higher-level issues of establishing leadership, organizational structures, communication and processes, whereas management is tied to the operational issues of creating rules and the day-to-day operational issues. He proposes a number of ingredients for rules management and governance:
- Leadership and stakeholders, including identifying stakeholders, classifying them by attitude, power and interest, and identifying roles, responsibilities and skills
- Communication plans for each stakeholder type
- Identifying types of rules, particularly around complexity and dependencies
- Understanding the lifecycle of rules within your organization, which shows the process of creating, reviewing, testing, deploying and retiring rules, and the roles associated with each step in that process
- Rule management processes, with details on rule discovery, authoring and other management tasks, right down to rule retirement
- Execution monitoring and failure management
- Change management, including security and access control over different types of changes
- Building a rules center of excellence; interestingly, Jim Sinur recommended a joint BRM-BPM CoE in his presentation this morning, although I’m not sure that I completely agree with that since the efforts are often quite disjoint within organizations (or maybe Jim’s point is to force them closer together)
Eric obviously has a huge amount of knowledge on organizing rules projects, but he also proved his practical experience at this by discussing two case studies where he is involved as a facilitator, rule author, rule administrator and developer: one in a Canadian government project, and the other with Accovia, a travel technology provider.
The government project is a multi-year renewal project where legacy AS/400 systems are being converted to service-oriented architecture, and rules were identified as a key technology. In order to gain an early win, they extracted rules from the legacy system and put them in a BRMS, exposed them as web services and then call them from the legacy system. In the future, they’ll be able to built new systems that call those same rules, now that they’re properly externalized from the applications. They’re using a fairly simple rule lifecycle (develop, test, deploy) that combines authoring and change management because they have a small team, but have specific timelines for some rules that change on an annual basis. They have processes (or procedures) for deployment, execution monitoring, failure management, testing and validation, and simulation, although they have no rule retirement process because of the current nature of their rules. The simulation, a new process, takes the data from the previous year and runs it through new potential rules in order to understand the different impact on their costs; this then allows assessment of the new rules, and the appropriate policy set that in turn selects the rules for production.
The Accovia project is focused on their off-the-shelf software product, where they are embedding rules as a key component of the software. They have some rules that are internal to the software, and others where they allow the client to customize the rules; this means that the typical rules project roles are split between Accovia and their clients. The clients won’t be able to change the basic rules models, so the challenges are around creating the environment that allows the clients to make changes that are meaningful to them, but are also resilient to upgrades in the core product. They haven’t solved all of these problems yet, but have identified six possible rule lifecycles that need to be managed.
Some key lessons learned about rules governance and management as a wrapup: this takes time, and needs good stakeholder analysis. You may also need to do some research and consult your technical team in order to understand all of the issues that might be involved. Very comprehensive presentation.