[ubl-cmsc] Use Case Categories: Integration vs. Customization

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

It's my perception from mostly listening to our SC's over the past few weeks
that the primary category of use case we've been implicitly working from is
one where some user wants to craft a new kind of business document.  I'll
call this category of use case "customization".  I haven't heard any
discussion of what I feel is the far broader and more pertinent category of
use case that I'll call "integration".  I just looked at out current list of
use cases and verified that none of them talk about integration.

My understanding of customization would yield a scenario like this.  A
developer needs a brand new kind of business document for a brand new
application (with a brand new trading partner).  That developer uses the UBL
BIE's as a starting point, describes the deltas in terms of context _or_ XSD
derivation, and then presses some sort of button to generate the new
schemas.  Oh and since we aren't going to do "aggregation", the developer
would then I guess write a new schema and import those generated
(contextualized) BIE's in it.

Taking a step backward -- I don't think that the value of our methodology
(CM) has been proven for this kind of scenario.  I was hoping that the
concrete example in the Extensions Position Paper would prove it, but that
scenario hasn't shown up yet.  I guess that's not too suprising, since we
are only beginning to develop use cases.  What might be surprising is that I
don't believe there's any value we _could_ prove.  While I believe that
certain users will derive documents from our BIE starting points, I believe
to prove the value of UBL and more specifically CM we have to look at a
different category of use. 

I think that by far the most important problem to solve is the "integration"
problem.  I also feel that this is where we can actually prove some value to
CM.  Further, I _suspect_ that this is the real problem way back in the
primordial consciousness, that spawned CM.  That's why I find it so odd that
no one has talked about it overtly.  Allow me...

In integration problems there are always at least two parties.  As a
simplifying assumption perhaps we could assume that the parties have systems
in place communicating via (contextualized) UBL components.  Let's
characterize that.  What then becomes interesting, to my mind, is what are
the "change cases"?  This is what I'd like to hear from the domain experts.

For instance, let's say that you've got a driving party (800 lb gorrila) and
it decides to change some structure.  Question for business expert: what
structure are they going to change?  

After that, it's either the case that the change is backward compatible or
not.  In the case of a backward compatible change, participants will
implement the change on different schedules.  What mechanisms shall we
specify in support of that.  In the case where the change is not backward
compatible: what mechanisms shall we specify to enforce that?

Did I miss the memo wherein the integration problem is proved to simply be a
special case of the customization problem?  If so, please point me to it and
my life will get a lot simpler.

My purpose in this rant is to try to narrow the scope of what were asking
for when we go to the domain experts for use cases.  Again, I see great
potential value in integration.  I'd like to focus our effort there.  And
while it is a heckuva lot easier to understand, I see almost no potential
value in customization.  Feels kind of like those keys and that street lamp.
I look forward to hearing your views.

-Bill