Avoid JaBoWS as the Basis for your Enterprise SOA

Nick Malik declares JaBoWS (Just a Bunch of Web Services) are the enemy of Enterprise SOA.

In an earlier post on his blog Nick Malik first asked the question if your SOA is JaBoWS. With JaBoWS he does not want to start a discussion on technology, but on the general approach and goals of an Enterprise SOA:

I'm not asking from the standpoint of technology (are services secure, available, composable, etc) but rather from the business.  In other words, if the business wants to achieve flexibility through the SOA, do the available services represent the correct interaction end points to accomplish that goal?

In his opinion "Evaluating “how good” a SOA is means modeling out the competitive opportunities that are actually in the corporate strategy and seeing if the SOA can react to both expected and potential competitive moves". The SOA story is mainly about Business/IT-Alignment:

SOA saves money in some environments (especially ours), but it’s greatest value happens when the business can add a capability to meet a competitive opportunity quickly and inexpensively.  Speed is important.  Cost is important.  A Good SOA is structured to deliver on that promise.

He points out that traditional IT did a good job on "processes that changed rarely" and might or might not occur frequently. "The SOA Sweet Spot" is on the processes that occur frequently and change frequently.

In his recent post he declares that JaBoWS are not a bad habit of unsuccessful SOA initiatives of architecture teams that merely got it wrong:

JaBOWS is the dead end that kills value.  It is all that is wrong with top-down approaches that produce unusable services, or bottom-up approaches that produce overlapping and badly coordinated piles of services.  JaBOWS is the costly, time-consuming, valueless exercise that so many companies have taken upon themselves in the name of SOA.

Moreover according to Nick Malik JaBoWS poses a threat to the whole SOA community:

We all lose when any one company kills their SOA initiative for lack of value.  In the SOA community, we are all invested in the success of each company that has bought the hype.

Nick closes by calling on the community to start "writing about JaBOWS, and talking about JaBOWS, and sharing experiences about how to effectively avoid JaBOWS" and by defining a simple formula for JaBoWS:

It's not a tools problem.  It is a process and people problem.

Tools + existing processes = JaBOWS.   And that is baaaaaad.

Nick Malik's post is in line with Anne Thomas Manes' search for SOA success stories. As she points out all those beautiful (technologically driven) architectures, tooling and products "have yet to demonstrate how all this infrastructure yields any business value".

Scott Wilson  thinks that Malik's manifesto is a "simplistic characterization of what is bad and leads inevitably to JaBoWS":

I feel as though part of the problem with many of the tools which he rightfully decries is that they attempt to do exactly that; but I think that it is those restrictive, imposed definitions which cause many of the problems in enterprise SOA implementations. Instead, I feel about SOA as I do about ITIL: 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.

Mike Kavis makes a case for BPM as the main driver for any SOA initiative:

The problem with SOA isn't SOA, it's people. People must understand SOA and the importance of aligning their initiative with a key business driver. BPM is the killer application that can get your business sponsors on board. And finally, you need strong leadership with a focus on change management to pull it off.

What do you think about JaBoWS, tools, BPM, and Enterprise SOA?