Month: October 2007

I moved over to the über-geeky “chief architect” track to hear Rik Gerrits of RuleArts and Petr Choteborsky of Microsoft, but 10 minutes into the session, Gerrits is still giving some fairly basic definitions of business rules management: where rules live, how they’re developed, and how they’re managed and used. He does make a point that business processes consume business rules but that they should be distinct in terms of methodology and implementation, as well as other motivations for business rules management such as compliance and efficiency improvements.

Choteborsky took over with a case study about Microsoft’s internal development (as in applications for their own internal use, like software licence authorization), and instantly endeared himself to the audience by saying that he was in corporate IT at Microsoft, and was just as much a victim of the Microsoft product groups as we were. They had issues with software development lifecycle documents and the rules that were embedded within those documents: multiple, conflicting instances of rules in different documents; rules not explicitly defined hence less agile; no common vocabulary leading to inconsistency and miscommunication. Over time, the business logic is lost, and the business requirements documentation becomes completely out of sync with the application and the user manual, so that the only true representation of the business logic is embedded within the application as coded.

He stepped through an example, showing how to break down the prose in a requirements document to determine what is a rule set (a group of related rules), what’s a rule, what’s a fact (unchangeable, therefore may be hard-coded), what is usability behaviour (which may include hidden rules and facts), and what is contextual information that describes capability without being something that will be explicitly coded. Very cool example, since he shows the tendency for the prose in what we think of as a fairly well-written requirements document to actually be a confusing mix of facts, rules, behaviour and context that doesn’t really provide adequate information about what should be written to be easily changeable versus what can be hard-coded into an application.

He went on to show how the same paragraph should be restructured as facts and rules (describe the pure essence of how business must be conducted, independent of implementation detail), requirements (UI and application requirements to implement the rules) and context (information that makes it easier to understand the facts, rules and requirements; redundant information that is not coded). The rules mantra (which I’m just learning today) is “rules build on facts, facts build on terms”, and he shows the terms sprinkled throughout the facts and rules.

They’re attempting to change their requirements documents to this form of structured requirements using business rules (for going-forward documents, not retrofitting the existing ones), but it’s a painful process: there needs to be some common vocabulary and a significant amount of training in some cases to have people start thinking in this way. There was a comment from the audience that once the vocabulary — particularly standardization of terms — was established, there’s usually a pretty good uptake from the business community since they really like language that can help them to define their business more precisely and unambiguously.

There was another comment from the audience that what he is calling a requirement is actually a specification, which is an argument that I’ve had about a zillion times in my years of software development: I completely agree with the comment, as did Choteborsky, but he stated that this was the common terminology in use at Microsoft today and he wasn’t trying to fix everything at once. I have to see the pragmatism in that, although there should likely be some sort of migration of terminology to be more accurate.

He went into more detail on terms, facts and rules, including descriptions of each, and the use of graphical term models and fact models. He also made a distinction between a rule and a policy: a rule can produce an action or decision, whereas a policy is more general but might sound rule-like. He stepped through the before and after of a fact model, where he went through and marked each object and relationship in the model as correct, sort of incorrect, or outright wrong, then found new relationship pathways and defined new terms in the model to make it a better reflection of the actual facts and provide a more logical structure for developing rules. He’s just using Visio for creating the fact models, although I’m sure that some more comprehensive modeling tools could make this process a bit easier. They’re starting to use RuleXpress (the RuleArts product) for terms, facts and rules, although the rules themselves are actually encoded within applications: rules management without a rule engine. As he pointed out, although some business rules may end up in a business rules engine, some end up directly in the code of an application, and some are never codified but become part of an operational manual. We see exactly the same thing in BPM, where a process model may include steps that are transferred to a BPMS, but also ones that are completely manual and never represented within a BPMS. Having a modelling tool separate from the execution environment provides greater flexibility in what can be modelled, but I suspect that the same issues of synchronization and round-tripping occur in rules modelling environments as exist in process modelling.

Choteborsky was a great speaker: knowledgeable, able to explain some fairly complex concepts, and funny (when one slide came up, he said “I don’t know why PowerPoint made the font on this slide bold and ugly, but I’ve learned that I don’t need to win every battle”). The great thing is that he presented a methodology for developing business specifications that everyone in the room involved in software development could take away and start examining for their own use.

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.

After a brief intro by Gladys Lam, the executive director of the Business Rules Forum, the conference kicked off with a keynote from Ron Ross, the driving force behind this event and a big name in the business rules community. A couple of things are distracting my attention from his talk: I’m up directly after him, and I’m presenting in this room, which is the main (read: big) conference hall. Let me make my ever-present complaint about passworded wifi in the meeting room and no free wifi or wired internet in the hotel, since I know that my regular readers would be disappointed without that news from the front lines. 🙂

Ron and I have exchanged email over the years, but this is our first opportunity to meet face-to-face; I’ll also have the chance to meet James Taylor and a few others who I only know from afar. Today, Ron’s talking about the shift from business rules to enterprise decisioning. This is the first business rules conference that I’ve ever attended, which means that most of the attendees likely know a lot more about the subject matter than I do, and most of the sessions will be new material for me.

Ron predicted that no one will be talking about SOA at a major conference in 15 years, but they will be talking about business rules or decisioning; I certainly agree with the first point, and the second makes a lot of sense.

When he said “we want our business processes to be smarter”, it was like music to my ears, and a direct lead-in to my presentation. He talked about three trends in the decisioning space:

• The shift from an exclusive focus on BPM to a balanced approach on enterprise decision management (EDM). He mock-grudgingly admitted that business processes are important, but pointed out that the “smarts” provided by business rules provides agility in the processes (which is exactly the point that I will be making in about 45 minutes — maybe the material here won’t be all that foreign after all).
• The shift from an exclusive focus on data quality and accessibility to a balanced approach on decision deployment. This is the whole convergence of BI and BR into decisioning — again, a key point in my presentation. I think that Ron is scooping me! He included a great quote from Taylor and Raden’s new book, Smart Enough Systems: “Making information more readily available is important, but making better decisions based on information is what pays the bills.”
• The shift from an exclusive focus on rules to a balanced approach on decisions. My key takeaway for this conference is figured out a good distinction between business rules and decisioning, since these terms seem to be used interchangeably in some cases; it seems that decisioning is about (not surprisingly) decisions, which in turn are based on business rules and some information about the current scenario.

He finished up with some pointers on where to think about applying decisioning in your business through a few use cases, such as creating “rules of record” for compliance purposes.

Like every other technology-specific conference (especially the BPM ones that I typically attend), this one has at the heart of it that its subject matter is the most important technology in an enterprise, and that herein lies the key to business perfection. I’m being a bit facetious, but we really do need to start getting a bit more cross-over between some of these conferences and technologies.