BRF Day 1: How Many Business Rule Analysts Does It Take to Change a Lightbulb?

Seriously, that was the name of Giovanni Diviacchi’s session that I attended this afternoon, which looked at his experience as a business analyst at both Freddie Mac and Fannie Mae (the two big government-backed mortgage companies in the US). He had a number of good pointers on how to extract rules from the business and document them in a way that will be properly implemented by the developers.

They developed a “business action language” for the business analysts to communicate with the developers in an unambiguous way, including statements such as “present” (i.e., >0 and not null), “mutually exclusive”, “is required”, and my personal fave, “read my mind”.

He pointed out that the old axiom “rules are meant to be broken” is true even for business rules, in that you can’t ever plan for all the ways in which a rule might need to be overridden; he discussed one case of a woman who was born prior to 1936, never worked and never had a Social Security Number, which meant having to override the rule that SSN is required for a mortgage. There’s a lot that can be learned from this one example: I see so many rules embedded directly in applications — especially web applications — that make some assumptions that aren’t necessarily true, such as assuming that all people have a US address.

I often work through issues of policies, procedures and processes with my customers, and it was interesting to hear his comments on the relationship between policies and rules. He said that if the policies are well-written, the rules pretty much write themselves, and by spending more time on the policy behind the rules, you end up with a better set of rules. That definitely caused an “aha” moment for me in my emerging role as an evangelist for business rules in a BPM world, and will help to form some of my ideas on how all these things come together.