Wednesday, March 05, 2008

The Power of Skunkworks

Google alerts made my day with this blog quote :)

The Power of Skunkworks
While at LPA me and a guy from Amentra were told to make the Blaze Rules Engine to work in ways it was not built to be used. After banging our heads on it for a month, countless conference calls with Fair Isaac, and general disgust with the complexity - I spent a weekend learning Drools and replaced it. It was perfect. Just what we needed. I switched their coffee with mine, and they never noticed. I told them a week later what happened. Told my boss. Then his boss. Several conference calls later my system was officially in - Blaze was out, saving our company $250k/year in license and support fees.


  1. Surprised this guy admits he couldnt get the Blaze BRE working, but could get DROOLS working. Wonder what he was doing wrong? Or maybe he meant the BRMS, not the BRE?

  2. It wasn't that he couldn't get Blaze working, it's that Blaze wasn't flexible enough to do what had been asked of him:
    "were told to make the Blaze Rules Engine to work in ways it was not built to be used"

    Seems that the FIC support couldn't help either, so doubt this was due to his lack of Blaze knowledge:
    "After banging our heads on it for a month, countless conference calls with Fair Isaac, and general disgust with the complexity"

    I could be wrong but as I understand it Blaze does not really separate the BRMS and BRE - you have to do everything through their BRMS. I imagine it is just the BRE he is interested in, as he does say "Blaze Rules Engine". Java developers are use to light weight embedded projo frameworks, maybe it is this that is frustrating him.

    Don't get me wrong Blaze is a very powerful product, feature for feature I think it is the most comprehensive BRMS out there. But it is aimed at business users and is very "Enterprisey", which means it may not appeal to the Java developer market, which is the market that Drools targets.

  3. Mark, that is entirely correct. It isn't that there was something wrong with Blaze, it was just an example of overkill for our needs. Our CIO bought into the sales pitch and threw a huge budget at this rules engine that was far more than what we needed it to do. We needed the engine to be a component of our system, not the other way around which is exactly how BRE is set up - to be built into, not around.

    We had several conference calls with the developers, and the components we required to hook into were not available as an API. When they started suggesting we access unpublished internals to get the job done - that's when I started looking elsewhere.

    Again, nothing wrong with BRE - it was just far more than we needed, which was the real point of my post. Also, this was 3 years ago - things may be different now.

  4. Intriguing. So basically this was a deployment pattern not supported by Blaze, but is (and/or can be hacked together in) DROOLS. Any more info? Supported in JESS or OpenRules too?

  5. From my limited experience with blaze 6. The deployment model of blaze requires you use the IDE to create a deployment package. That package is then integrated into the target application.

    The model is a bit monolithic and isn't very flexible. The BRMS is also a bit limited and doesn't track versioning at the rule level. I found the functionality far behind what JRules offers.

    Also, modifying the RMA rule editing webapp to use some other look and feel is far more difficult than it needs to be. There isn't any editor for it and requires manual wrangling of their template files, which are called GSP. I took a look at the JSP and the organization and structure is a bit ugly and unwieldy. Back when I did JSP and UI work, we did some fancy things like multi-language support, and our code didn't look as messy as Blaze RMA.

    In my bias opinion, the RMA needs to be rewritten from the ground up, so that is is extensible and makes it easier to create Skin designers. That way customers can use their own look and feel.