William, I've already started this effort in my message last weekend in which I asked participants to begin describing the various scenarios. Other efforts already initiated by me were the various messages about formally beginning to specify requirements so that those who develop the formalized specifications that are the end work product of this effort can ensure that the resultant specifications satisfy those requirements.
Gathering this information is part of the initial tasks of any process analysis. This information then results in formally described scenarios from which use cases are determined. This information gathering (process analysis) then results in various UMM/UML artifacts, such as use case diagrams, collaboration diagrams, state diagrams, among others. This formalized documentation of the knowledge represented in the UML is then validated by the subject matter experts, who are the participants and contributors to this work effort. One does not start a process analysis effort by rushing to create diagrams. The diagrams using the UML are the formal documentation of the information gathered from the subject matter experts. On another topic....if the CPP/CPA specification does not currently support the requirements of this effort, then the logical next step would be for us to take those new requirements to the OASIS Technical Committee, headed up by Marty Sachs of IBM, responsible for the CPP/CPA specification for consideration and addition to the CPP/CPA -- rather than going off on another tangent and re-create something else. This process is not different than the process X12 Committee operates under for requesting modifications to existing standards through a data maintenance request or a new standard via a project proposal. Rachel Foerster Rachel Foerster & Associates, Ltd. Phone: 847-872-8070 -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 6:00 PM To: WEDi/SNIP ID & Routing Subject: Re: UN/CEFACT's Modeling Methodology (UMM) Rachel: If you're willing to (start the) model, using the UML/UMM methodology, on something like Dave Minch's Information Flows (which I found readily understandable even if they weren't expressed in UML diagrams), then I'll pay attention. Someone has to get us started using the UMM, and it may as well be you - its principal advocate - to show us its benefits. Likewise, I would expect Kepa to "take a stab at stating the requirement [for the Domain Name Service] concisely, clearly and succinctly" - it was his idea and he's best suited for articulating it. Similarly, Dick Brooks proposed using the CPP as a Trading Partner Profile, as was done for OTA. I would like to see him take a stab at that one.... though I suspect the existing CPP cannot practically represent the (expected) various transport protocols used for EDI (e.g., Kermit on Dial-up) or the HIPAA EDI capabilities of a trading partner - but I'm "all ears," in any case. And I would really love to see what Dave Minch can come up with using the 838 Trading Partner Profile! I wouldn't have thought there was enough detail in the 838 to satisfy our requirements (and being techy, I wanted to try out XML) - but what the heck: we should eat our own dog food, if that's possible! Thanks, Dave. I'm surprised anyone could have excavated enough proof that 67 to 75% of IT Projects fail (due to failure to analyze, establish a strategy, plan, manage the plan, or otherwise) - what executive in his right "corporate" mind owns up to failure? And besides, there's no failure in the corporate world: they just say the project "no longer melded with our strategy," or "expectations changed post-Sept. 11th." Projects (internal IT or standards efforts) fail mostly because they're stupid or pointless, completely devoid of any vision as to why anyone would want to bother attempting them - not due to any lack of methodology. Good ideas, no matter how complex, have a way of getting done (even if you have to cobble them together with Javascript, Active server pages, or - Lord forbid - EDI!) if the vision is clear. Remember when President Kennedy thrilled us (well, not me - because I'm way too young) with his vision that "by the end of the [1960s] the United States would land a man on the Moon"? Sure, he had to bounce ideas around, running them up the flagpole to see what stuck, before the vision was completed with ".... and return him safely to Earth again." In 1969 Kennedy's vision came true, even though there were a few pitfalls along the way. Everyone could see that it was a neat thing to do - though they were too polite to say the real reason was that if you could land a man on the Moon, you could lob an ICBM at Moscow. I don't know if they used UML, though. William J. "Pollyanna" Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Rachel Foerster" <[EMAIL PROTECTED]> To: "'WEDi/SNIP ID & Routing'" <[EMAIL PROTECTED]> Sent: Thursday, 14 February, 2002 02:22 PM Subject: RE: UN/CEFACT's Modeling Methodology (UMM) William, You're correct that these documents are available from the TMWG web site. However, everyone should know that these are still working documents. It's for this reason that I suggested taking a look at Chapter 1 only. I'm also quite dismayed and disappointed by your obvious disdain for a disciplined and rigorous approach to analyzing a process and determining requirements....this attitude only serves to further confuse this effort and suggest that a methodology and approach that is not only endorsed by the leading standards organizations in the world: X12, UN/CEFACT, OASIS, OMG, ISO, to name a few, and is used by the world's leading ISV's (IBM, Sun, the RosettaNet consortium, Intel, webMethods, SeeBeyond, Vitria, the automotive industry, etc.) is useless and not worthwhile. I totally and emphatically disagree with your statements and position on this issue. Why on earth would you encourage this group and health care in general to not adopt this approach but to go off in a fragmented and ultimately potentially an ineffective effort? Over the last couple of years several surveys have been conducted by The Gartner Group and the Boston Consulting Group as published in COMPUTERWORLD March 27, 2000, to better understand why IT and/or eCommerce projects and efforts do not succeed. The results of both surveys can be synopsized as follows: 67 to 75% of IT Projects Fail due to 1. Failure to analyze 2. Failure to establish a strategy 3. Failure to plan 4. Failure to manage the plan To state this another way: Only 1 in five IT projects succeed, and the characterics of successful projects include the following: 1. Up front assessment & analysis 2. Well-thought-out business strategy 3. A focused project plan 4. Effective management of the project plan 5. An understanding of the various technologies to be exploited I certainly hope you'll reconsider your attitude and position. Rachel Rachel Foerster Rachel Foerster & Associates, Ltd. Phone: 847-872-8070
