Re: Dissillusioned about interoperability.
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format