Top 10 SOA Pitfalls

Discussions

News: Top 10 SOA Pitfalls

  1. Top 10 SOA Pitfalls (13 messages)

    Over the last 2 months Rik de Groot, Viktor Grgic, Vincent Partington, and Gero Vermaas ran a Top 10 SOA Pitfalls blog series. This top 10 countdown is now completed and it's time to wrap up and step back and see if there is some logical grouping in the top 10. Putting all pitfalls together in one simple 10 item list quickly reveals a grouping of types pitfalls. Number #1 and #2 are both related to organizational aspect. If the culture, mindset and attitude are not right, these are typically the pitfalls that a SOA endeavor may run in to. The next group covers the items #3 till #7, these are all related to architectural/design skills. And the last group, numbers #8 till #10, relates to implementation issues (although proper design could help to prevent these pitfalls from manifesting themselves). The complete Top 10 SOA pitfalls list is: Implementation pitfalls Architectural/design pitfalls Organizational pitfalls: It was great fun to compile this list with the four of us and it also helped us to get a sharper view on why SOA projects or programs are challenging and hard to complete successfully. Hopefully you've learned a thing or two and are able to prevent or at least recognize the pitfalls in your day-to-day work.

    Threaded Messages (13)

  2. Re: Top 10 SOA Pitfalls[ Go to top ]

    Overall a pretty decent set of articles. I'm not sure about the BDUF vs. agile argument though. Unless a SOA is well thought out and a well-defined process exists for extending and modeling it, I think it can easily become fragmented and begins to lose its value. I think the governance process is not stressed enough. I think the authors may have confused big up front design with waterfall. The up front design needs to be done, but can be done iteratively. That is, it is ok to model business process A, and move it to implementation while modeling business process B. Contrast that with waterfall, which states that I move nothing to implementation until all design is complete. I am reading a couple of SOA books from Thomas Erl, who does a great job of breaking down and explaining the SOA space in some of the simplest terms I've seen. Wrapping your mind around SOA is half the battle. Once you've mastered the lexicon and principles, it becomes much easier to carve through the confusion and implement. You can read some excerpts on his web sites: http://www.soaprinciples.com and http://www.whatissoa.com - Joe
  3. COMPLI CATED[ Go to top ]

    I tried a bit of JBI this week. It is tooooooo complicated! With a model like this you don't need a pitfall to actually fall!
  4. Re: COMPLI CATED[ Go to top ]

    I tried a bit of JBI this week.
    It is tooooooo complicated! With a model like this you don't need a pitfall to actually fall!
    You should stick to CSS/JSP/HTML/JavaScript editing then champ.
  5. Re: COMPLI CATED[ Go to top ]

    You should stick to CSS/JSP/HTML/JavaScript editing then champ.
    I guess I would. You can make money developing SOA and I will be replacing them by HTML in a couple of years.
  6. Re: COMPLI CATED[ Go to top ]


    You should stick to CSS/JSP/HTML/JavaScript editing then champ.

    I guess I would. You can make money developing SOA and I will be replacing them by HTML in a couple of years.
    Deal!
  7. Re: COMPLI CATED[ Go to top ]

    I tried a bit of JBI this week.
    It is tooooooo complicated! With a model like this you don't need a pitfall to actually fall!
    Just a suggestion, stay away from JBI. It's caught on just about nowhere and it's roundly panned as an object-oriented approach to service orientation. Unless you need JBI for a specific project, it probably isn't something you need to know. More importantly, JBI is emblematic of the "SOA = integration" mindset I was referring to. More than learning a specific technology, what you really need to do is learn how to build composable, stateless, contract-based, loosely coupled services (if you're interested in pursuing some SOA skills). From what I understand, a lot of developers get hung up on composability and statelessness. It's not how they were trained to build things and it requires a major mental adjustment. Here's a breakdown of basic SOA principles. If you're looking to play around with a specific technology, I'd suggest Apache Tuscany. It's focused on composition instead of integration and it's incredibly uncomplicated. Brushing up on REST skills is probably a sound idea as well.
  8. Tuscany?[ Go to top ]

    Apache Tuscany. It's focused on composition instead of integration and it's incredibly uncomplicated.
    I took a quick look, but the URL to the SVN repository is broken, and the user guide seems very incomplete. Kinda hard to figure out what Tuscany actually does for me. I looked at http://tuscany.apache.org/getting-started-with-tuscany.html , but I still couldn't figure out what value Tuscany is adding. It looks like I have to write a verbose "composite" XML file to get something done. And some of the classes are using Tuscany classes, which seems like a no-no for a framework that is supposed to shield the application code from the environment, right? I didn't look much closer, it just seems like Tuscany has very half-baked (and the broken SVN URL doesn't really inspire confidence!).
  9. The #1 Pitfall[ Go to top ]

    Spending 1M on an SOA platform that you didn't need in the first place.
  10. Re: Top 10 SOA Pitfalls[ Go to top ]

    Good list Gero. The top two really get at the heart of the matter. According to recent study by Burton Group, the real #1 pitfall is not making SOA part of a larger business initiative. Apparently there are IT shops out there who have done SOA perfectly right from a technical standpoint and it's not delivering. Why? Because it needs to be about more than the technology in order to succeed. There are also a fair number of folks who think SOA = integration. They're wrong. The ones who get outside the integration/IT mindset seem to be the ones who are succeeding with it.
  11. Top SOA Pitfalls[ Go to top ]

    The list doesn't directly highlight the need to align with business initiatives/processes. It also doesn't give due importance to having the appropriate methodology/framework to implement SOA.
  12. Re: Top SOA Pitfalls[ Go to top ]

    The list doesn't directly highlight the need to align with business initiatives/processes. It also doesn't give due importance to having the appropriate methodology/framework to implement SOA.
    List is far from perfect and complete, but gives nice overview.
  13. Re: Top SOA Pitfalls[ Go to top ]

    The list is not expected to be perfect and complete if it were entitled just "Top SOA Pitfalls". But for it to be entitled "Top 10 SOA Pitfalls", it implies that this list highlights the first 10 SOA pitfalls, thus the expectation to be reflective of commonly perceived or observed pitfalls, the first 10 to be exact. But it's a nice overview indeed.
  14. not just SOA[ Go to top ]

    most of these pitfalls can and have been seen in non-soa development efforts it is good to see more explict codification of what experience shows does and does not work