[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [regrep] V3.0 of ebXML for SOA (SOA-NOT)
David,
Is there any room in ebXML-Land for someone that is not wedded to the notion that a web frontend solves all problems? I have seen some really nasty backend systems that were impossible to partition and/or scale. I have worked with networks that very overloaded and resource constrained. Is there any room for “an ebXML Registry-Lite” and/or “Nomadic Application Support?”
Zachary Alexander The IT Investment Architect ebTDesign LLC, (703) 283-4325
-----Original Message-----
Duane raised some interesting points that I'd like to focus on - in regard to - creating a new 3.0 release of ebXML.
My biggest departure point is around the single issue of a perscribed architecture as opposed to a suggested architecture.
I believe that trying to force certain technology components down peoples throats as "you must have this to be ebXML compliant" is a serious mistake - and especially in the area of payloads.
One of the reasons payloads were never perscribed is exactly that.
The great strength of ebXML is that you can eat just the pieces you need.
Next up - Registry and CAM components offer a phased approach - that is based on sound business ROI to discreet problems - around information alignment and interoperablity.
Now - if people discover they really can save money and work more efficiently by using your technology - you will not have to force them to use it - they will come to it themselves - and that's essential longterm.
So - again - its comes back to - articulating where those ROI factors are - from a business-centric view - and that is what we need to spend our effort on IMHO.
As for the SOA fit - yes - we do need to make sure that SOA literature includes ebXML components as options there - and so again - the value proposition needs to be made at that level. But its not a case anymore from the technology level of saying "you must have this to have an SOA" - as UDDI found out - that dog does not hunt.
Identify the business needs in a replicatable and formal way - and the technology to accomplish that will then make sense for people. Again the OASIS BCM TC is focused there.
The platform for "ebXML Architecture" may actually be a losing proposition - and instead just perpetuates the notion of SOA v ebXML - whereas if the effort is
"ebXML V3.0 for SOA"
I think you have a much much stronger message that all the TCs can signup to - to make sure their piece of the pie makes ebXML for SOA a compelling business success.
Cheers, DW. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]