Welcome to the IDIOM Decision Products Knowledgebase.

alt
 



Recent Comments

    Designing Repositories and Decision Models

    Mark Norton  3 February 2010 02:36:27 PM
     

    Tuesday, October 20th, 2009
    Decision architecture or modeling is primarily about managing the delegation of responsibilities – and this separation of responsibilities is a strong advantage provided by the approach. Another concept that should be kept in mind is ‘normalization’ – the objective of data normalization is to eliminate (or at least reduce) redundancy and ambiguity. This objective applies equally in a decision context:
    • Each decision should be administered by one, and only one, domain expert;
    • Decisions should be grouped according to their context event (a model is always invoked in response to an event), their sequence, and their data context;
    • Decision models should be grouped according to their data context and business domain.

    To interpret this in the context of decision modeling we can say that a decision model is defined and owned by a nominated domain expert (although it may be maintained by more than one person). We would not expect multiple ownership within one Decision Model.

    A Decision model should provide a complete response to an event within the nominated domain of the business owner. It is feasible for one business owner to have multiple decision models participating in one transaction at different times. For instance, a financial administrator might ‘own’ the model that applies taxes, discounts, and time payment premiums to a purchase cart total. They may also separately own a model that ‘approves’ the customer account credit. This situation would result in two models when the following conditions exist:

    • Each model participates in a different series of transactions;
    • The models can be used independently of each other;
    • There is a dependency on other domain expertise required between the participation of the two models.

    One or more of these conditions should cause model separation. Within these criteria, decision models should be as large as possible.  Any dependencies between decisions are easily managed within a decision model – but they might not even be apparent across models, therefore the bias should be towards larger models and greater cohesion.

    Dependencies between models can only be via data elements in their respective schemas. Ideally, there will never be two decision models claiming accountability for one element. Such a situation implies ambiguous delegation, and is ultimately a business issue. The solution is to separate the data into additional context elements.

    Multiple data models should be aggregated into repositories based on cohesion around their schemas. Again, the bias should be towards greater cohesion, bigger repositories. One benefit is that formulas can be shared across decision models within a repository without diluting ownership.

    On the other hand, unlike decision models that do not share schemas should not be forced to coexist in Repositories to reduce the number of repositories.

    Note that calling a decision model is a negligible overhead – calling 1000 decisions has more or less the same runtime cost whether they are in one decision model, or multiple decision models. The primary driver for an optimal decision model population is the management objectives implied by the term normalization.