[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: What do people really expect from ebXML? - Is CC really a setofLegos?
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"
Powered by eList eXpress LLC