xml-dev - Re: Dissillusioned about interoperability.

[Eric Bohlman <ebohlman@netcom.com>]

On Thu, 7 Oct 1999, Kent Sievers wrote:

> I am working on a project that is heavily involved with trying to make sense out of data from multiple outside sources.  Years ago when we started out we had our own proprietary way of representing "documents", and had to convert the different formats into ours in order to consume them.  When we first heard about XML we got very excited and have been using it now for quite some time.  But looking back, I have trouble seeing what it bought us.  I will try to use a simple contrived example:

The reason XML seems not to have bought you anything is that it's a
technology, and as such is only capable of solving technical problems. The
problems you have, OTOH, are essentially social and political problems
that only look technical.  Without knowing more about the inter- and
intra-organizational relationships involved, I'm guessing that one of two
things happened:

1) Failure to achieve true "buy-in" from the players involved.  Their
reactions look like a classic response to a "BOHICA"--an
externally-imposed mandate with no perceived benefit to themselves.

2) Failure to communicate requirements in adequate detail, which is
usually the result of failing to fully analyze the requirements oneself
before impos^H communicating them to others.  If you tell a bunch of
outside sources "we want our data in XML format now" (leaving the people
who have to actually implement the data production with the impression
that you don't know much about XML other than that the press says it's the
latest "killer app") and leave it at that, everyone will try to figure out
what you mean, and they'll each wind up with a different understanding.
"Figure out what I mean and just do it" simply doesn't work across
customer boundaries, whether internal or external.

Did you ever get representatives of your various data-generating
organizations together with your own people to *jointly* hash out
everybody's requirements and then come up with a specification (the
requirements really do need to be worked out jointly, as they're more
socio-political than technical; once they've been put down in detail and
bought into, the translation to a spec can be done by one person or by
representatives of only one player, as that's much more a pure technical
endeavor)?  Without such a process, the only other way to get a uniform
data format is to create it in-house, spec it out in *excruciating*
detail, down to the level of allowable positions for line breaks, amount
of indentation to use, etc., and then inform your sources that they either
observe it or quit doing business with you, and hope that they're staffed
with drones who don't know the techniques of "creative rebellion."

It sounds like there were mismatches between what you wanted and what
their systems were capable of generating easily, and that those mismatches
became apparent only *after* the new system was put in place. This is an
absolutely classic project-management failure mode, and it's almost always
the result of cutting corners somewhere.  No technology can solve it; the
best a technology can do is help you work around the after-effects of such
a failure.  Back in the 1980s some rather forward-looking people in the
basically backward-looking US auto industry set out to gather and analyze
real data in order to figure out why the Japanese auto industry was able
to produce cars at much less cost.  One of the things they discovered was
that the costs attributable to engineering changes were far lower for the
Japanese companies.

They briefly considered that maybe Japanese engineers were just smarter,
better educated, etc. than American engineers and therefore came up with
fewer changes, but they stuck to their philosophy of only looking at real
data rather than speculating, and they discovered that the Japanese
companies were making *more* engineering changes than the US companies!
They scratched their heads for a while, looked at more data, and finally
came up with the answer to this seeming paradox by doing plots of
engineering-change frequency vs. product lifecycle stage.

It turned out that the Japanese companies were making most of their
engineering changes very early on in the product-development cycle,
whereas the American companies' engineering changes peaked in the early
phases of production, right *after* all the tooling had been ordered,
production lines committed, etc.!  IOW, the Japanese companies were
putting more effort upfront, when engineering changes were cheap (a few
hundred dollars each) to make, while the US companies were itchy to get
production started as quickly as possible (probably to impress Wall
Street) and deferred a good chunk of the engineering effort to a point
where changes were expensive (millions of dollars each) to make.

(Legend has it that Detroit was full of tool-and-die companies who, when
one of the Big Three ordered tooling for a new model, would supply it
almost free, knowing that a few months later the manufacturer would be
running to them looking for revised tooling on a need-it-yesterday basis,
at which point the tooling companies could charge whatever they felt
like).

This is one of those problems that looks boring and trivial
from a nerds-eye view, and therefore tends to get glossed over by nerds in
favor of purely technical issues, but it's a real, *social* problem that
requires hard work on the part of all the parties involved.  It ultimately
comes down to realizing that technology is a means, not an end, and that
it's a means to the ends of the internal *customers* of IT, not the ends
of IT itself.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)