Blaze Advisor 6.5 springs forward, falls back
Verification and automated testing for business rules bring more reliability to rule services; if only the new tools were easier to useFollow @infoworld
Rule lifecycles will invariably differ across organizations and projects, and Blaze 6.5 makes managing this process somewhat easier by providing a set of tools to assist in the movement of rule projects through the various stages of the rule lifecycle. An example of this might be in moving through development, staging, and production environments, but could also include testing environments of various sorts. Another good use for these tools is managing large rule repositories, where different teams author different parts of the repository. Using these tools, a team can manage its part of a project independent of others, and on differing lifecycle timelines.
Usability quirks and irks
These features are not without a price. The tools are difficult to use and difficult to set up properly. There are two main reasons for this: complexity and usability. The complexity is unavoidable with a tool that performs these types of functions, and the system does allow you to save settings and manage them as a project artifact, so once set up properly, things become easier to manage.
The usability of the GUI is another matter. The more complicated the tool, the more user-friendly the interface needs to be. It seems that engineers, rather than GUI specialists, designed the Blaze IDE, and that they had certain conventions in mind about the way things should work. The learning curve is rather steep, and the absence of error checking in the IDE makes it easy for new users to shoot themselves in the foot. The system happily allows you to create objects that can’t be used. If you’re not careful with each button click and keystroke, you can end up having to redo your work.
Click for larger view.
You have to click repeatedly many times in a row to add filter conditions. How about a two-pane window for adding entity types?
Whenever you create a new folder in the repository, you have to go back and select it again in the file browser dialog. Why not automatically move the focus to the newly created folder?
And finally, generated deployment shell scripts always have improper permissions.
GUIs are not easy to create, so it’s understandable that Fair Isaac would focus on things like runtime deployment and the rule engine, which are unaffected by any of these quirks. But employing a usability expert when designing the tools and observing how users interact with them would go a long way toward improving their usefulness.