The Fundamental Problem of Software Engineering is Not about Decisioning
I am always very careful to talk about ‘business rules’, not ‘rules’. We define ‘business rule’ as a criterion used in business operations to guide behavior, shape judgments or make decisions. We have not perceived any poverty of guidance that fits that definition(!). One reason we always say ‘business rules’ is because we make no attempt to capture rules that mimic intelligent behavior in the original sense of expert systems. That problem is at least an order of magnitude more difficult than capturing organizational (business) rules … which is hard enough as it is. Business rules always trace to some source … even if the source is now unknown (or has gone to work for the competition). Organizations are dependent on people on the inside, and on interactions with people and organizations on the outside. So a great many business rules are about the behavior (of people and organizations). Ensuring conformance with such behavioral rules – and being able to change and redeploy them quickly – is the fundamental failing of traditional software development. It literally boils down to keeping your commitments (as expressed in contracts, agreements, MOUs, deals, certifications, regulations, acts, laws and so on). I’m all for better decision management, but fail to address the root problem of software engineering and we’re simply grasping at straws.Tags: decision management, decision rule, decision rules vs. behavioral rules, decisioning, decisions, software engineering
Ronald G. Ross
Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.