For those of you interested in such things, I thought I’d highlight some stuff from my attendance at this year’s Business Rules Forum.

Terry Halpin gave a great tutorial on verbalizing, visualizing, and validating business rules. Although it had a lot of ORM, of course, his main point was to talk about rule modeling in the general sense so that even if you are saddled with the semantically and technologically inferior ER/UML techniques, you could still think about static business rules and how to express them. In other words, he highlighted stuff to look out for so you don’t screw it up when using ER/UML.

Terry is always fun to watch. He delivers the content with skill and ease and is very entertaining because he occasionally delivers dry wit and a few well-placed derisions. My favorite of this session was, "RUP [Rational Unified Process] has to be iterative because it is so easy to get it wrong."

Not to do a disservice to Terry, but since we all know how great ORM is, I won’t provide any further details about his presentation here. Much of the lecture was based on a series of articles titled "Verbalizing Business Rules" available on his website (about halfway down the page).

Tony Morgan, a colleague of Terry’s over at Northface University, gave what I felt was an inspired presentation on the notion of a Virtual Rules Engine (VRE). You can think of a VRE as being a mix between a meta-model used to store rules and where they are physically implemented, a validation engine to ensure that the rules are logically valid, and a simulation engine to test changes to business rules upon the entire universe of rules.

His main point was to de-couple the rule from its implementation, something which no business rules engine vendor currently does. This fits right into the general idea of conceptual modeling. You figure out the rules from a business perspective, many of which are static rules right from, say, an ORM model anyway but others are dynamic. After you express, validate, and verify these rules with business users and from a logical consistency sense, you decide how (logical level) and where (physical level) to implement them.

Let’s face it: even if the technological hurdles keeping rules engines from being widely adopted are overcome, you will still have business rules being implemented all over the place: in your database, component layers, user interface, legacy systems, wherever. If the only place you have business rule documentation is in the rule engine itself, you are in just as much trouble as you would be if your only source of business rule documentation is the comments in your C# code.

Anyway, I liked his presentation so much that I’ve added his book to my reading queue.

I then attended "Extreme Business Rules Beyond Agile". Think about that title for a moment. The overwhelming stench of meaningless buzzwords is overpowering, isn’t it? Say it out loud. Don’t you feel silly?

Although I regard many of the tenets of the extreme/agile "movement" to be best practices, many of which I have been doing for a long time anyway, as a "methodology" (the oft used but incorrect term for "method") I feel it is a bunch of crap. At some point, maybe I’ll rant about it in order to back up that assertion but for now I’ll just say that much of my aversion is due to the proponents themselves and their tendency to make straw man and specious arguments. That, and "extreme" programming sounds to me like someone chugging a Mountain Dew, saying "Dude" a lot, listening to corporate Gap-punk "music" like The Offspring, and then frantically writing code. Oh, and don’t forget the baggy pants.

Anyway, to his credit, the presenter, who I shall not name, did admit that the "Religion" surrounding agile/extreme was a bit much. Further, he strays from it here and there when adopting it to a business rule approach, albeit his definition if business rule is a bit contrary to most and focuses on code generation from a repository. Anyway, true to form, he made a bunch of (what I think are) funny and indefensible statements:

Using agile techniques "the quality of the software goes up exponentially". Really?! Exactly how is that measured? Ah, I thought so. No matter if you can back up your claim, just say it breathlessly enough and they will follow, eh?

"There is no argument against pair programming". Uh, well, this book has several....

On the business rule approach, "If you give me a word doc of natural language sentences, it had better be able to generate a database." Hi, we haven’t met, but my name is ORM.

On refactoring, "Sometimes when you have the aircraft carrier in a river pointed in the wrong direction, your only choice is to blow it up and re-build it in the right direction." Well, you could always just not steer it in the wrong direction or up a path where you have no alternatives in the first place. Silly analogies are another trademark of these guys....