War declared against JBOWS architecture... but is it something we can live with?

In a new post, Nick Malik declares all-out war... against JaBOWS, or Just a Bunch of Web Services, architectures. 'What I hate is the notion that SOA can be reduced to tools'He urges IT executives and professionals to get active as a community in the effort to stamp out JaBOWS before it chokes the very SOA efforts that were supposed to simply and streamline IT architectures.

Nick says he's grown sick and tired of the all the talk and promises of SOA, yet nothing happening but more spaghetti:

"As a community, we have sat silently by as the pundits have sold products that fail to deliver on the promise of SOA. We have watched, many of us in horror, as the goal of changing behavior, and changing infrastructure, has fallen victim to 'yet another tool' to solve the same problem."

As Nick put it: "What I hate is the notion that SOA can be reduced to tools; that you can introduce a tool and suddenly all the bad (human) behavior stops. I want to dispel that notion right now." The way he explains it, the road to JBOWS is paved with good intentions. (By the way, Nick's JaBOWS and my JBOWS acronyms are interchangeable.)

As Nick puts it, it happens like this across organizations:

1. If you take a group of well-meaning and intelligent engineers...
2. Give them a process that looks like a normal software development process, train them on it, and they believe that this process works...
3. And add SOA...
4. You get JaBOWS (Just a Bunch of Web Services).

The good news is JaBOWS is not a terminal condition, Nick says. The key is to move toward "a comprehensive Enterprise SOA transformational program" that emphasizes reusability. No enterprise architect, developer, or IT executive can do this on his or her own, however. Nick urges SOA proponents to better share knowledge and approaches, and work harder to raise awareness within their own establishments. "As a community, we have to do a better job of defining what it means to build an Enterprise SOA," he says.

The first step in this awareness campaign is to acknowledge that the slow and tortured adoption for SOA thus far has nothing to do with tools, as vendors may want you to believe. "It is a process and people problem," Nick states. Attempts to leverage tools to address existing processes is what is creating JaBOWS.

As Nick explains:

Enterprise SOA goes way beyond 'making two apps talk using a Web service interface.' It is a systematic approach to developing an Enterprise-wide Service Oriented Architecture that actually allows information, process, and functionality to be composed in new ways, ones that were not foreseen by the authors of the services. Until you have this, Web Services are just 'interoperable COM.' Without Enterprise SOA, you have JaBOWS."

Nick also relates that Microsoft has been battling the JaBOWS syndrome in its own internal SOA efforts: "In Microsoft IT, we are using something we call 'Solution Domain Architecture' or 'SDA' to build an approach to services that, we hope, will result in the creation of an Enterprise SOA. SOA is the benefit, SDA is the way to get there. And the reason to use SDA: to avoid JaBOWS."

CIO's Scott Wilson picked up on Nick's clarion call to crush JaBOWS, and posits that Nick may be seeking perfection in a quite imperfect world. While Scott agrees that many SOA projects fall down the slippery slope toward JBOWS, he says there may be many ways to address a problem, and tools are just as legitimate a means as anything else.

In some situations, the right tools will actually help the move to Enterprise SOA, though it not be not be textbook SOA, he says. In fact, SOAs don't have to be 100% pure and elegant:

"I feel about SOA as I do about ITIL [IT Infrastructure Library]: it's a concept that needs some flexibility to be useful in every instance. Imposing restrictive stamps on what it is and is not makes a lot of sense within a given organization, but I'm not sure it's a good idea for the concept as a whole."

In other words, Scott is saying, if something works for the business, even though its ugly or messy, why fight it? "Making compromises in architecture isn't always wise, but it doesn't always debase us, either; there are times when compromises are the best thing for the business." He adds that this is "a choice that CIOs face all the time."

True, no two SOAs will ever look alike, and many will be ugly conglomerations of clunky services, hopelessly non-interoperable systems, and unsupportive business units. But, in the long run, Enterprise SOA holds tremendous value as an agent of transformation. The challenge now is that too many businesses with low-functioning JBOWS architectures think they have SOA, and are wondering, 'where's the value?' And, as a result, dismissing SOA before things even have a chance to get off the ground.