Wednesday, November 25, 2009

Memories of IT - mid 90's - The IAA from IBM

What IBM had was something called the Insurance Application Architecture, the IAA. They assigned an IAA consultant to work with us, so he came in one day to do an overview. I was really curious how they could have a model that any Insurance company could use, as I had done some models and they certainly looked specific to my company to me.

So, he starts his presentation and gets into some detail and it dawned on me that this was an example of a concept that I had recently been learning about: the IAA was a “meta-model”, a general model that can be used for modeling something specific. In fact, it was a meta-meta-model, maybe more “meta’s” than that. So, about 20 minutes in to the presentation, it burst from my lips, “aahh, this is a meta-model…”. My VP and others in the room said “what?”, but the consultant said “Yes, you’re right.”

Apparently they had worked with about 20 client companies for many months in Brussels to come up with a data model and a functional decomposition. The decomposition looked reasonable, and had business words, but the data model entities and attributes seemed to have no insurance words. That’s because they had seriously generalized the “things of interest” such that a major part of the model would actually be used to define the business, with the rest used to actually capture data. I remember one subject area was Agreements, which would be used to define what your insurance products, but could also be used for any legal agreement. This was also the first time I saw what we now know as a Party model, a meta-model for defining customers and other business participants,

Because the model was general, it came with syntax for defining what data would be needed to do things like define a Product. It was at this point that my brain rebelled. I am a pretty Conceptual/Logical thinking kind-of-guy, but this was just too much. However, my co-worker who did tech support for IEF grokked it completely, so he and the consultant would sit in a room and spin out this syntax, and nod at each other and agree on stuff, and I would be in the room nodding like I knew what the f&%k was going on. I was worried, what if I never “got it”?

Skipping ahead a bit, IAA started being used for that Agent System. I had done data modeling with the business people about this just before IAA had been bought. The consultant and our IEF guy started holding meetings with these business people, and I joined the first meeting a few hours in, and the whiteboards and flip-charts were filled with the IAA syntax. One of the business people, a great guy, turned to me and said “I like your models better”. I felt a whole lot better.

In the long run, I need not have worried, as management totally blew the implementation of IAA. It was a general model, and very big, so its was recommended you start with a basic subject area like Party, and implement and start cutting your existing systems to start getting Customer data from the new Party system. It did not work well for doing a specific line of business or function, because you would have to use almost the whole model right away.

However, after evaluation and purchase of IAA, our VP sat down with the IAA consultant and said “OK, start with Agent Management and Compensation”. The rest of us meet with the consultant directly after this, and he holds us to secrecy to tell us that he recommended, even pleaded with the VP, not to do this, but she was adamant. So, that was that and those IAA modeling and syntax sessions began.

Now, doing this kind of modeling and analysis should likely have me involved, but I managed to avoid it somehow, it just seemed to default to the two other folks to do it. There were other projects going on, as usual, so they kept me occupied as well. I know that the IAA project did get to our tech guy writing some Action Diagrams and database generation in IEF to support party and agreement, but it stalled. I was still keeping up-to-date on the progress, as I still wanted to be able to learn and do this if it was going to stick around. What became apparent to me the doing analysis using a meta-model was next to impossible. If the model did not have business words like Customer or Policy, the business people would not get it and could never validate it. My recommendation was to do the analysis using logical models to capture the business requirement. It was true that systems built from such models would need to be changed whenever the business changed, and the power of the meta-model is that you make such change by changing data, not code. …But people can’t think ‘meta’’, so do the analysis logically, get it approved, then generalize it to the meta-model for use in subsequent development. My belief was that IBM should be able to build something that would take a logical model and generate the IAA syntax to use in the IAA model.

Unfortunately (again) for IAA and IEF, the overall desire to replace the whole CLASSIC system had reached fever pitch. One day, we heard from the VP of Individual Insurance that a package had been bought to replace CLASSIC and would also do Agent Management and such. So, that was the end of IAA.

2 comments:

Patrick said...

David, your story validated some of my thoughts regarding IAA and its meta model. I particularly like the idea of using a standard logical model with the business and map the logical model to the IAA meta model. It creates another level of models to manage but provides the business a greater opportunity to participate in the analysis for the project.

I would be interested in connecting with other people who have worked with IBM's IAA for a custom software development project.

Frederic Dutreuil said...

Dear David,

The good news is that there is now a model dedicated for insurance which is not a meta model and has been successfully used to develop many applications across the world. Please have a look at Prima IBCS from a company called Prima Solutions (www.prima-solutions.com). Some more, it is the model underlying the ACORD Information Model!
Frédéric

About Me

Ontario, Canada
I have been an IT Business Analyst for 25 years, so I must have learned something. Also been on a lot of projects, which I have distilled into the book "Cascade": follow the link to the right to see more.