Unum – Managing business rules #bbc2010

Subtitled “from 0 to 1400”, this case study discussed how Unum (an insurance company) introduced business rules. Back in 2009 their rules were scattered, siloed, hidden in requirements documents and in different formats (from code to if/then statements to long verbose notes). And even though they tried to focus on rules, they were often embedded in documents that were full of things that were not even rules.

They decided to move from this environment to one in which the rules were managed as a corporate asset. This meant centralizing them, making them consistent and putting them into a governance environment (repository, processes). They saw this approach improving their agility, their speed to market. They also hoped that this would improve business understanding of the rules and their documentation. Finally it would allow for impact analysis and create alignment between the products and the business vision. Unum’s process involved selecting a methodology and a supporting repository, then they did a pilot and got executive sponsorship before rolling out the rest. So, what did Unum learn?

• Have a pictorial view of how rules are managed
• Had a small (2 person) central group to ensure consistency and manage approvals etc
• Each business domain had a lead business analyst focused on business rules to leverage the small central group and give each business area some business rules skills
• Wrote the rules (for analysis) in natural language to ensure business ownership and understanding but enforced a consistent syntax (sentence patterns) because they were planning to automate these rules
• Define roles – business analysts to document rules, business architects to own them, a rule quality team and a rules development center of excellence to manage implementation
• Have a repository that allows editors, read-only access and sharing
• Repository is rule engine agnostic
• Domains can create and approve rules for their domain before passing them on to the enterprise level for approval and sharing
• Train business analysts in analysis skills, not just business knowledge
• Focused training on their specific needs (customized) and set up regular user group sessions to discuss and agree changes
• Business analysts take the lead in documenting rules in English
• Expect change management to be an issue – adopting rules is a big change and there can be a lot of resistance
• Develop a consistent, centralized glossary
• Get top-down support and have a change agent/champion
• Have an iterative approach
• Realize that rules are not requirements