RSS FeedOver the course of my career, I've seen attempts on various projects to eliminate the need for ongoing developer involvement in system maintenance. The argument goes something like this: If we could just build a flexible business rules engine, we wouldn't have to call the developers every time we need to update our
Don't get me wrong... there is definitely a time and a place for application configurability. It's just that business owners (egged on by developers looking for a good challenge) tend to over-extend the concept. For example, they may foster the creation of a new micro-language for defining pricing rules. Something like:
IF ($PRICE$ > 100) $PRICE$ * .90 --> $PRICE$ ELSE $PRICE$
Given that I personally know both people who read my blog, I know you could implement the parser to apply this business rule. And why not? Now my business owners can be in complete control of their pricing rules! We're not just talking a few canned rules... No, I mean autonomous, unbridled, master-of-your-own-universe power!
But there are a few catches. What happens when my business owner misses a closed parentheses? Well, it's back to the drawing board to write a user-friendly syntax checker (a.k.a. compiler). But then, they forget the symbol for manufacturer cost and complain (which is, of course, $MFG_COST$). Well, it's probably time for documentation (language specification) and macro-builder (IDE). The next complaint you get is "My pricing rules are getting really hard to enhance without messing them up." Well, this time (again because I know who my readers are) you realize you'll need to implement a unit testing framework and educate your business owners on Test Driven Development.
By now, however, the gig is up. You don't know how to implement a unit testing framework for your new language, POOP (Pricing Open Operation Protocol). However, you've now spent 20% of your career developing it, its compiler, it's language specification, and its IDE. You're highly invested - it's no time to abandon POOP now!
You forge on... You begin gathering pricing requirements from your business owner (if only you could just program all day), implementing them, and demonstrating them for acceptance. It's just that you're life is harder than it used to be. You used to have a powerful, expressive language (C#), complete documentation (MSDN), whiz-bang development tools (Visual Studio & Resharper), and unit testing framework (NUnit). Now you've just got POOP.
17 comments:
Very nicely put. now only if my boss understood that.
Even if you do get a solid DSL going (extremely easy, frankly), it is not going to be easy to manage the system over time for non developers.
What are you going to do when you have 15,000 rules?
Kevin, you actually have 3 readers :)
Nice post.
From my experience, after such a system is built the users are reluctant to using it.
Perhaps this comes for lack of confidence in what THEY are doing.
I think for many businesses today that want to unload developers, outsourcing routine tasks will look more lucrative.
U are talking about home-grown business rules engine. What about embedding a 3rd party business rules engine in your product? What do u think about that?
@ reshef
I have yet to see a business rules engine that allows non-developers to effectively manage application logic. In my opinion, developers provide more value than just the knowledge of a language syntax. They possess a strong ability to understand, construct, and test logical statements. However, I'm open-minded, also. If the right tool came along for the right situation, I wouldn't hesitate to use it. You just need to be extremely aware of the pitfalls.
Actually, I share your opinion. I reviewed the ILog rules engine and got the feeling that it "opens up" the the application too much to the business owners and their actions might have unexpected side effects on the system. Just was curious to know if there is an engine that might do the job.
Thanks for the post - made me think and blog a response at Believe in business rules (I do).
Enjoy
JT
Author, with Neil Raden, of Smart (Enough) Systems, Prentice Hall 2007
You've got at least one reader you don't know. ;)
I've certainly found this to be true in my work. Shortcuts aren't short, they're just cuts.
You now have at least another reader you don't personally know. Insightful, funny, and oh-so-true ...
(This kind of silliness killed one of my projects a few years back ... )
This just what the market needs, a new product. Salesmen and Marketers love selling POOP now. This wil be a cake walk for them.
You will be raking it in. Don't forget the glory days, when you were just a programer and you needed to wear robber boots because your boss kept you in the dark and you doing POOP. Now you actually use what you have been taught. Concrats....The WaAmbulanceDriver
I did give a try for some years but soon realised that business rules are market oriented and everyone wants quick fixes. Essentially you land up with a everchanging program! to address the new bussiness rules (which is a reaction to market)
Do discussants agree that it useful to draw a distinction (at least for the purpose of discussion) between business rules that are independent of any particular process and those that are not (ie can apply to any process)?
The distinction would be between the rules relating to objects, which enable objects to maintain an internally consistent state (eg those that determine the conditions under which that object will provide a service and those that determine updating after an object has been involved in providing a service ), and those
that control service activation.
If considered useful, the simple labelling could be 'object business rules' and 'process business rules'.
My gut feel is that clarity and communication to all, including non-IT, would be improved if the term 'business rules' is only used when the use applies to both kind of rules. Otherwise, writers could be more specific; as suggested.
Didn't Microsoft try something like this? Oh yes, it was called Windows Workflow Foundation...
@fregas: And SSIS, and ..., and so on...Lather Rinse Repeat.
just a "me too" comment, but --
from what i've experienced, it doesn't matter how well the configuration system works, if its use requires thinking in multi-layered binary logic, you will need a programmer or mathematician to configure it. managers think in english, not in truth tables. giving them nested parens is not equivalent to giving them the ability to use them correctly.
so now i've got an awesome editor for a state machine brancher that i am the only user of... :(
@dut... truly one of the most intelligent blog comments I've ever read "managers think in english, not in truth tables"
Post a Comment