How To Kill A SOA Project - Or What Questions To Ask First Your Client

SOA focusses on business and customer needs - what is a good thing. However it becomes often too expensive, or hard to estimate. The problem is seldom the technology - and always business, organizational issues and politics. Things, which cannot be fixed with any technology. There are some technical challenges, which can be derived from the distribution, reuse and orchestration. The following facts have impact not only to the technology, but especially for business - and can make your customer no more so excited about the SOA approach:

1. A once deployed service (e.g. WSDL, Java interface, WADL, IIOP etc.) cannot be changed any more. Every change breaks all clients (potentially from other departments). In some protocols - even minor interface changes can break the contract. So, what is the strategy for the release management?
   
2. Because a service cannot be changed - new copies (versions) of slightly changed service have to be deployed. So, how many versions of one service your department like to maintain?
   
3. Monolithic services are orchestrated inside one process in a local transaction - now they are distributed - and distributed (XA, 2PC) transactions are needed. Does it really work?
   
4. The robustness of the whole systems becomes as good, as the weakest service. Can your customer live with that?
   
5. You have to live with partial failure - this problem was unknown so far in monolithic silos. How to deal with it from the business perspective?
   
6. It is hard to find a semantically valuable service, which is interesting enough to different departments. Business Domain Objects like "Customer", "Invoice", or even "Address" are different concepts for each department. So will the service be actually reused at the end?
   
7. The abstractions and distributions and TX coordinations do cost performance - synchronous transactions becomes asynchronous, or have to be split to many fine transactions coordinated by the end-user. Is your client ready to change the already existing process to adapt SOA?

Funny thing - at the beginning of the most SOA projects - no one want to hear such questions - it is much easier to concentrate on the technology, and forget about business :-). In case the customer already invested in tools and infrastructure - he want to be successful and just start to implement. Inconvenient questions are always problematic :-). I forgot some points for sure (this post was very spontaneous) - what's your experience with SOA? In my opinion, most of successfull projects are "just" EAI integration of existing, legacy stuff - so only few of this points have to be considered in such a case...

[See also Persistent Domain Object, page 90+ and Pragmatic Java EE Architecture, Page 253+ in the book "Real World Java EE Patterns"]