ACORD is a Guideline NOT a Standard

Apologies to my readers who are not in the insurance industry and do not care about the ACORD XML "Standard". I have gabbed a lot about it lately. Perhaps this applies to other "industry standard" xml efforts. I know that it also applies to my experience with OAGIS. I also recently posted on canonical message format as well (related). I hope that this post and the comments that may ensue will put this topic to bed for a while.

While at the ACORD conference last week in Las Vegas, I challenged myself to interrogate every vendor, carrier, and ACORD employee on whether ACORD is a standard or a guideline.

To a person the consensus was that it is a guideline.

Perhaps I am just a stickler for words, but this really bothers me. I listened to executive after executive and industry analysts yapping and banging drums about "standards" and how everything is just great in the insurance world on the wire. I listened to the Gartner insurance dude spaz out about ACORD "standards" and then recommend that carriers fork it (excuse me, use ACORD as a guideline) in one sentence. The insurance analyst panel (Gartner, TowerGrouup, Celent - liked their guy Matthew Josefowicz the most)) was pretty comical - one of the more arrogant groups I have seen. Sniping at each other, challenging each other to dare to question the standards -- saying things like, "the standards have never been as close as they are today ...". They certainly all know more then I do about the insurance business, but someone needs to remind them that their PowerPoint presentations don't compile. They should take a look beneath the covers of a couple SOA projects and check to see what is really on the wire.

I talked to several aggregators and AMS reps who said that in their eyes ACORD is at best a guideline. They did say that since carrier xml is often ACORD-like and at least has some similarities, it makes things better then if everyone started from scratch. I can buy that - but that isn't standard.

I listened to a presentation from a reinsurance intermediary (Guy Carpenter) on an event driven impl. They forked the ACORD standard and have no regrets. By the way that was the best presentation of the show (even though it was called "Using ACORD XML Standards to Build Enterprise SOA"). I have a feeling that the presenter, Paul Fox didn't name it that.

I challenged some CIO level folks who were talking the standards bit. They quickly folded and agreed with me.

What bothered me the most about the ACORD conference was that there was no serious discussion about the realities of ACORD XML in practice today - no sessions, no critical thinking - zip. Everyone just seemed to wink and nod and say nice things about standards. Also, zero talk about 2.0.. Perhaps I just wasn’t in the right sessions.

Every sane person I spoke with is following the prune strategy accepted in 2.0.

I still believe that it is appropriate to use the ACORD guideline as an starting point for a insurance entity's canonical form - provided it is aggressively pruned and there is no requirement to keep up with future versions of the ACORD guideline. Most importantly, don't spread the illusion that your canonical form is "standard" -- that there will be some magic interop some day. There will not. This is ok. Owning your canonical form outright is far more important then conforming to a standard that doesn't really exist.

ACORD Conference - lots of vendor-pires & some that get it

Wow, lots of vendor-pires large and small here.

I had dinner last night with some folks from Skywire Software - we use one of their products, Insbridge.

What I like most about them is that they aren't a vendor-pires and aren't trying to be. They are SOA based and stay out of your way. I wish there were more vendors like this - that just offered service based software.

Instead, every vendor seems to want to invade your whole stack. I met with a couple of these vendors yesterday and told them straight - "I would never buy this - it will lock me in and make me miserable". Most of these vendors have crazy GUIs and scary proprietary scripties that are intended to make your life easier. "Easier" sadly also = lock in and esoteric skills that few developers want to acquire.

IMHO, SOA strategies that rely on lots of extensive clickie tool support are doomed to failure. Or at least lots of bites from various vendor-pires. I'm all for tool support - just not invasive tool support. As long as the tool isn't generating files with weird file extensions and isn't required to build a service, you are probably ok.

Insbridge. does have a clicky tool, but the way you call it at runtime is via a service. So the clicky is useful and contained - that works for me.

Update 17-JUL-06 - Now that it is possible to determine my employer by reviewing my blog posts, I must follow my employer's blog policy.

This is not an endorsement by Liberty Mutual, but my personal view. Vendors are NOT free to quote with attribution.

ACORD Conference

I, standards basher, am at the ACORD LOMA Insurance Systems Forum in Las Vegas.

The conference really starts tomorrow. I went to a technology forum run by insurance agents. It was fairly interesting. I have gone to several agencies and watched these people work. As the saying goes, "they don't call them independent agents for nothing". They all do business differently, use different tools (agency management systems (or none at all), aggregators, etc.), yet they want everything integrated and simple. Makes my life fun, what can I say.

At the agency technology forum, the word "standard" was tossed out there quite a bit. I kept muttering to myself, "what version?", "who's extensions"?

I had an interesting conversation with one of our aggregators in the conference hall. An aggregator is used by insurance agencies to do comparative rating. Basically, they just type in an insured's info once and click one button and get back rate quotes from N carriers (think Travelocity with airline tickets). If anyone should be benefiting from the industry standards that we all say have such a high payback with no questions asked, it should definitely be him. Guess what he told me? Every carrier that his system integrates with uses dramatically different XML on the wire. There is no "standard" XML that they send to each carrier.

Now I found that pretty funny.

He did say that it is nice because each carrier's XML has some resemblance, but then conceded, with some prodding, that the whole thing is b.s.

Anyway, I still hold out a slim bit of hope for Acord 2.0, but time will tell.

Don't get me wrong on standards - I think they are fine. I just get miffed when people blindly cite them as a panacea when I know under the hood what is going on isn't standard. I think we might get there someday with Acord XML - it just is going to take a long time IMHO.

Canonical Message Format and XML Schema

I have lived with and without a canonical message format on messaging projects. I think that they are absolutely crucial if the project is going to survive and be extended over time. If its just a one off integration that uses messaging, I guess you could get away with hacking the message format, but even then, I'd be leery as business who experience message based (i.e., SOA, event based integration etc.) tend to get hooked on the concept once they understand it and want to grow/reuse services. When XML is your message body, XML Schema is the natural choice to define the canonical message format. Different industries tend to have different industry standards for helping to define the canonical message format for a given business. I'm simply astounded at how unusable these industry standards are. I have found that the standards bodies don't take usability of these standards into account. Using any of them out of the box is simply out of the question typically. But I've seen companies try over and over again. Eventually, they all drift from the "standard". Sadly, their canonical message format often drifts too. As the company forks from the industry standard schema, they don't write and enforce their own. Instead, the schema ends up being held within the code of different services and in the minds of the developers of the services. This scenario leads to a lot of problems. Try testing a canonical message format like that. Try bringing new developers on board. Try extending your SOA/ESB, etc. etc. A canonical message format is the key stone to a successful SOA/ESB. I have had success using XML schema to define the canonical message format. The teams I have been on typically start with an industry standard and then dumb it down dramatically. Sadly, the writers of the industry standard schemas typically put every feature of the schema spec including the kitchen sink in their schemas. Try running that through Castor, JAXB, XMLBeans, .NET xsd.exe. I think good tool support is crucial as well. I mean if you are going to go to the trouble of writing the schema down down you want it to help you develop your SOA? Afterall, XML Schema really is just an IDL. Why shouldn't you expect tool support? Anyway, this is a rant I guess. But my advise on canonical message format is: 1. Get one 2. Make sure that there is tool support for your format (e.g., JAXB, Castor, .NET xsd.exe) 3. Do not under any circumstances compromise your canonical message format for a quick hack. 4. Nurture it