[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Re: [ebxml-dev] P2P for e-business -applications?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]