JaBoWS is the Enemy of Enterprise SOA

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.

Don't get me wrong.  I don't hate tools.  For one thing, there are some tools that support Enterprise SOA*.  Not many, but a few.  Those tools understand that Enterprise SOA is not about building one service after another, but building the right services, and building them in a manageable and non-overlapping way. 

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.

image

  • If you take a group of well-meaning and intelligent engineers,
     
  • and you give them a process that looks like a normal software development process**, and you train them on it, and they believe that this process works...
     
  • and you add SOA...
     
  • you get JaBOWS (Just a Bunch of Web Services).

I did not invent the term "JaBOWS."  Near as I can tell, Joe McKendrick did, a couple of years ago.  However, I am taking it one step further.  I believe that JaBOWS has specific causes and can be specifically avoided.  Not just with an executive sponsor, as Joe suggested back in 2005, but with a comprehensive Enterprise SOA transformational program, an approach designed to create a reusable infrastructure. 

Failing that, companies that invest in SOA are getting tripe, and the entire goal of achieving Enterprise SOA takes a hit.  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.  If we sit quiet, well before those initiatives fail, then we have no right to come back, two years from now, and say "well, it failed because you didn't do it right."  Or worse, "if you do it again, we can show you how to get value."  That Ain't Gonna Happen.

As a community, we have to do a better job of defining what it means to build an Enterprise SOA*. 

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.

In order to force that growth, and leave the bad behavior behind, we have to declare war on JaBOWS. 

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. 

Join me now.  Join me in decrying the creation of piles of useless and valueless noise.  It doesn't matter if it can be discovered, or governed, or built quickly, if it is not reusable.  It doesn't matter if it is built on WS* or leverages the best security protocol on the planet, if it is not decoupled correctly. 

Join me by writing about JaBOWS, and talking about JaBOWS, and sharing experiences about how to effectively avoid JaBOWS.  Join me by sharing what is wrong with building too many things, none of which are actually usable outside their original context.  Join me, by discussing the processes by which developers build the right systems, not just the tools that we need to buy and the interface standard we need to adapt.  None of those solve the problem.

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

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

 

* 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.

 

** I am including agile development here.  There is nothing in Agile methods that makes the problem worse, but there is nothing that makes the problem better, either.  If you say there is, tell me what agile book, on what page, aligns the agile manifesto with Enterprise SOA development.  I have all the books right here.