Wednesday, June 24, 2009

One model to rule them all... and in the darkness bind them

It seems to be a bit of a holy grail of Service Oriented Architecture, or in fact for any large organisation, to have a single canonical model/form of all important entities to their business.

After watching a colleague struggle with a 900K WSDL that defines something like that (900K of XML !), I happened to stumble across this interesting and amusing blog post: http://service-architecture.blogspot.com/2009/06/single-canonical-form-only-suicidal.html

Quote:
If SaaS is anywhere in your future, and it will be unless you are a military secure establishment and even then it might me, then GIVE UP NOW on the idea that you can mandate data standards in applications and create a single great big view that represents everything.

I have watched organisations spend millions even trying to define what the most "basic" entity looks like: A Customer ! Its hard to even agree on the basics !

So what ends up happening is that some sort of a standard is reached, and projects have to pay an expensive "architecture tax" to use these huge models, fail, and then feel guilty for creating their own little models that at least allow them to build their app.

With modern mapping tech, such as this or this, the cost of mapping between models is much much less, perhaps its less then the tax of using huge complex models? (this is directly relevant to the models that rules use: rules *can* use the canonical models, depending on how complex you want them to be, but sometimes it is clearer to use a model tailored for where it is used, and map to it from the external model).

2 comments:

  1. You make a very good point Michael. As a rules consultant I have seen this behavior over and over again with several organizations. The 'holy-grail' of working with a single view of the world doesn't work, especially so when dealing with rules engines.

    I think the idea of 'mapping models' based on what you need or the system needs, is the key. However, larger the organization the stronger the resistance to it. Nobody knows who is responsible for mapping, however everybody wants to consume the right model and few want to help map the base model to a specific one. Again I have seen this especialy with rules and typical argument given against specific models is 'why should we bother to map back and forth models just for the consumption of the rules, why can't rules just consume the model as it is, which the rest of the system is using'. The ignorance undelying his argument becomes glaringly apparent during the rule lifecycle development and more so when the project reaches maintenance stage.

    Thanks.

    ReplyDelete
  2. Greetings:

    IF we are agreed that the Single Canonical Model is not a feasible model at all and if we are agreed that it is ancient and archaic, THEN what are we do do when the corporate "head shop" - sometimes called a CIO or CTO or some other CxO title, decrees that this is what we have to do? What to do indeed?

    The problem is this: On the one hand, you know that what is happening is wrong. BUT, do you stay and rage against the machine and, perhaps, make some impression on the insanity of your superiors, or do you go somewhere else and be happy, thereby allowing the "machine" to drift into total and utter failure.

    Personally I vote for the latter rather than the former. I've only found one occasion where the "machine" allowed any tolerance to what had always been done. And then, after 18 months and completing the final testing, they brought in a new "Director" who knew nothing about rulebased systems who immediately replaced all of the top technical personnel with his SQL gurus and redesigned the whole thing. They laid off (contractors) or re-assigned (employees) about 183 persons that one day. (Final test was working and completed so the project was, for all practical purposes, finished.)

    The new Director said that he would have it done in SQL in 30 days. It took him another 18 months and the code was so convoluted that no one, including himself and his gurus, could tell you what was really happening. So they ducked the whole issue of having to explaine and joined with another company that had already solved the problem. Then they effectively flushed both projects down the proverbial tubes. Something like $30M plus on the first implementation another $40M on the second was spent because of a change in Directors.

    Sad but true and those who worked on that project will recognize the story. I ask only that you NOT name names at this point because I have some friends who are employees there who are about to retire. Let them retire in peace.

    Oh, what was my point? If the upper management is sold on driving the corporate IT bus off a cliff, tell them quickly and politely that the bus is going over a cliff. If they don't change course, JUMP! Hopefully there will be another job somewhere that won't have you waking up screaming in the middle of the night. But, and this is important, do NOT tell your next employer your real story. You left to take care of some personal family business and now you're looking for another job. (That personal family business was keeping your sanity.)

    SDG
    jco

    ReplyDelete