Welcome to the IDIOM Software Blog.

    Carole-Ann Matignon and James Taylor discuss complexity - Idiom responds

    Mark Norton  13 November 2010 11:03:41 AM
    This post is in response to a thread running between Carole-Ann Matignon and James Taylor's respective blogs. These are two of the most authoritative commentators in the industry. You can access their blogs from our external links section on this blog.

    Carole-Ann opened with this

    To which James Taylor responded with this

    Carole-Ann returned with this

    Idiom's response:

    Carole-Ann and James, I think you are both exactly right. Innovation is required to achieve simplicity, but how this innovation plays out in terms of product or approach or even the actions of market participants and their clients is uncertain.

    Idiom sees the disabling effect of complexity on our customers on a daily basis. This is not just a tool issue - James has referred to our product as one of the most business centric rules products on the market.

    My view is that much of the complexity is only perceived complexity. By this I mean that at the end of the decision modeling process, what was perceived to be a problem of great complexity is now seen as being far simpler. So the problem itself in such cases is not complex, only the pre-analysis perception of it.

    We think that the decisioning approach is crucial to distilling the simpler essence from apparently complex problems. This approach is dependent on having a clear definition of a decision and then decomposing the problem into a series of atomic level decisions within a decision model. This is analogous to data modeling. Note that the decision (comparable to an attribute in a data model) and the decision model are both essential ingredients in this approach. This is the antithesis of the historical BR approach which has a very imprecise definition of a business rule (hopefully this is not up for debate) and a model that is usually opaque and often dynamically inferred at runtime.

    Many of us are trying to solve the complexity problem. I am convinced that natural language is NOT the way – there is nothing simple about natural language unless you are a local native speaker who understands the ‘idiom’ – the idiom is all important and never simple for any other than a native speaker – the Navaho whisperers being an extreme example. In other words, introducing a new business rules paradigm to current generation SMEs is going to be complex no matter how we cut it, simply because it is not how they currently think – it is not their current ‘idiom’ by definition.

    So one solution is to mimic how they currently think if we are going to make it less complex for them. For this reason we have found the approach outlined in http://bit.ly/c6YfcI is useful – asking recursive questions like ‘what decisions do you need to make in order to achieve xxx?’ This reflects how SMEs think, and they do find it relatively simple to respond. The drawback is that it usually requires a moderator – this is not easily ‘self- actuated’.

    We are finding that this approach is helpful even for the SMEs because it helps them to organize their own thinking and approach. Just last week we worked with the author of a complex clinical pathway trying to codify their own textbook on the subject. By going through the above mentioned approach we collectively evolved the pathway to a new level of simplicity and clarity in 3 days, helping the expert to simplify, organize, and codify their own domain knowledge.

    This is not ‘problem solved’ though – it is still a mentored process, scalable only by the number of mentors. The tool is not the critical factor – the approach and the mentor is.

    Notwithstanding all of the above, I do think that we (being the business rules community in general) have simplified things by an order of magnitude for an entirely different audience – if they let us!

    The audience is the IT development community. The simplification is achieved by removing decisioning entirely from the SDLC – treat decisioning as content, not as application ‘plumbing’. Frankly, even without any BRMS tool at all, this can still deliver an order of magnitude improvement in development performance. Remove all decisioning into stand alone, discrete components that are owned and managed by the business – period! This improves application design and reduces application complexity by a large margin, and as T Capers Jones [http://en.wikipedia.org/wiki/Capers_Jones ] has comprehensively demonstrated, reducing size and complexity generates a corresponding exponential reduction on development cost, risk, and time.

    We are not there yet, and as you observe, there is still plenty of room for innovation to tame the ‘beast of complexity’. But where will this innovation appear – products, approaches, and/or market practice?