The chasm between JBOWS (Just a Bunch of Web Services) and SOA

SOA in Action Blog

« Putting the pedal to the metal in SOA -- literally | Main | Healthy, Wealthy and Wise with SOA »

September 13, 2006

The chasm between JBOWS (Just a Bunch of Web Services) and SOA

I've been ruminating over the results of a recent InformationWeek survey, which the publication entitled "The Dark Side of SOA." I'm not sure where the gloomy title came from, since the survey seems to generally point to some pretty bright expectations from service oriented architecture implementations.

Yet, for initial implementations in the survey of 273 technology executives, there were few cases were these expectations were met -- seven percent, to be exact. Another 24 percent report they weren't happy with the way things were working out.

Interestingly, the survey fuses the categories of 'SOA' and 'Web services.' The problem with this fusion is that many organizations may have a significant amount of Web services, which aren't necessarily orchestrated or managed as part of an SOA -- they're JBOWS, or Just a Bunch of Web Services.

I had the chance to talk with Infravio's (or webMethods') Miko Matsumura about what this survey is telling us. Miko pointed out that the survey demonstrates organizational barriers more than technical barriers. "There's a prevailing notion that reuse isn't occurring because of discovery, because people don’t know about things -- but that turns out to be actually not the case."

Actually, "the reality is that people don’t fully engage SOA because of mistrust, and political reasons, and because of silos. And silos evolve not because people are dumb, but because people are pretty smart. They know who their bosses are, they know which kingdom they below to, and they k now that the enemy may not be the product they compete against in the market, it may be the other division In the company that gets more budget than them."

For example, Miko said, about 55% of respondents said one of the challenges is that SOA introduces more complexity into IT systems. "What does that mean, introduce more complexity?" he asked. "It means it introduces someone else’s interest into my workflow. So the developer says, 'now I have to deal with complying with these standards for interoperability, whereas before, I didn’t have to. That’s more complexity. Now I have to deal with getting approval from another business unit, whereas before, I didn’t have to. Complexity really means introducing somebody else’s viewpoint."

Such as being married introduces more complexity than the single life. In the case of enterprise SOA, "it's like being married to 40 people," he quipped.

Posted by joemckendrick in SOA | Digg This | Add to del.icio.us