Genuine interoperability & the tower of Babel

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 Monday, 22 September 2003 21:40:13 UTC