Published in IT World
The Jazz approach to E-business integration
By Sean Mc Grath
I hope that some of you will like this article. However, I predict that some of you will dislike it. Before we start, let me ask you a question. Do you like Jazz? In particular Jazz improvization? Your answer to that question will, I believe have a bearing on your reaction to this article.
How do we get a couple of business systems to talk to each other according to currently accepted best practice? Why, unless there is a very good reason not to do so, we should use XML to express the data right? What does that involve? Well, we get our architects into a room and we figure out what the data is going to look like flowing between our systems. We capture the timeless Platonic perfectitude of our ruminations in XML schemas.
These schemas are the primary artigfacts that will feed into software development somewhere down the line, maybe next year. We need to define all the ins and outs of the data formats up front of course. We cannot let the software development start until the schemas are rock solid. That would be silly, wouldn't it?
Picture the scene. The white shirted architects gather in the well lit meeting room with more flipcharts than chairs. They struggle late into the night and into the early morning on their data models. Struggling to define the nano-particles of the data and process flow between systems. Through an open window, from a basement far below, comes the sound of Jazz.
In some other basement, in another part of town a second team of architects is struggling with the same integration question. How do we get a couple of business systems to talk to each other? One architect, familiar with the innards of system A, throws together a sample XML document and fires it up on the screen. Another architect, familiar with the innards of system B, throws together a second sample XML document in the response to the first. She too fires it up on the screen.
The system A guy makes a few changes to the XML and flies it via FTP to the system B architect. Within seconds, the system B guy has picked it up and replied with his own XML document, also via FTP. Soon, XML documents are slinging to and fro. All the while, the architects work together to fine tune the exchange. They try different possibilities, homing in and accentuating the ones they sound best, throwing out patterns that just don't sound right.
Meanwhile, a third architect is watching all of this and listening to the exchange between A and B. He adds an underlying beat in the form of an orchestration that brings some order to the exchange of data between A and B. Somehow, somewhere along the line, the integration between systems A and B starts to actually work. It ceases to be a plan and become a reality. Through an open window, from another basement, comes the sound of Jazz.
If you think the latter scenario could not possibly work in practice, I suggest you take a closer look at how some of the best Web/XML technology out there actually works in practice. There is an entire class of highly competent EAI architects and engineers who work that way. Formal XML schemas and formal application development waterfalls do not feature in their modus operandi. They sling sample XML at each other, then refine it until it works. Formal schemas - if they exist at all - are ex post facto artifacts of the process - not the primary design instruments.
You will either find this way of integrating systems horrifying or you won't. I predict a correlation between your reaction to it and your attitude to Jazz.
Am I right or am I right?