RE: Genuine interoperability & the tower of Babel

Not quite sure I understand why WSA can't deliver. The plumbing is, as
you point out, the necessary prerequisite and it enables data to be
exchanged between separate  - and previously incompatible - systems. And
it provides standard ways for services to find and communicate with each
other. 
Of course, it doesn't solve all the problems. Now, it is a fact of life
that people speak different 'languages' and even worse, a certain word
may have different things to different people even when the language
they use is the same. That doesn't necessarily, mean that they cannot
communicate with each other and have a meaningful dialogue. The key here
is in translating the 'data' exchanged so that it makes sense in the
other's frame of reference. That is a real challenge, I agree.
The company I work for is being transformed from a decentralized
organization to more centralized one using common standards and best
practices. Sure, some items have completely different names, part
numbers and sometimes even different meanings in different parts of the
company. 
But here we are talking about the data itself, its transformation and
cleansing and we are also talking differences in processes (an order can
have different perquisites and components in one part than it has in
another). Coming up with these transformation rules is the harder part,
sure, but not doing is not an option.
Maybe after having the plumbing in place people will start to wonder why
they are doing things differently then the other guy, so maybe we are
lucky and some 'harmonization' will take place automatically.

Cheers
Oliver 


-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Frank McCabe
Sent: mardi, 23. septembre 2003 03:40
To: www-ws-arch@w3.org


I have been a little uneasy for a while about certain aspects of the 
direction that the WSA is taking. This note is an attempt to express 
this concisely and hopefully to suggest a route forward.

The current WSA is, somewhat consciously, founded on the principle that 
the application writer has most, if not all, the 'rights' in designing 
a system. In this case, by application writer I mean the collective 
group of people who are designing a particular Web services 
application. Of course, there are constraints, which mostly arise from 
the mechanics of getting Web service agents talking to each other.

My concern does not lie in the plumbing.

Imagine a scenario a few years down the road where two corporations 
have developed and deployed their Enterprise and/or supply chain using 
the latest of Web service technologies. (By latest, I mean technologies 
based on specs we can see coming: SOAP 1.2, WSDL 1.2, OWL 1.0, WS-CDL 
1.0, BPEL 1.2 etc. etc.)

One of these buys the other, and now these two systems must work 
together -- or some shareholders are going to be upset, and the CIO 
will lose sleep.

My question is, in what way, other than with the necessary but tedious 
plumbing, will our specs have helped that scenario. My fear is that we 
will not have helped enough; and by extension, Web services will not 
deliver on the promise.
The issue is that some of the hardest problems with this kind of 
integration don't come from the plumbing but come from silly but 
devastating dissonances such as incompatible dates, different names for 
slightly different parts, and different names for slightly different 
functions.

For example, A inc. may require that a PO be "requested", and B inc. 
may require that it be "authorized". While A inc and B inc were 
separate, this wasn't an issue, but as soon as A buys B, then this 
becomes a problem.

Related, and perhaps more realistic, are cases where 'vertical' supply 
chains have to be merged. A used to deal with A*, but now A gets to 
deal with A* and B*, and B similarly with A* and B*. There though, we 
are not simply adjusting two systems but 2N systems, belonging to 2N 
companies.

The tower of Babel referred to above is the huge number of 
application-specific systems that can't leverage each other because of 
trivial but lethal incompatibilities. There has to be a better way.

Before we look at solutions, it is helpful to see that there is a 
problem. Is this analysis off the mark, and if so, why?

Frank

Received on Tuesday, 23 September 2003 14:18:48 UTC