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.

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

Comments

• Anonymous
  March 17, 2008
  PingBack from http://msdnrss.thecoderblogs.com/2008/03/17/jabows-is-the-enemy-of-enterprise-soa/

• Anonymous
  March 17, 2008
  You are dead on when you stated that, "It's not a tools problem.  It is a process and people problem."  I just wrote a post claiming that the problem with SOA is not SOA itself, it is people who don't understand SOA. http://blogs.ittoolbox.com/eai/madgreek/archives/why-doesnt-anyone-understand-soa-23102

• Anonymous
  March 18, 2008
  The comment has been removed

• Anonymous
  March 18, 2008
  Great post, Nick. And I couldn't agree more. :-) I think 10 years from now we'll look back and recognize that a lot of what we thought was SOA was actually JaBOWS, serving narrow, tactical needs. And that this hurt perceptions about what SOA could really accomplish. -Joe

• Anonymous
  March 19, 2008
  Thanks, Joe.  

• Anonymous
  March 19, 2008
  Nick: you are dead wrong when you claim it is not a "tools" problem. It is only a tools problem is not until we will move millions of developer from a Synchronous CRUD-Oriented Client/Server programming model to an Asynchronous Inter-action Oriented Peer-to-Peer programming model that then we will reach the level of enterprise SOA. Today people do JaBoWS just and only because it is enforced by the consumer side programming model. It has nothing to do with people and process, and only with tools. The day we will smash MVC, Object Orientation and ER as the foundation of the application architecture, that day only, will we be able to create an enterprise SOA.

• Anonymous
  March 19, 2008
  Very true.  The same was true for structural analysis and later for OO. All that stuff gets always oversold claiming that it would solve all the problems easily and create maintainable products quickly. But as we know there is not an easy solution to a complex problem. It requires careful engineering and knowing a specific environment. Methodology  can obviously help but a lot depends on experience of people. I am actually very pleased hearing that.

• Anonymous
  March 19, 2008
  The comment has been removed

• Anonymous
  March 19, 2008
  Nick, yes, it is true that SCA promotes an AIOP2P programming model, it is also true that one could come up with a better technology -no doubt about that. But what I am really talking about is at the EA level: People, Process and Technology (tools). How can you expect that "People" and "Processes" would change while they have been optimized for the current programming model ("Technology")? You are fighting 40 years of evolution. You are recommending an unnatural, therefore unlikely, change. It is not until the programming model will change that "People" and "Processes" will be re-engineered to reach new levels of optimization in relation to this new "Technology".   At the end of the day, thinking that "tools" are adequate today is a bit of a stretch. I urge you to consider the argument that "it does not matter how many times you say interoperability", that's still not going to give you Service Orientation. Web Services Annotations on a CRUD-Oriented programming model are simply equal to XMLized remoting. Service Orientation is about enabling an AIOP2P programming model, whether you use SCA or not is just a technical detail. The key concepts of an AIOP2P model are: bi-directional interfaces, orchestration and assemblies. (WSDL,BPEL,SCA) is definitely a match, but again I am not caught up on it. Loose(r) coupling can be achieved with technologies such as XML and SDO. Incidentally, one of the major contribution of SCA is to add bi-directional interfaces and orchestration to traditional programming environments (Java, C++) in a non invasive way. So in itself, SCA has enabled the emergence of an AIOP2P programming model across the programming landscape. So overall you are correct in saying that "SCA" is not the solution to Jabows, but by far it opens the door -and I don't know any other technology today that can claim that- to go passed beyond Jabows and focus on "inter-actions".

• Anonymous
  March 20, 2008
  The comment has been removed

• Anonymous
  March 21, 2008
  The comment has been removed

• Anonymous
  March 21, 2008
  http://maxtechtalk.blogspot.com/2008/03/jabows-yam-jaboms.html#links

• Anonymous
  March 21, 2008
  The comment has been removed

• Anonymous
  March 22, 2008
  Nick, JJ, A very interesting discussion, but... The issue here goes far beyond tooling. No matter how good your tooling and programming models are, if your services are not aligned with the enterprise business model and semantic, you will still end up with JaBoWS. The issue here is that SOA is a business problem, that we are trying to attack as a technology issue. Regardless of the technology used, bottom up approach to SOA leads to JaBoWS. Top down design can and should improve situation, but majority of practitioners considers it too complex and expensive. We are still cought up in an application centric mentality and a result have even invented a term application services. Untill we start considering SOA as a true enterprise undertaking JaBoWS will continue to rule the world.

• Anonymous
  March 22, 2008
  Hi Boris, My point exactly.  That is what SDA does.  It's good to know that someone gets it. --- N

• Anonymous
  March 22, 2008
  Hi Joris, Hate to say it, friend, but your prescription treats a different disease.  Good advice, but doesn't solve for JaBoWS. --- N

• Anonymous
  March 22, 2008
  I am glad you accept that web services are better than COM, EJB, or CORBA for interoperability.  Thus, they are better than what came before, by being a message oriented enterprise integration strategy. I am generally of the mind that most claims of any greater benefits of SOA just confuse things and waste money. Fowler's concept of Service Oriented Ambiguity lives on. [ http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html ] What is it in non "Enterprise SOA" web services that prevents them from being "composed in new ways, ones that were not foreseen by the authors of the services"? Why can't Enterprise Architecture just coordinate the bottom up creation of services to increase the probability of future reuse? The pendulum is swinging back to making IT simpler...by focusing on the user experience, by dealing with the fact that so-called enterprise technology is starting to trail consumer technology in capacity, availability, usability. Take a step back and think about the business value of what you are providing- not some ridiculous concept of "alignment" that people bring up, but how you can use IT to bring money to the organization, or, if you can't, make it cost less. If you aren't tracking back to one of those objectives- get out of the way.

• Anonymous
  March 23, 2008
  Hi Matt,

1. Alignment reduces IT spend by 10-12% yoy project spend.
2. Building a service layer that produces semantic consistency cannot happen bottom-up.  Without semantic consistency, services cannot be reused at any kind of scale.  Every app creates new services.  Complexity flourishes.
3. I estimate that, in a sufficiently complex environment, building a consistent service layer and then, over time, moving front end apps to the same, will reduce the app portfolio by as much as 30%, and will reduce the complexity of the ecosystem by 20%.  Complexity begets cost. I have business goals, my friend.  This is not about WS vs. COM. -- N

• Anonymous
  March 25, 2008
  The comment has been removed
• Anonymous
  March 25, 2008
  The comment has been removed
• Anonymous
  March 25, 2008
  Hi Alex, You assert three concepts here:

1. Enterprise SOA as an architectural style
2. Enterprise SOA = Enterprise Service + Design governance
3. Enterprise Service = Understandable digital business asset Question: Does the design governance that you are asserting in #2 above REQUIRE adherance to an enterprise wide information model? You use the term "non functional quality" and it makes me think you are describing what we call System Quality Attributes.  While I agree that the only rational way to insure enterprise class quality is through governance, I am concerned that your definition appears to stop there.  To me, alignment to a common information model, as difficult as it may be to create, is imperative if we are to get semantic interoperability. And, in my opinion, the best and most promising avenue for attacking the scourge of JaBoWS is via semantic interoperability. Do you include issues of Semantic interoperability in your understanding of Enterprise SOA? --- Nick

• Anonymous
  March 26, 2008
  Hi Nick, thanks for a very thorough response - it's probably the most detailed and relevant I ever got. Naturally, I could not resist the temptation to answer, but my reply quickly grew past what's reasonable for a comment in both size and scope, so I decided to post it here: http://blogs.sun.com/RealSOA/entry/to_or_not_to and put these trackbacks in both comment streams. And for the record: I agree with your agreement ;)

• Anonymous
  March 28, 2008
  I'm always a bit worried when someone has "the answer." Lot's of red flags go up when someone tells me:

• Anonymous
  March 30, 2008
  Let's assume that every problem worth solving has a cause. Interesting assumption. Reality: Any one problem

• Anonymous
  May 13, 2008
  I just came across this post and found myself in agreement with most of your points.  Just creating a service and exposing it for people to use doesn't mean you have a working SOA program.  Tools do not solve the problem of SOA but people and processes do.  Tools provide support for the strategies, processes, and policies that people put together.  However, no single tool or a suite of tools will provide a complete SOA or EA solution.  A lot of manual processes will still be required.  The key to a successful SOA program is governance.  Without it, you will end up with JaBoWS. I also wanted to add to the discussion on SOA and agile development.  I actually explore this topic in depth in one of my posts: http://leoshuster.blogspot.com/2008/05/soa-agile-software-development.html.  I strongly believe that agile development is one of the worst things you can do to your SOA program.