I got a walkthrough of Corticon‘s Business Rules product last week – the first time I have discussed it in a while. Version 5 has some interesting features. The Business Rules Foundation is a set of headless services, designed to support a variety of development tools, UI frameworks and metaphors along with a variety of persistence mechanisms. On top of this Corticon ships its own Rule Studio, built in Eclipse, and IDS Scheer ships its ARIS Rule Designer (allowing rules to be specified in parallel with process models and stored together in a single repository). The core engine uses code generation, currently to Java or .Net . Finally there is a data integration layer to integrate external data so that it can be accessed as needed by rules as they execute rather than having to be marshaled for a call to a decision service.
The tool is aimed at less technical users and this is something Corticon certainly works on. I have my doubts about Eclipse as a business-friendly tool but Corticon does offer a fat client version that is more streamlined. Users define a vocabulary (either from scratch or by importing XMI, UML, XSD or Java interfaces) and then specify constraints on attributes, map that to the inbound data or to external data sources and define rules against the vocabulary. Rules are defined in rule sheets (similar to what most vendors call rule sets) and these are linked together into ruleflows – what I might call a decision flow. The rule sheets are designed to make it easy to define the values different attributes must have for a rule to be true (using a table metaphor) and can then be linked to rule statements (something like reason codes) with a rich set of meta data related to outcomes. Corticon’s approach is sometimes called a Decision Table but there approach is different than mot others – less compact but able to define more complex rule logic in the table. Rule conditions trigger actions, such as setting attributes to specific values. The ruleflow allows sequencing of these rule sets as well as some iteration and branching – the iteration seems mostly needed to compensate for the lack of a Rete engine to automatically re-fire rules but could also be used to iterate more generally.
Validating that rules are complete and consistent has always been something Corticon has handled well. While a number of the vendors have closed the gap recently, the table metaphor Corticon uses works in their favor here and this remains a strong feature. They have added some nice testing facilities, allowing input, output and expected data to be compared. This kind of support for regression testing has become widespread in the rules industry in recent years and it is nice to see it here also.
Corticon prides itself on being “model driven” and on not needing much programming support. One area this shows up is in the data connectors which do not require any SQL writing, for instance, instead generating it from the model (vocabulary) and database schema. Obviously this is easier for non-technical users but it does mean that specific stored procedures or SQL could not be used to access a database and this could be a little limiting.
Corticon has also started expanding into application frameworks with one aimed at automated customer acquisition (primarily in Insurance).
Comments on this entry are closed.