He Who Knows...

Greetings:

Nothing much to do with rules specifically but more with things in general. I ran across an old by-line that I used to use a long time ago:

"He who knows not and knows not that he knows not is a fool.

Shun him.

He who knows not and knows that he knows not is a child.

Teach him.

He who knows and knows not that he knows is asleep.

Wake him.

He who knows and knows that he knows is a genius.

Follow him."

This was supposedly an old Hindu proverb but who knows? Maybe Ben Franklin made it up but it sounds too psychological to be Ben. On large projects I've met all kinds distributed in a natural distribution pattern. Maybe one or two at the top and one or two at the top. Maybe. But lots in between which is pretty much a compliment to programmers everywhere.

Here's the problem: What to do with the first one? Management picked this guy and he/she is a "valuable" member of the development team. I had to point this out to a company once after a two-week gig to help them get started with rules. I told ONLY the Senior Director for the project after he pointedly asked about each person. But his pride-and-joy manger had picked that individual to move from being a contractor to leading the rule development team. The guy had been doing C/C++ stuff for two years and had made very little progress toward a real rulebased system. But, in his defense, his GUI stuff looked really cool.

Truly, he didn't know rulebase development and he didn't know that he didn't know. Their regular employee on the team (who would have to work for this ninny) was more of the second kind; eager to learn anything that you could teach him. I'm not sure where the manager fit on the chart but she certainly was convinced that she had made her decision and she was going to back it up 100%. Also, unfortunately for me, she was the one who hired me and I had to tell her the same thing. They were ecstatic about the analysis that I had done until 2:00 the afternoon that I was leaving. By 2:15 all bets were off. So, I didn't get called back for the traditional "sanity check" because the bare, naked truth was out of the bag and on the table. Now they had to justify keeping these plans and that meant that they did NOT want anything to do with facts.

As one of my old managers used to tell me, "James, you have great technical skills. It's your 'soft skills" that need work. You don't know how to tell anyone diplomatically that what they are doing is trash and that their development personnel need five years training just to get up to the zero level. Sometimes you can't tell someone the truth straight out - you have to sugar coat it so that it tastes better." He was right, of course. Maybe one day I'll find a home where I can just DO things and not have to worry about feelings. So, that's my tale of adventures with the upper class of management. I don't belong there. Hopefully you can learn from that and be nice to nit-wits and dweebs. After all, if God didn't love them he wouldn't have made so many of them. :-)

SDG

jco

Benchmarks 2009 to follow ORF 2009

Greetings:

Just a quick follow-up on all of the earlier posts about Benchmarks. It looks like I'll be doing them AFTER the October Rules Fest rather than before. Too much stuff has piled up on my plate. I do plan on doing CLIPS and Jess on WaltzDB-200 since the code is already written for those. And I've run most of the OPSJ and TECH stuff already. But the multi-platform and optimization as well as the code for Advisor, JRules, Drools and others will have to wait until after ORF 2009 is over. If anyone has a suggestion, or wants to write the code for the last three, I would appreciate it.

It's beginning to look as though the Annual Benchmark Cook-Off will have to be done the last two months of each year since that seems to be when most companies begin to shut down and then crank up again in January.

SDG

jco

FICO Forum: Decision Management Tools User Group

Greetings:

The FICO Forum: Decision Management Tool User Group will meet on September 16 - September 18 at the Hotel Allegro in Chicago, IL. FICO has kindly asked me to chat with the FICO Blaze Advisor users about optimizing rules, benchmarks and things of that nature. My talk will be on September 17th so if you happen to be in Chicago at the time be sure to come by the conference. There is a lot more than my talk, of course, and this can be found at

http://www.online-reg.com/FICO/2009/dmtools/

http://www.online-reg.com/FICO/2009/dmtools/speakers.lasso

if you would like more information about the conference itself or the other speakers. Like most other conferences, I would like to be able to attend all four tracks but I can only attend one session at a time - so in addition to having to attend my own presentation (one that I already know quite well) I'll miss out on 3/4 of the great stuff, including the half-day tutorials on Wednesday. All-in-all, it should be a really great conference.

SDG

jco

October Rules Fest 2009 Books available

Greetings:

More conference news:

More good news for attendees: Dr. Leon Kappleman, a widely recognized authority on Enterprise Architcture, has made it possible for attendees to order his new book on "The SIM Guide to Enterprise Architecture" that normally retails for $59.95 and get a 40% discount. You can get better preliminary details at http://www.routledge.com/books/The-SIM-Guide-to-Enterprise-Architecture-isbn9781439811139 where you can some more details about the book itself. [Added note 10 Aug] Here is a list of contributors to the book: http://courses.unt.edu/kappelman/aboutwork/Book%20Slide%201.pdf

So: Register for the conference THEN register at the hotel for the conference rate. If you have ANY problems (registering OR getting the special ORF rate at the hotel) PLEASE let either myself or Chelanie know about it. See you in October!

Finally: If anyone else has a book that they would like to offer discounts to ORF conference attendees, please let us know and we will start a listing of all of them. But, right now, this is the only one. Enjoy...

SDG

jco

Benchmarking at ORF 2009, Part 7

Greetings:

Conference News:

Dr. Forgy has just about finished up his new algorithm - there's always some last minute thing that needs to be done. While testing his new TECH algorithm on my variousl platforms I have found it to be about an order of magnitude faster then Rete 2 or Rete III on both my MacIntosh, Core2Duo Unix environment and the Windows 64-bit Dell i7. On the i7 (that is effectively 8 CPUs) it scales nicely and provides even faster performance. I can't wait to get my 8-core Mac Pro (the Nehalem 2x4 CPU) and see how it runs there. Dr. Forgy has agreed to discuss the new algorithm after hours during Pub Nights in the Walt Garrison restaurant and bar that is located in The Adolphus Hotel.

OH! You wanted numbers? OK, the only comparison that I have right now is OPSJ versus TECH but here is what I have so far - lots more to come later and I'll publish it all at ORF. We had to use a new benchmark because TECH runs so blooming fast that it's hard to compare the difference in 1.2 seconds and 0.57 seconds as anything meaningful when running WaltzDB-16. OPSJ runs that one 2.7 seconds on the Core2Duo Mac and in 0.433 seconds on the Dell i7. TECH is not really measurable.

WaltzDB-200 (New Benchmark for 2009) - in seconds

Core2Duo Mac, Leopard, 3GB RAM:

OPSJ: 46.467

TECH: 4.549

Dell i7 64-bit Vista, 6GB RAM

OPSJ: 17.466

TECH: 2.362

So, that's pretty much a 10:1 (or thereabouts) speed improvement firing 246,233 rules. Remember, OPSJ is the underlying engine in Java that incorporates Rete 2 / Rete III, the fastest Java rulebase on the planet Earth. Until now, that is. Also, remember that I have NOT finished the full comparisons checkout and double-checked everything to be sure that they are the same and firing the same rules and doing everything. But, so far, it looks pretty fantastic. As soon as I get a chance I'll do the other BRMS and rulebased systems including Drools, Blaze Advisor, Jess, CLIPS and (possibly) JRules.

Depending on when his patents are approved and finalized, Dr. Forgy will be happy to talk with you at ORF about this ground-breaking technology.

SDG

jco

Manny and James

Greetings:

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