I switched streams to the business rules symposium for the last breakout session of the day, The End of Requirements, because the description sounded too good to miss:
Business wants control of the business back. For years we’ve lived with a process where the business creates “requirements” and IT creates a business solution. While business processes are the lifeblood of an organization, rules are where the volume of business changes are. If the business is going to take back control of its own fate it all starts with making sure that the business rules they own are really under their control after they go into production. The current requirements process simply can’t handle that. It’s time to embrace a Business Engineering-based approach and move beyond the requirement-centric approach that we’ve love to hate.
He makes the distinction between knowledge and behaviour: rules is about (reusable) knowledge, and processes are about behaviour. For example, you might have a rule that would allow you to determine if a customer was a “good” customer, and you might use that knowledge in a process to provide a discount. He discussed different views of rules and how they integrate with processes:
- Rules as structural knowledge about business entities
- Rules as business judgements
- Rules that trigger events
Unfortunately, McWhorter didn’t ultimately talk about how the business is going to get control of the business rules, or how it’s going to work once they do, which is what I was expecting from the session description. He did finish up with a call to arms to bring a design function back into the business side — sort of like what business analysts are supposed to do, but don’t because they don’t have any design training — which would allow proper designs to be created before things are ever passed on to IT.