Well last week was exciting on the ebizQ blog – thousands of new visitors after a link from a popular programming blog. This article – Programming Sucks! Or At Least, It Ought To – referred to an old article of mine – Don’t soft-code, use business rules that had been prompted by his article on soft-coding. Following so far?
Clearly, having provoked this storm of interest, I should respond. This week I will write three posts to answer this – one will recap the basic premise of business rules and make it clear what I mean, one will take some of the arguments Alex makes and show why I think his arguments should lead one to adopt a business rules approach and one will take the specific comments I got and address them. Should be a fun week.
Let’s start with the snippet of code Alex used in his posts and with which I took issue in Don’t soft-code, use business rules:
private void attachSupplementalDocuments(){ if (stateCode == "AZ" || stateCode == "TX") { //SR008-04X/I are always required in these states attachDocument("SR008-04X"); ...
Copyright © 2009 James Taylor. Visit the original article at Business Rules to Programmers – Methink thou doest protest too much I.
Syndicated from ebizQ
Well last week was exciting on the ebizQ blog – thousands of new visitors after a link from a popular programming blog. This article – Programming Sucks! Or At Least, It Ought To – referred to an old article of mine – Don’t soft-code, use business rules that had been prompted by his article on soft-coding. Following so far?
Clearly, having provoked this storm of interest, I should respond. This week I will write three posts to answer this – one will recap the basic premise of business rules and make it clear what I mean, one will take some of the arguments Alex makes and show why I think his arguments should lead one to adopt a business rules approach and one will take the specific comments I got and address them. Should be a fun week.
Let’s start with the snippet of code Alex used in his posts and with which I took issue in Don’t soft-code, use business rules:
private void attachSupplementalDocuments(){ if (stateCode == "AZ" || stateCode == "TX") { //SR008-04X/I are always required in these states attachDocument("SR008-04X"); attachDocument("SR008-04XI"); } if (ledgerAmnt >= 500000) { //Ledger of 500K or more requires AUTHLDG-1A attachDocument("AUTHLDG-1A"); } if (coInsuredCount >= 5 && orgStatusCode != "CORP") { //Non-CORP orgs with 5 or more co-ins require AUTHCNS-1A attachDocument("AUTHCNS-1A"); }}
Three (perhaps four) rules, 13 lines of code and three comment lines. Alex then went on to say
And then there was this one guy, James Taylor, who basically called me an idiot for suggesting that developers get their hands dirty with business rules. Apparently, we should all be building whiz-bang expert systems with fancy UIs that let the end user do all of the dirty work.
…such expert systems exist only in the land of pixie dust, unicorns, and lossless compression of random data
Well, I guess I did call him an idiot (more or less) for coding 3 or 4 simple business rules in code and arguing that was a good way to go – though quite what my post has to do with Expert Systems, unicorns or pixie dust I don’t know. I would no more suggest an Expert System for managing these rules than I would suggest hard coding them.
Now these are pretty simple rules and I am certainly not suggesting that if these were the only rules for this decision that it would be worth coding them in a business rules management system or BRMS. Despite the opinions of some of the commenters I am not, in fact, an idiot. But the decision “Identify Supplemental Documents” probably has more rules in real life than the example – I can’t believe, for instance, that only AZ and TX have state-specific rules. Given that, coding these rules in a business rules management system would be way better than just stuffing them into an ever-longer piece of code.
Now a typical business rules management system would probably give you very similar rules:
If StateCode is AZ then attachDocument(”SR008-04X”) and attachDocument(”SR008-04XI”)
If StateCode is TX then attachDocument(”SR008-04X”) and attachDocument(”SR008-04XI”)
If LedgerAmount is greater than or equal to $500,000 then attachDocument(”AUTHLDG-1A”)
If coInsured Count is greater than or equal to 5 and OrganizationCode is not “CORP” then attachDocument(”AUTHCNS-1A”)
There are not many differences here – a BRMS would let you use slightly more user-friendly terms for attributes, for instance, and avoid having to teach users what && or != mean for them to be able to read them. A BRMS could probably handle the coInsured Count declaratively so you would not need to maintain it as a separate variable but who knows – you might be doing this for some other reason anyway.
These rules are more approachable – they don’t have programmer speak in them – and they don’t require comments like those in the original code – but the changes are pretty minor. If I only had four rules, this would not be worth it. But if I had several hundred then my code starts to become voluminous and the ability to manage the rules becomes more important than the specifics of each individual rule. Using a BRMS I can:
- Easily find all the rules that relate to a state or a document or that use a particular attribute
- Check for contradictory or incomplete rules using the underlying logical structure of the rules
- Log the rules when they fire for debugging or for compliance without writing any additional code
- Have the lawyers or business people who know what the rules are interact directly with them
- Have different groups or people manage their rules (TX rules v AZ rules, for instance) and easily combine them at runtime
There’s more but I want to finish the post today. The point is that coding these kinds of rules – rules that are largely independent of each other and that have high business/low technical content makes them harder to manage and harder to verify and keeps the business users at arms length.
Of course for some programmers, that’s the point – they like to keep their priesthood unsullied by non-programmers. These were the same programmers who insisted that business users could not build their own reports or manage their own business processes. Yet company after company has successfully empowered business users to do both these things. I guess some programmers will continue to lie down in the face of the bulldozers of progress but hopefully some will realize that some of the logic in their systems is not technically complex and can, and should, be managed by the business users who are deciding that that logic is.
As Jim Sinur over at Gartner said, If You Bury Key Business Rules, then You Will Bury Yourself
