I could start this blog with a cute saying, but the essence of the blog is more serious so I shan't. Manny Gandarillas posted an article http://www.BRCommunity.com/a2009/b487.html on BR Forum that was a tongue-in-cheek view of the different views of a rulebase as experienced by different personnel on any rulebased program. Subsequently, James Taylor posted a response on BR Forum at http://www.BRCommunity.com/a2009/b487.html where he took Manny to task for some of the things that he said. So, just to add another view, permit me just a quick view of both articles and an even briefer rejoinder.
First, neither Haley Expert Rules nor Mind Box are considered "leaders" in the world of BRMS. Way back in 2004, with some agreement from both ILOG and FICO, I wrote a brief definition for a BRMS at http://www.infoworld.com/t/business/business-rules-management-systems-548 that was pretty much as brief as one could be and still say anything about it in a 400-word side bar. In that description I did say that, for the most part, the business analysts should be writing the code BUT with the guidance of a full-blown knowledge engineer. Since that time I have seen situations where the BAs did not want any help whatsoever from the IT guys except to construct the architecture for the Java classes, database, web screens, whatever. In other situations, the BAs wanted no part of writing the rules except for writing them into the rules document and letting the IT department implement them in what ever fashion they deemed fit so long as it passed the final testing for both validation, verification and speed.
Let's face it: The business guys have the money but have not the technical expertise to use it properly if left alone. The IT guys know how to implement things but the real rules of business are usually beyond their job skills. The rules help implement the "what" and the "why" of what happens in the coropration, not the "how". The "how" is normally left up to IT. BUT, at what point do we draw the line between the BAs and the IT guys? This last bit is what can cause a BRMS to fail if one party or the other cannot resolve their power struggles and work in harmony with the other. Business is, after all, the customer of the IT department. And if business wants things to work correctly, they need to be friends with the geeks.
I do think that James is spot-on about the business personnel not needing to care about forward or backward chaining, sequential or Rete or Dete or whatever - it's the geeks who will have to make this blooming thing perform properly and scale to enterprise proportions who will be, should be, concerned about those things. And the BAs will HAVE to work with the IT guys to accept that some things will work and some things won't work.
However, let's get one thing perfectly clear: When the BAs take over the logic of the rules then THEY are the ones responsible for the testing and verification of the results, not the IT guys. To me, this has and should be one of the great things about a real BRMS; the BAs take responsibility for what actually happens. Normally, this kind of arrangement just provides more and more work for the IT guys who have to design more enterprise architecture to handle all of the various rulebased system (BRMS) that will begin to crop up once the word gets out that the rules CAN be changed, tested, verified and put into productions in days (three to five) rather than months. BUT, and this is equally important, the design of a proper BRMS is not an easy task and it DOES require the expertise of someone who has done this several times for many different companies and knows where the land mines are located.
Bottom line: Even with the shameless plug for BR Forum and his book, James is right on several of the points. However, Manny did bring up some bullet points that gave us a focus on our discussion. Personally, while I might not agree with all of the contained thoughts in Manny's chart, it was unique and should be shared for further consideration by most vendors. (OK, it's a twist on the old view of an elephant joke.) Now, for my shameless plug: If you guys really, really ant to get into the technical semantics of BRMS, come to October Rules Fest in Dallas, http://www.OctoberRulesFest.org and see what the CIOs and technical architects think about the BRMS hype.
BTW, what is the best way to eat that infamous elephant? (A: One bite at a time.) The same applies to a BRMS or rulebase or any other unfamiliar territory. Take it slow, make something small work first with the ultimate goal to incorporate all of the corporate knowledge into the rules. Not today, not this year. But maybe in five years. :-)
SDG
jco
Posts
