Mark Norton 8 February 2013 09:03:22 a.m.Bottom line – the issue is not the tool! Idiom’s major difference is in the approach to building a decision centric system, and our tool is simply the best (but possibly not the only) implementer of our approach. With this approach, we have invariably developed large scale decisioning systems much faster than customers have expected – some referenceable examples include auditing for a $AUD30bn pension fund, underwriting for one of the world’s largest insurers, and billing for the 47 hospitals, 121 outpatients clinics of the Hong Kong Hospital Authority.
The risk is in the approach, so that should be the primary focus. A traditional development approach leaves developing the full complexity of the decision-making policies until later in the development cycle, and can only confirm the correctness of the developer's interpretation of that complexity when the data dependencies are fully wired in and available to the Drools (or other rete based) engine. This inverts the development dependency – that is, you need a system to wire the rules into, but you can’t know what the system must look like before knowing what the decision-making looks like when correctly modeled. This inverted dependency is the root cause of failures in complex decisioning projects (because you are building blind, and the subsequent complexity undoes you).
With the Idiom approach, we would expect to fully develop (ie model) the decision-making policies and test them completely independently of any application. This activity is an order of magnitude (literal use of the term) less than the application development build implied above, therefore both cost effective and risk averse. This is a business/analysis function, not a development function. When proven, we would then loosely couple the model(s) at the database or application service level as required. The implication, correctly, is that the rules may stay the same even if the system changes and vice versa. The system reflects current technology choices, whereas the decision model(s) always reflects the current business policy – and this means two distinct life-cycles, so that thereafter, policy and application would live in different life-cycles.
Idiom delivers the decision-making complexity in a form that the policy makers can manage ongoing, more or less independently of the technical application and its developers. This policy focus is further supported by a new tool, the Idiom Decision Tracker, which traces and reconciles the bi-directional dependencies between policy documents (as defined in MSWord, Excel) and the decision models that are implementing those policies.
Some areas where Idiom differs technically from Drools are as follows:
1. Drools has no visible global rules model; Idiom has the Decision model and the Formula Palette:
· Drools implements rete, this is a ‘condition/action’ paradigm where the conditions and actions are atomic (they don’t know about each other – the role of Rete is to orchestrate them at run time), so that it is impossible to see and test the combined affects without testing the entire model in situ;
· Idiom builds a decision model where the linkages and dependencies between decisions is visible and manageable, and can be tested immediately and interactively even when incomplete.
· Drools is developer oriented and rules are programmed within a Java development environment (Eclipse); Rules are defined in DRL, a text based language (a Drools rule file is a text file) that is scripted by authors just as they would script Java itself.
· Idiom is business oriented, with rules ‘programmed’ by dragging ‘lego-blocks’ in a graphical model that is ‘more fun than playing golf’ – quote from the CEO of the company that delivered the rules for the Hong Kong Hospital Authority billing.
· Idiom’s decision model does for the rules what the data model does for a database!
2. Drools is tightly bound to the underlying system object definitions; Idiom is tightly bound to a data schema representing the domain problem:
· Drools wires in every required attribute with code at the method level. Any change to the required data requires a programmatic change to the application code base.
· Idiom defines all data using an XML schema – new data can be added without any programming change.
· This highlights a high degree of decoupling in the Idiom approach that can be made absolute with some smart technical design – without this decoupling, the ‘independent life-cycle’ concept is impossible to manage.
3. Drools' ability to manipulate the context data is very limited; Idiom can manufacture new, large and complex data objects as required within the rules execution process:
· Drools’ limited condition/action paradigm means that large scale manipulation of the context data cannot be done – for instance, dynamically creating intermediate data constructs that represent different data conditions over time.
· Idiom can generate large, virtual data objects from scratch (within the rules execution process) to synthesise different situations derived from the supplied context data. This allows Idiom to build multiple images of each transaction that are amenable to different rules, but which are not naturally visible in the inbound data (that is, it takes the rules-builder’s knowledge to make them visible).
An example of this is entitlement calculations where there is overlap between policy changes, and changes in claimant circumstances, within individual cases through time, so that each unique time slice within one case may give rise to a different application of rules. This was also a critical complexity of the hospital billing problem above, where many contracts may concurrently apply to a single patient episode, overlapping over time.
- Comments