[Rewrite 1] Two of the industry's leading gurus of rulebased systems, Dr. Hafedh Mili of UQAM (University of Quebec at Montreal) and Jerome Boyer (pronounced Boy-yaa for those who don't handle French very well) have blazed some new ground with their book on ABRD, Agile Business Rule Development.
Dr. Mili wrote all of the training manuals for ILOG up through version 3.x somewhere as well as being heavily involved in versions 4, 5 and 6. Jerome is a Senior Solutions Architect for IBM / Websphere / ILOG. Dr. Mili has been involved with JRules andILOG since 1996 and Jerome has been doing JRules since 2000 [ref: Dr. Mili]. More on that later.
Anyway, on to a review of the book. The extremely brief accompanying web site is http://agilebrdevelopment.wordpress.com/ but, to date, there is only one comment - I'll add mine after I complete my reading of the book. Let's just say that this is an overview or a synopsis of what I found and think.
First, the darker side: Reading through the table of contents is always a good start in any review of a book. This particular book is divided into eight parts. The introduction contains a couple of different approaches to reading and using the book. The parts are:
- Introduction
- Methodology
- Foundations
- Rule Authoring (JRules only)
- Rule Deployment
- Rule Testing
- Rule Governance
- Epilogue
The other place to which I normally go next is to review the references that I might expect to find in the book or article. This book does contain a fairly decent set of (brief) references in the back. Yes, they also referenced Dr. Forgy's work on the original Rete algorithm although I doubt that more than 15 or 20 people in the world actually have sweated through the original Ph.D. thesis (all in LISP) and understand totally how it works. Dr. Mili has been through the synopsis and is responsible for the early implementations of Rete in ILOG Rules (C/C++ version that has been discontinued) and somewhat in JRules.
In any event, Dr. Mili and Jerome did a "fair-to-middling" job of research disclosure but nothing really exciting nor earth-shattering. BUT, remember that this is a book that focuses on the agile approach to writing rules and not the MYCIN approach to more advanced rule writing, even though MYCIN is referenced in the back of the book. (As a matter of fact, I know of only one or two guys from the Rules Fest who have sweated through the MYCIN approach.) The references are broken up into these sections:
- Books
- Articles and Papers (Trade Journals, Magazines, etc)
- Web Sites (lots of them)
- Documents (standards, web documents, etc)
- Tools (short list of most common BRMS and Open Source)
[Ed.Note: Dr. Mili's Ph.D. was in AI and he did quite a bit of research on MYCIN and eMYCIN during that period. However, he says, "I made a deliberate decision not to make it into an academic book because, a) that is not the public we are targeting, and b) rule engine science and technology is NOT where the main challenges in implementing business rules in the industry lay." A good enough reason, although I personally would like to see more medical systems and insurance underwriting systems - among other - research the approach of MYCIN and make rulebased systems once again a real AI product and not just and IF-THEN-ELSE rulebased Rete system.]
The end of each chapter also contains a "Further Reading" paragraph pertaining to that chapter that is sometimes a bit brief but in others quite good and extensive.
There is one drawback: All of the examples are in JRules, a very expensive -and very good -commercial product. However, JRules is very similar to Blaze Advisor, Drools or OPSJ. I would that they had used either an Open Source product or use very generic, English-style rules. They do explain their reasoning for using JRules in the introduction. But I found it kind of weak, especially considering that both of them have been tightly coupled with IBM/ILOG for many years. They said that their second choice would have been Drools (an Open Source product form Mark Proctor) which was OK. Even so, they kind of danced around the FICO Blaze Advisor product, which is the number one or number two commercial product in the market place.
Just a personal aside: I would say that there are only two or three real BRMS products on the market today; JRules, Blaze Advisor and Pega Rules. Drools (the free Apache Open Source product) from JBoss is rapidly gaining ground with "Guvnor" and other additions. Probably by the next year or so, they will have caught up with the most obvious parts of a BRMS, especially if they get their debug reporting tools done up to date. But, I wander...
The book is well divided in sections and they do a really good job of explaining ABRD, Agile Business Rule Development. However, I am no longer being a big fan of acronyms since FICO, ILOG and InfoWorld (yours truly) coined BRMS (Business Rules Management System) to my chagrin back in 2003 and then promoted it to the business world. Further, I don't favor writing a book using acronyms that are not an industry standard. That could be because I'm just resistant to rapid change for the sake of being "cool". In addition, I'm not a huge fan of the Agile methods since they were first introduced several years ago. But, still some of the methods are quite good and acceptable. (Yes, I know I'm sounding wisy-washy, but I'm just expressing my distaste for Agile while still finding some useful things in it.) I found trying to fit rulebased systems to the Agile methods to be the same as trying to find patterns for rules. (We have been trying to do that at Rules Fest for four years now.) [See Carole Ann's comment below about the Agile methods.]
Finally, as part of full disclosure, everyone needs to know that I have worked with both Hafedh and Jerome on various projects and all of these statements above are my own personal opinions. I have tried to the best of my ability to forget that we are good friends and talk about the book from an objective point of view.
Good Part: BUY THE BOOK !! Especially if you have never done an enterprise rulebased project and need a guide. It is easy reading if you are a good programmer and not highly technical. However, it might not be really easy reading if you are not a programmer but, even so,it would be well worth your time to read the management parts. Even some of us older troops could learn a thing or two from their fairly lucid explanations of what they are trying to accomplish with a particular chapter or section. The parts where they use JRules code is easily readable by most programmers and even most managers.
SDG
jco
Posts
