SOAP and MQ
You don’t need to be particularly technically proficient to know that SOAP and MQ are compatible solutions to related problems. That our vendors chose to spend hours arguing the relative merits of their preferred technologies remains a bit of a mystery to me; this should have been treated as a technical problem which needed to be solved, not as an issue to dispute.
The disagreement about DTDs, on the other hand, had some substance.
In the end, my boss told both teams he was agnostic about the solution. Then he reminded them we were paying them a lot of money to reach an agreement.
I’ve mentioned before that the web app we are rolling out was developed by two vendor teams working on parallel projects. One vendor was adapting an existing document management application to meet our specific needs, while the other vendor had agreed to build a web-based alternate front end on that app. The web app was organizationally an IT project and had an IT project manager. Meantime, the internal system was (is) wholly owned by our department; that PM, Mel, was my immediate supervisor. The resulting multi-headed beast had four actual PMs (counting the vendor folks); the poor critter was never healthy.
At this point I need to remind my readers that the app I’m calling “the back end” is actually a fully-functional production application with a GUI user interface. Only from the web developers’ perspective is this a back end; in the office, it’s a document processing system which keeps 20 employees busy.
Even before the contracts were signed, it was clear that there was a serious design disconnect: The back end vendor’s product used SOAP to communicate with the world, while the web team was committed to using MQ for a transport mechanism. Each team was adamant that their method was preferable, that (their) corporate headquarters was committed to that solution, and insistent that the other team should change. Bad sign, folks. Regardless, both teams made it clear that the disagreement wasn’t fatal; while each solution has technical advantages (and disadvantages), the only design reason not to build a hybrid system was the extra interface layer, and the potential complications resulting from that.
Shortly after the contracts were signed, we hosted a teleconference so the teams could begin to agree on solving the interface problem. The back end vendor wasn’t ready to share the SOAP interface spec, and the web vendor really needed to begin work–so the IT PM authorized the web team to start design development without a full interface spec. In restrospect, this was likely the worst of our mistakes on this project. I suspected it at the time….
The back end vendor’s development team works together in a single office far from Michigan, while the web team was an assembly of talents who live all over the country; while most would touch base in Lansing fairly regularly, they worked at home. This was not conducive to communications; rather than call the other team to resolve differences, they’d call Mel (or me) and complain. So we scheduled long teleconferences on Thursday afternoons; Mel and I (and occasionally Margie) would sit in and try to referee.
The methods dispute continued unabated. Every Thursday meeting would start with accusations, degenerate into name-calling, then to staking out incompatible positions. This would occupy the first 40 minutes or so; then Sean (the web team’s MQ/Web Services guru) would offer an opinion or ask a question and the real meeting would start. Within minutes they’d be past my technical competence, but it was generally clear when they were making progress and we were able to nudge them toward agreements, even when we couldn’t understand the issues. This is a terrible way to build something, but once we figured out the rhythm we learned how to work with it. (A word about Sean: He’s an obviously-brilliant geeky guy who speaks in tongues, stops to think in mid-sentence, and changes topics unexpectedly. Exasperating, but essential; we all learned to trust his opinions.)
One debate was never resolved to anyone’s satisfaction. The web team was fully convinced that the SOAP interface ought to have a fully-specified DTD, while the back end vendor was equally certain that this was a red herring. It was very much like they were talking about two different things called SOAP; the usual result was that the key players on each team talked right past each other, and wouldn’t acknowledge it. Very very strange days. Glad they’re past.
In the end, the issue was resolved when IT decided not to renew the contract of the web vendor, and took direct responsibility for the project. The politics mostly went away, and the technical issues became technical issues.
This remembrance was provoked by Kendall Grant Clark’s deconstruction of Tim Bray’s recent IETF memo offering a way to code what Clark (and apparently the XML community) calls “funny characters.” Clark’s case is built from this sentence in Bray’s essay: “For a variety of reasons, authors increasingly wish to avoid the use of DTDs, but still want to retain the convenience and readability of internal parsed entities.”
To me, this sounds a lot like the argument our vendors were having all summer in 2002.