Are you comfortable with your understanding of SOA and its role in integration? You are. Great!
Ronald Schmelzer of ZapThink says you're wrong.
OK -- that's not completely fair. He didn't say you, personally, are wrong. But he definitely has a bone to pick with a whole lot of techies (and techie writers) who are pursuing SOA projects "as if they were point-to-point integration projects."
I'm not going to lie: I was surprised by Schmelzer's lengthy analysis, published recently as a ZapFlash, and I'm guessing I won't be alone -- especially given a whopping 75 percent cited "integration" as the "issue SOA best addresses" in a recent AmberPoint survey. Not only are they using it for integration, but they're apparently doing so with great success, since the same survey showed only 1.5 percent of SOA projects were considered failures.
But according to Schmelzer, most SOA integration projects aren't actually SOA at all. If you're using middleware -- usually an ESB -- to manage service communications, then you're practicing Enterprise Application Integration (EAI) 2.0, not service-oriented architecture, he contends. The ESBs are actually being used as an EAI hub-and-spoke or message-bus brokers facilitating Web services integration, which, he stresses, is not the same thing as a SOA.
His argument is long and complex, so I'm not going to try to give you a summary here. Suffice to say this isn't just about what you call these projects or how you define SOA -- although it is partially about that. Schmelzer is trying to help you avoid costly mistakes with SOA. You'd do well to read the full article and overlook his occasionally condescending tone toward techies with integration backgrounds.
So, where does this leave us in terms of SOA? Again, I'm not trying to capture the whole of his piece, but here are a few key points: