Gartner published a research paper on SOA meltdowns written by Yefim V. Natis and W Schulte. The raised question was:

Won’t SOA suffer the same consequences, a meltdown like we’re currently seeing in the financial markets, if one of the services part of the SOA architecture would get intoxicated?

The answer is: Yes!

Simple because the chain of services used in SOA, are as strong as the weakest link is. So if you do nothing to manage this, a meltdown is bound to happen.

Gartner’s recommendations can be summarized as follows:

• Limit the number of services you use! Not everything in an application must become a service. Typically only 5 to 30 services are required. Services introduce multiple architectural layers in order to work, that make them very heavy an inefficient if they are overly used.
• Avoid meshes of services you have no control over! You should know if your services are using other services. This knowledge of external dependencies will give you insight during risk assessment of the whole architecture. Your service providers should openly disclose this information.
• Monitor changes in the mesh of used services! If you have nothing in place to monitor the changes over time in the services you depend on, you’ll once again lose control and are unable, in the long run, to correctly asses any risks.
• Don’t be responsible for the services’s state! Try to avoid request-response access to services because they make you, as service client, responsible to resolve the situation if the service does not respond or is not available. Focus on event driven designs, were requests are fired-and-forgotten to the services.  At least this takes away the immediate dependency on the service.
• Avoid big bangs! Start small when introducing SOA. Use some pilot projects. This will allow the organization to grow and to avoid big costs if the project does not work out as expected.