BT

InfoQ Homepage News InfoQ Article: Top 8 SOA Adoption Pitfalls

InfoQ Article: Top 8 SOA Adoption Pitfalls

Bookmarks

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?

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Why XML? Why vendor?

    by James Richardson /

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Re: Why XML? Why vendor?

    by Stuart Charlton /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

  • Re: Why XML? Why vendor?

    by Stuart Charlton /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Why XML? Why vendor?

    by James Richardson /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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)

  • Re: Why XML? Why vendor?

    by Jeff Thomas /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Why XML? Why vendor?

    by Jim Murphy /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Suprised by the lack of fret over #2 Standardize SOA

    by Jim Murphy /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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?

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

    by Eric Roch /

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.