I’m an EA in an organisation with 10000+ employees. Strategically we are heading towards SOA. Currently I’m researching about SOA’s and creating a road map and I have come over many blogs that talk about “SOA is dead”. We can all agree that SOA is not just web-services.

The problem is that I have hard to find any information on the reason behind SOA-fail stories in enterprises. What went bad and what went right?

My question is: What are common SOA mistakes in enterprises that make SOA fail in long term? Is the any best practice for SOA? What are the most important requirements for a successful SOA in an enterprise?

It would be good feedback towards our SOA strategy in this organisation.

I have tried to narrow down the question, but it’s hard due to the nature of the question.

  • if soa is dead I'd like to know the best alternative – NimChimpsky May 23 '12 at 12:01

From my experience with SOA strategy the biggest issue is making it understandable to business and the governance of it. The limitations are not technological. Typically when designing a SOA architecture you have to be client (those that will consume your services) agnostic. However typically the business analyst and end users only understand the screens that they interact with. So your challenge is to make your services generic enough that many screens in different clients with different workflows can use it. This is tough. e.g. We have a core enterprise service that is used by an internal desktop client and a public facing web application. The same service is reused by both but designing such services are challenging as they present the same data differently and have different workflow.

You also have to watch for dependencies. The project for desktop client may request a change to a service that may be breaking for the web client s well and that project may not be willing to pay to make the necessary changes for the web client. This requires a real solid governance structure.

The other thing to consider is the granularity of web methods (CRUD style or document style), service Independence etc. From technical perspective hosting, deployment, service versioining, security policies, interoperability (e.g. for us Java - WCF), monitoring etc. all needs to be thought about as well.

  • 1
    your example is the perfect case where you can just write a new different webservice and have two separate services ? I thought that was the point tbh. – NimChimpsky May 23 '12 at 12:48
  • Is this something an Enterprise Service Bus would/could solve, with translation of messages between different systems? – Svish May 23 '12 at 13:12
  • @Svish Traditional ESB approach has been one of the reasons behind SOA failure. – Amir Rezaei May 23 '12 at 14:14
  • @NimChimpsky - I thought the same thing. If the requirements for the desktop client and the web client are different, wouldn't it make sense to have 2 services? They could share the same data, and even share common code. – B Seven Dec 3 '14 at 14:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.