Welcome to the IDIOM Software Blog.

    Decision Models and Normalisation

    Mark Norton  24 June 2013 04:23:19 p.m.
    Can normalisation be applied to business rules?

    In a recent article in Modern Analyst, New Opportunities for Business Analysts: Decision Modeling and Normalization, Larry Goldberg and Barbara Van Halle (principals of Knowledge Partners International [KPI]) posit that normalisation as it applies to data can be refactored and applied to decisions, essentially by using the decision term ‘conclusion’ as a substitute for the data term ‘key’, and the decision term ‘condition’ for the data term ‘attribute’.

    This transforms the colloquial definition of normalisation from ‘every attribute must describe the key, the whole key, and nothing but the key’ into ‘every condition must participate in the evaluation of the conclusion, the whole conclusion, and nothing but the conclusion’. Sounds good!

    Larry and Barbara claim that normalisation is science not art, and assert that this science can be applied to their Data Model concept – in fact, it is a fundamental premise of it. IDIOM commented on the opportunity to ‘normalise' decision design in its original published article on Decisioning (published in the Business Rules Journal, Jan 2007). Our view at the time, and one that we continue to hold, was that normalisation is more art than science, although we did and do agree that it provides useful lessons for decision designers.

    This post discusses normalisation as it applies to decision models. Unfortunately, ‘decision model’ has different meanings in the KPI and IDIOM vocabularies, which needs to be clarified.

    The KPI concept of a decision model is a relatively recent innovation that provides a formal structure for collating decision tables. It is intended to present the normalised structure of the ‘business logic’ as it is defined by collections of condition statements, which collectively derives a single ‘decision’. A decision in this case is a special class of ‘conclusion’ (one that is deemed to be of special interest to the business), so that the KPI Decision Model is a model of the internal structure of a decision.

    The IDIOM Decision Model on the other hand, is a structure containing a collection of decision(s) and is defined as follows:

    Defn: An ordered assembly of decisions that creates new and proprietary information to definitively determine an optimal course of action for the business.

    The IDIOM Decision Model is a model of a collection of decisions and the relationships between them, including logical groupings of decisions that are achieved by the eponymous ‘decision groups’ within the decision model, so that the IDIOM Decision Model is a larger concept that has an external existence that is independent of any particular decision. It is the collection of decisions working together that delivers value to the business in the form of a single, significant, orchestrated and inherently valued change of state. By definition, all decisions involved in the state change must operate as a single ‘unit of work’, hence the larger concept called a decision model.

    To our knowledge, there is no equivalent construct described in the KPI published works.

    In IDIOM, the internal structure of a decision is described by a formula. In KPI terms, a formula can implement anything from a single condition, to a single row in a ‘rule family’, to the rule family itself, to a complete KPI Decision Model. Actually, it can do substantially more because the formula can use the full range of data and logic operators rather than just the logic (ie Boolean) operators that are available to the KPI conditions.

    Because any formula can be implemented via a decision, it is possible that a KPI Decision Model could map to one or more IDIOM decision groups, decisions and/or formulas.

    The decision definitions have a likeness between the KPI and IDIOM worlds.

    A ‘decision’ in KPI terms is a synonym for a conclusion as described above, albeit with the qualifier that it must be ‘of interest to the business’ viz.

    KPI Defn: A business decision is a conclusion that a business arrives at through business logic and which the business is interested in managing.

    IDIOM defines a Decision as:

    IDIOM Defn: A proprietary datum derived by interpreting relevant facts according to structured business knowledge.

    While we think the word ‘proprietary’ conveys the business linkage in the IDIOM decision definition, the business importance of any individual decision is not highlighted in the IDIOM methodology, since this is subservient to the overarching intent and purpose of the decision model.

    While these terms appear to be similar, in that they both describe decisions that are derived by the application of business knowledge, they also harbour a distinct difference.

    The KPI emphasis on ‘business logic’ (their emphasis) as the means of derivation highlights this difference. Business logic is but a small subset of the operators available to the IDIOM formula, and this substantially limits the scope of ‘decisions’ that can be defined by the KPI Decision Model. When this significant limitation is coupled with the limited ‘single decision’ scope of the KPI Decision Model itself (when compared with the bigger IDIOM Decision Model concept that could include hundreds of decisions), the effect is pronounced in terms of the type and scope of decisioning tasks that can be modelled. But the question remains, can normalisation as a concept be validly applied to these models?

    The normalisation of business rules in the KPI article is achieved by applying the traditional normal forms (first, second, third are described by KPI) to the set of conditions that are associated with a conclusion, aka a decision. IDIOM agrees with the KPI assessment that the relationship between conditions and conclusions as described benefits from applying these normal forms, which provide a useful guide to organising the underlying decision tables. This approach might be of value in building an IDIOM decision table, although these are not often used natively in IDIOM formulas – the equivalent results are usually easier to achieve using other means.

    We have agreed that normalisation can be of value in organising the decision tables that are the essence of KPI Decision Models. We now look at the concepts that KPI does not implement: the IDIOM Decision Models and the Formulas.

    The datum that results from an IDIOM decision is always output to a defined context node, and the context is always assumed to be normalised (in its data sense), therefore the structure of each decision’s derived data is normalised by definition.

    However, in the IDIOM Decision Model, each decision also has a distinct location in the Decision Model itself, which is unrelated to the location of its context data.

    Does normalisation have a role in this model?

    Probably not. Normalisation is defined as a function of the dependency between an item and its key(s) – or ‘conclusion(s)’ in the KPI view. The existence of a decision or decision group in an IDIOM Decision Model is always unique by definition, because its location in the model has meaning – this is emphasised by the word ‘ordered’ in the decision model definition (because the same decision made immediately before or after another could deliver a different result). This means that the model is normalised by definition, just as a data model would be if we were to define each datum simply by its position relative to the key (example: if the definition of the first attribute says, “the first attribute for the entity”, etc. then it is correct by definition provided it is first. While sounding simplistic, this can occur in practice, with for example, “address line1” of an Address entity).

    And within a formula? Here the answer is probably yes. To normalise the logic within a formula means breaking the formula up into its component parts, each of which is unique across the entire model (and beyond actually, to the entire Repository, which is an IDIOM concept that could equate to an application or even a whole enterprise). The only qualifier is that this involves a small effort, and if the redundancy is entirely local, there is always the pragmatic option of simply copying the logic within the formula itself.

    As a final general comment, we tend to avoid reliance on normalisation in its more prescriptive forms. Notwithstanding its ‘scientific’ dependency notation, it is more art than science.

    Normalisation is a set of very useful guidelines for structuring data to reduce the potential for update anomalies. While normalisation is a powerful concept and is fundamental to good data design, it does not of itself provide a ‘scientific’ solution to any problem.

    Determining what data is relevant to the problem domain (what is your point of view?); choosing the level at which to define it (would you use 28 tables to define how to render a single name from its name components, as was done for the failed billion dollar CS90 project?); choosing the balance of meta data and data (is describing everything as name/value pairs normalised?); and creating the actual definitions for each datum (where you place an attribute in the model will prescribe its definition, and vice versa); these are all very loosely defined, subjective assessments that get input to the ‘scientific’ normalisation process, giving rise to the statement made in our earlier published articles:

     “Data normalization is a semi-rigorous method for modelling the relationships between atomic data elements.  It is 'semi-rigorous' because normalization is a rigorous process that is dependent on several very non-rigorous inputs, including:

    ·        Scope:  determines what is relevant -- we don't normalize what is not in scope.

    ·        Context:  determines how we view (and therefore how we define) each datum.

    ·        Definition of each datum:  this is highly subjective yet drives the normalization process.”

    In summary, we think normalisation has an important role in structuring the data used by and produced by decisions. It may also be useful to help understand and structure decision tables. Its overall usefulness in this regard would depend on how widely used decision tables are within the methodology; in the case of an IDIOM Decision Model, this is limited.