RE: What do people really expect from ebXML? - Is CC really a setofLegos?

["William J. Kammerer" <wkammerer@foresightcorp.com>]

Phil Goatly thinks that if you build the processes top-down, and the
data bottom-up, "there is a problem since it is like trying to construct
a tunnel from 2 different ends, and since at the start it is difficult
to ascertain the middle point - or even the direction - there is little
likelihood that they will meet."

And as I said or implied yesterday, I agree that something like Bolero,
with multiple stages of completion that must match real-world events
between multiple partners  (shippers, carriers, importers, banks and
what-not), data (message and Core component) design might be dictated to
some great degree by the business process in a top-down fashion.   Or
something to that effect: I have trouble saying stuff like that with a
straight face.

There are varying degrees of influence that the external business
process between partners has on the design of messages within a
transaction.  If Bolero were the extreme case (of process dictating
design), then things like Just-in-Time manufacturing or Health care
claims might fall in the middle. But many, if not most, examples fall at
the other extreme.  Bear with my story:

I just received a notice from the Ohio Bureau of Motor Vehicles saying
they were conducting a random check to ensure I had liability insurance
coverage on my jalopy. Most, if not all, U.S. states have some sort of
Financial Responsibility Law, requiring drivers to have some minimal
liability coverage.  Ohio seems to have kind of a random enforcement,
where you pretty much only have to have insurance coverage at the time
you're stopped for a traffic violation, or when you get picked for one
of these stupid audits. I imagine many people drive for years without
insurance and are not caught.  And then there are those who could lose
their license simply because they didn't return the audit form and
insurance registration.

This seems to be an application that screams out for automation.
Hello??? - like maybe it would be possible for the (few) insurance
companies to tell the (few) states when someone became insured, renewed,
or  terminated coverage, and details of the car and policy.  Not only
would (millions of) individual motorists not have to be bothered to
provide proof of coverage, but the clear intent of the legislature -
that every vehicle registered in Ohio be insured all the time - could be
enforced with some reliability.

Our state motto may be - for the time being - "With God All Things Are
Possible" (Matthew 19:26), but that apparently doesn't apply to the Ohio
BMV.  I suppose with a clumsy hit-or-miss system based on paper, the
political hacks at the BMV can ensure plenty of jobs for their cronies,
even though ASC X12N has put together an 811 implementation guideline on
Automobile Liability Insurance Reporting for this very purpose!  See
http://www.wpc-edi.com/Property_40.asp.  The 811 Consolidated Service
Invoice/Statement may not really be the best message for implementing
this function, but that's not the issue here.

The X12N guideline shows "Information Flows," or what loosely might be
considered the "business process models":

    Reporting Process:
             State Agency ----> Insurer

    Verification and error process:
             State Agency <---- Insurer

That's about it... and I don't think I would've been able to add that
much more to the mix.  Now that we have that out of the way, it's clear
we're not going to have much luck designing the business message - or
the core components -  of this sucker based solely on some "top-down"
"gap" analysis of the "business model."  And where does this vaunted
"context" fit in?

But the X12N guideline does list a couple dozen data elements which
conform to a common-sense notion of what would have to be transmitted,
concerning the insurer's name, address, contact information  and ID
number, the insured's name and address, coverage period, policy number,
and vehicle description, license and ID (VIN) - pretty much everything
that was on the piece of paper I had to copy for the state registrar.

There really is no "business process" to speak of between the partners,
and certainly the insurance company doesn't give a rat's ass about the
*internal* business processes at the State of Ohio, and vice versa.
It's just a matter of the insurance company reporting current
information on their policy holders.  And so it's the design of that
policy information, as a data model, which is important to get straight
so the same message template or schema (or IG, in EDI parlance) can be
used by any insurance company reporting to any state (or province).

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"accelerating time-to-trade"