RE: Supply Chain Spec Volunteer

[Todd Boyle]

At 05:47 PM 8/19/2002, Neil Tiffin mentioned,
> I do believe that we will need a business persons view (prose 
> functionality) of the system design.  It does not matter to me which comes 
> first.  But it will be needed at some point.


Neil in case you're interested in the UN/CEFACT half of ebXML,
it is converging more and more around the "UN/CEFACT Modeling Methodology"
(UMM) which has the following chapters

Chapter 1 - Introduction
Chapter 2 - Business Modeling
Chapter 3 - Business Requirements
Chapter 4 - Analysis
Chapter 5 - Design
Chapter 6  - Protocol Specific Standards
Chapter 7 - Requirements and Training
Chapter8 - Metamodel
Chapter 9 - Patterns
Annex 1 - UMM Glossary
Annex 2-9

Those are available at mirrors such as
http://www.collaborativedomain.com/standards/index.htm

UMM is very interesting reading.  It is "stackism" in case
you haven't already had enough stacks, like the OSI stack.
http://www.google.com/search?q=ebxml+stack
This defines a business process layer, which encompasses
the business relationship and model of interaction that
spans time and has a long life.  It observes a collaboration
layer, which observes that a transaction lifecycle usually
has more than one event in commitment, fulfillment,
and settlement.  Then it observes a transaction layer of
course.

The documents are not hard to read; a bit time consuming,
and in my case they burn a lot of paper since I can't study
such big stuff from a screen.   But these docs are really
a kind of ontology works that are fairly inevitable, and are
useful for people like me who would have taken the rest
of my life to figure out a lot of these viewpoints.

At present the work involves expressing the abstract model
in terms of state machines.  In meetings in Seattle this
month the BCP team for example worked on expressing
the artifacts at the transaction level of the software into
the state machine that defines a BSI, a business service
interface (basically this touches messagware or middleware,
telling it unambiguously how the state of higher-level
business objects must be aligned with the state machine
maintained by the trading partner.  Keeping the state of
these two replicated business process models is the goal
of the business process level of the software.

For example, a business transactoin can begin after a lot of
business process context is aligned, getting the batter to
the batter box in a baseball game.  At some point a
commitment is expressed in unambiguous terms the
fullfilment of which can be computable by software. That
is the whole entier point of business process software,
that some unambiguous business entity agreed in a
contract, has proceeded from one state, to the next
state or to an exception condition. etc.

Hope this helps,
Hope I havent' erred to badly in my descriptions,
What this implies, is if you can live with the models and
prescriptions of the UMM you are immediately in the
middle of a larger community, one that is very clueful and
has huge history and experience, and is throwing off not
only a lot of modeling but pretty specific code objects now,
and...  you don't have to write documentation :-)

 cheers!
Todd

By the way, does GNUE have a "stack"?

Here is another "stack" for you,
http://iang.org/papers/fc7.html