InfoQ Article: Top 8 SOA Adoption Pitfalls

Posted by Miko Matsumura on Jul 20, 2006

Sections

Enterprise Architecture,

Architecture & Design

Topics

SOA ,

Stories & Case Studies ,

Agile ,

Architecture ,

Blueprints ,

Enterprise Architecture

Thomas Erl is the world's top-selling SOA author. He has written two books on SOA.  In this InfoQ article, Thomas explains the pitfalls others have fallen victim to inorder to help you chart a safer route down your own SOA roadmap. To this end he has collected the eight most common SOA adoption pitfalls he has noticed last year and explains which ones are still releavant this year.  Check out Thomas Erl's  Top 8 SOA Adoption Pitfalls.

In brief, the pitfalls are:
#8 Not Keeping in Touch with the SOA Marketplace
#7 Not Planning for Web Services Security
#6 Not Planning for Governance
#5 Not Understanding SOA Performance Requirements
#4 Not Starting with an XML Foundation Architecture
#3 Not Creating a Transition Plan
#2 Not Standardizing SOA
#1 Building SOA Like Traditional Distributed Architecture

How many of these pits have you falled into?

1. Back to top

   Why XML? Why vendor?

   by James Richardson

   Despite being very popular and free, there are more performant and less verbose extensible data serialization formats. (e.g XER/PER)
   
   Secondly - one needs to realise that the main purpose for the existence of vendors is to vend. Therefore they have a vested interest in making all the WS-* layers require their tools. However its totally possible to avoid a lot of complexity by simply not using vendor products, and doing "the simplest thing that could possibly work".
   
   Jetty A Servlet XStream can get you off the ground very quickly - not a vendor tool in sight...

   Reply

2. Back to top

   Re: Why XML? Why vendor?

   by Stuart Charlton

   This is a very unfair characterization of vendors, and I would also say a somewhat idealistic stance.
   
   Firstly, the XML verbosity argument is often irrelevant; the web is built on a very verbose markup language called HTML and seems to be doing just fine. There are many use cases that require a more compact form, but they tend to be the exception.
   
   Secondly, Why XML? Let me pose an alternative question: Why is broken English the most widely communicable form of language, even though there are other more efficient languages like Esperanto?
   
   There are plenty of contexts where an alternative to XML is applicable, such as JSON with AJAX. But one must recognize the serious economic tradeoff in making such an architectural decision. One shouldn't focus overly heavily on technological mechanisms when building an SOA; XML is not mandatory, but a whole lot more people will understand you than if you speak first century Aramaic.
   
   Third, vending supposes there is "need" out there. One can argue whether that need is manufactured or is real. I would say it's likely a combination of both. Clearly, there are many use cases that WS-* covers that you can't point to in nearly another other standard, save rarely implemented CORBA services.
   
   Some large customers happen to have tremendous clout with large vendors

   Reply

3. Back to top

   Re: Why XML? Why vendor?

   by Stuart Charlton

   Looks like I got truncated there.
   
   Some large customers happen to have tremendous clout with large vendors. Large vendors have clout with standards bodies. Thus a reflexive process occurs, where communities of practice think alike and guide a standard down a particular path, which guides client perceptions, which guides vendors, etc.
   
   Many clients want WS-*, even though URIs, HTTP and SSL would likely suffice for most use cases. They have their reasons - some legitimate, some not. But if they're willing to pay millions for an enterprise deal, it's hard for a vendor to at least be a "fast follower" of such standards, regardless of their actual success or value.

   Reply

4. Back to top

   Re: Why XML? Why vendor?

   by John Harby

   I agree with Stuart completly. The anti-XML argument probably doesn't hold much water except in the extreme cases. It has to be emphasized that SOA is really about distribution and how many distributed scenarios represent that sort of traffic where the message size will make a difference? Also, if you do have use cases with that sort of traffic can't patterns be employed to drop down or channel them around the ESBs, etc.?

   Reply

5. Back to top

   Re: Why XML? Why vendor?

   by James Richardson

   I am merely challenging the assumption that either xml or vendor is absolutely required to have a SOA. It depends on what floats your boat.
   
   While disagreeing, you simultaneously agree, by saying vendors are sometimes brought in "regardless of their success or value", and that xml is good "except in the extreme cases" - of which I can think of a lot.
   
   The need for these things should be decided upon by a rational decision process, rather than assumption. (as is the case with everything)

   Reply

6. Back to top

   Re: Why XML? Why vendor?

   by Jeff Thomas

   I agree that one can certainly have a valid SOA without XML. But it seems that many performance-oriented critics of SOAP/WS-* SOA are treating the proposition as if it were an application programming model and not an integration model.

   Reply

7. Back to top

   Re: Why XML? Why vendor?

   by Jim Murphy

   Let me add my 2 cents in support of vendors, since I represent one.
   
   The point of spending the last decade pushing for the widest possible standards ever has been to get as many people as possible "on the bus" (not the ESB, the metaphorical "lets all go in the same direction bus"). The point of that is to offload common, crosscutting concerns that app developers have been baking into systems themselves. The "openness" of wire protocol, metadata and policy supports a high degree of automation and composability of various vendor products.
   
   Obviously you need to be the judge of what automation and proucts you should compose but its a tremendous opportunity we have to raise the level of software development 1 notch.

   Reply

8. Back to top

   Suprised by the lack of fret over #2 Standardize SOA

   by Jim Murphy

   I often wonder what this means to people. Establishing a SOA council to adopt patterns and practices sounds like standardization. So does defining a common XML data model for an enterprise or even industry. But those efforts seem to be really hard to do. Try to get a bank to agree on the data model of a contact/person/organization/trading partner/entity etc. Then if and when you have standardized how do you evolve?
   
   Does standardizing at a low level stifle future innovation? Once you have that in place is there ever a chance of moving ahead?

   Reply

9. Back to top

   Re: Suprised by the lack of fret over #2 Standardize SOA

   by Eric Roch

   XML can be a challenge but it?s difficult if not impossible to avoid using. Even if you don?t want to use XML your business partners will likely force you to. There are also great tools for authoring and storing (repository) XML and there are XML accelerators if performance becomes a problem.
   
   See this post for more tips on XML and SOA.
   
   blogs.ittoolbox.com/eai/business/archives/xml-s...

   Reply