RE: [ubl-dev] Re: [ebxml-dev] P2P for e-business -applications?

["Stephen Green" <stephen.green@bristol.gov.uk>]

Hi Roger

What you suggest in terms of an analogy to credit card
products and services is of course still reliant on a third
party - the banking agency.

Maybe this aludes a bit to a banking agency providing the
subset/customisation and process profiles and maybe too
a default CPA template.

We tried doing this from a community/public body stance but
it looks like it may well be taken over by organisations close
to the banking industry.

Whichever organisation or person provides the technology
standards and profiles it looks to me like product developers
need a way to just drop the output of the trading party
agreements (in your analogy that would be merely the credit
card product type selection but in B2B that might be a CPA,
a subset profile - say a CAM template - and a process profile
- say an ebBP definition instance) into the respective product
and convert that into the necessary set of configurations and
maybe registry entries.

I guess it's worth thinking about developing tools to better
support all this and maybe piloting some proof-of-concept
implementations and interoperability evaluations. Of course
ebXML has something well matured in this area with regard
to use of ebMS. Maybe now that the ebXML IIC nearly has
completed profiles and there are also profiles coming out for
UBL like UBP, SystML1 and SystML2, NES and UBL-like TWIST
(? need more info on this), maybe now the time is right for
someone (as Drummond did for ebXML) to devise some
interoperability testbeds. I just hope things don't stall before
this can happen. Maybe it needs some government and/or bank
backing. It would be nice though to get as many countries and
regions invloved as possible, perhaps industries too.

All the best

Stephen Green


>>> "Roger Bass" <Roger@Traxian.com> 04/04/07 07:50:57 >>>
Stephen,

Well, ok, so collaboration's potentially interesting - still not
convinced that P2P or any other one specific underlying technology is
required to make that happen.

But there's a bigger problem - the scenario you describe contains two
things each of which is hard on its own, and extremely hard to the point
of implausibility when you put them together.

First, you describe the exchange of standardized messages to configure
the end-point systems for B2B. The big problem (especially with SMBs) is
that virtually none of the real business systems SMBs use have any
notion whatsoever of sending/accepting any such standardized messages to
configure an exchange. Even the more basic need of just getting a PO or
invoice document in or out is a challenge. And even where it's possible,
it's going to be in whatever legacy format they happen to support, not
any "preferred standard" document. So given this environment today, the
exchange of standardized B2B messages from peer-to-peer adds relatively
little value, to the extent it ignores the more important job of
actually integrating those messages with the existing systems.

Secondly, you talk about "clerks" customizing the setup of business
processes between the two businesses, with the notion that those
customizations will flow through and be understood and supported by the
business systems. This may not be far-fetched in the context of ebXML
CPAs, but it's fairly far-fetched given real-world SMBs, their systems,
and their people. In reality, what I see with our customers is each SMB
having its own internal process - and yes, wanting some degree of
customization to fit with that. But this is first about them, and second
about partners, who they ideally want to all look the same as far as
possible. In other words, it's more of a one-time setup as to what they
want and support. It's certainly not end-users negotiating case-by-case
with partners. The better analogy would be a merchant posting on their
storefront that they accept Visa, Mastercard and American Express.  A
shopper with Discover and Amex then decides which card to present, but
it's the same payment process for the merchant. That's more the
negotiation.  In our context, I expect mostly that this negotiation
would be automated based on the capabilities and preferences that each
party has expressed to set up the electronic relationship accordingly.
So here, even the experience of each party is some way from the
"collaborative" process you envisioned. (And even that more
collaborative process you describe fits P2P less well than you suppose,
given the first point about the constraints of dealing with the internal
business systems).

BTW not sure where your last comment came from. I'm not saying there's
not value here. There's huge value... in actually solving the problems
that SMB users care about, and applying appropriate technologies to do
so. As technologists, it's very easy for us to fall into "man with
hammer seeing all problems as nails" way of thinking... especially in a
group like this that's defined by technologies. The only value in P2P
(or standards, or any other technology) is enabling solution providers
to incrementally reduce costs.

As to expense... well yes, it does take effort to make this work, but
there are consulting business models, and mass market product models.
Despite our similarities, David and I have different business approaches
that affect what customers do and don't end up paying for.

Best regards,
Roger



-----Original Message-----
From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk] 
Sent: Tuesday, April 03, 2007 10:25 PM
To: ubl-dev@lists.oasis-open.org 
Subject: RE: [ubl-dev] Re: [ebxml-dev] P2P for e-business -
applications?

Hi Guys

So it looks like it is still on the horizon, albeit
with some vendor reluctance, then.

I could imagine it being very useful for situations
where there is collaboration needed: you mention the
problem there is in parties agreeing business processes
and I'd add to it agreement of the constituent parts
of a document (customisation as UBL calls it). Maybe
products will one day use IM or the like to provide
collaboration; like chat but more structured and
controlled, point-to-point, clerk-to-clerk as it were.
This could result in configuration of both systems for
the subsequent B2B. It's not so far fetched when you
look at the negotiation of CPAs in ebXML.

So what's the point of point-to-point? :-) Not much
more than allowing collaboration in real time. In B2B
I'd regard that as imperative for trading agreements
but not necessarily for the business itself. But if
it is provided for agreement resolution then why not
allow it to be used subsequently for the business
itself.

But all this talk of expensive development just makes
me think there must be more value in doing it than you
guys say or you wouldn't be talking about it still :-)

All the best

Stephen Green



Quoting david.lyon@preisshare.net: 

> Quoting Roger Bass <Roger@Traxian.com>:
>
>> Stephen, David et al,
>>
>> I'm jumping into this thread a little late...
>
> no - unfortunately it is still an ongoing thing...
>
>> This technology discussion all misses the point. From a pragmatic
SMB's
>> perspective, all they care about in this context is interconnecting
>> their business processes with one or more of their trading partners -
>> and having that be easy and inexpensive enough to be worthwhile, in
the
>> context of the overall business relationship. (The paper you link is
>> quite flawed in its most basic premises and approach, IMHO).
>
> Pretty much. I'd second that.
>
>> Don't get me wrong - I'd love to have a technology that could do at
>> least some connections P2P, and would do it for free.
>
> I think that there's a lot of talk and promises about this in the
> marketplace. But it usually comes down to it needing some (quite)
> expensive programming being done in an outsourced setting. It starts
> off with the promise of cheap... but ends up being more costly than
the
> clients could have ever imagined because you end up having to provide
> on the job training for the programmers even though you are being
> charged full market rates.
>
> It's interesting to pick up the pieces anyhow.
>
>> In fact, I expect we will end up doing P2P in future - but only
>> once we have a big enough group of SMBs connected to have a stable
set
>> of end-to-end process requirements. Then and only then will we (or
>> anyone else trying to do this) be able to deliver a P2P product that
>> actually works.
>>
>> There are no short cuts here.
>
> I think that's what a lot of us are trying to do. Sounds like a
> familiar soapbox anyway.
>
> Regards
>
> David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org 
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org 



---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org 
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org 


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org 
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org 

______________________________________________________________________
Please note the new simpler name for our website: http://www.bristol.gov.uk 

Our email addresses have also changed - visit http://www.bristol.gov.uk/bigchange for further details.

Sign-up for our email bulletin giving news, have-your-say  and event information at: http://www.bristol.gov.uk/newsdirect 



______________________________________________________________________
Please note the new simpler name for our website: http://www.bristol.gov.uk

Our email addresses have also changed - visit http://www.bristol.gov.uk/bigchange for further details.

Sign-up for our email bulletin giving news, have-your-say  and event information at: http://www.bristol.gov.uk/newsdirect