This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: SOA Meets Business Rules
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
After reading this article you just might be thinking that business rules management systems (BRMS's) are the key to what SOA was supposed to bring (now that we're in the trough of disillusionment) - that is, if you haven't tried working with these beasts before.
There are several now-well-known fallacies around BRMS's. One is that business analysts write the business rules, in plain English, and these rules do not require a programmer to enter/code them into the system; the BRMS handles all that.
"Costly, time-consuming transformation from business terms to programmer requirements and subsequent implementation can be reduced or eliminated. This in turn empowers business analysts to create and maintain the business logic directly, allowing them to make changes with little or no IT intervention."
But, the author forgets to mention who performs these trivial activities:
"After testing and validation the business logic can be deployed to a business rules server."
This brings me to the single most important thing anyone should know about the business rules approach. Employing a rules engine opens up the possibility that the system will behave non-deterministically. Consider that only 3 non-linear equations are needed to create chaotic behavior, and try to imagine what will happen in a system with hundreds and thousands of business rules that affect each other.
Yes, business rules often end up changing data which, in turn, causes other business rules to be activated. No, it is not humanly possible to look at such a set of rules and predict what will happen when a certain event occurs. You can fire such an event in a test environment and see what will happen. When the results aren't what you wanted (that would be all the time), you can use the BRMS's to show you which rules were run as a result of that event. Let's see a business analyst debug that. "Plain English" my butt.
Let's not go too much further on the BRMS on its own, but rather view it in the light of service-oriented architectures.
In the article, an approach is shown that is supposed to bring you the best of both SOA and the Business Rules Philosophy. I'm afraid that my experience has been otherwise. The author states:
"The business rules server may be implemented as a Web Service that is accessible to many SOA enabled applications across the organization. By supporting shared business logic within the SOA architecture that can be addressed by many disparate applications, organizations can reduce redundancy, speed implementation, lessen inconsistency and improve the overall efficiency of both the applications and the business processes they serve."
This desire to concentrate all business logic into a single BRMS embodies the 11th fallacy of enterprise computing, as put forth by James Gosling "Business logic can and should be centralized". Not to mention that this goes against the grain of SOA where each service is autonomous and is entirely responsible for all of its data and behavior. There's another reason why the business rules community is pro centralization - the BRMS's are so damned expensive.
Anyway, I don't want to be all doom and gloom today so I'll end on a positive note. While good OO practices and the use of the Domain Model Pattern will take you VERY far in making business rules explicit, and, therefore, their maintenance and evolution much less costly, sometimes you really neeed a BRMS. Just so you know, the investment you made in the domain model is not written off when you "upsize" to business rules - the rules themselves are written using the concepts exposed in the domain. As for the service, well, its message handlers keep on working the same as they always did; parsing messages and making calls on the domain model. The business rules will just respond to the events raised by the domain; message handlers don't need to call into the BRMS.
Oh, and the next time somebody tells you how business analysts will be doing the work instead of programmers, ask them if they're willing to take the debugging too :)
Previous Topic
