There is a fine line between technology addiction and proper technology
usage. SOA should not be used just for the sake of using it rather it
should be used judiciously. Here are the indicative scenarios were it
can be used and not used
How and where not to use SOA
Do not use it for small projects which do not need interoperability
of various services. Use the good old MVC architecture to segregate
your system.
Do not change all your existing services to SOAP/WSDL interfaces.
Some services work best as they are. Example: Your existing socket server
is best bet for performance intensive services.
Do not get dazzled by SOA. Read the requirements and business processes
properly and evaluate what level of SOA is needed. Don’t split
your application into 100 services. Remember there will need to be hundred
services to be maintained when the product goes to production.
Do not scrap the old products completely; see how the old products
can integrated into SOA.
Do not use SOA were performance is important. Because SOA induces
a whole array of call stacks like SOAP, WSDL, Service level security
which could completely clamp down the performance of your system. One
solution to this is server farms. But do you really want you increase
your maintenance costs.
If you are sourcing your system to other vendors make sure SOA architecting
is done or validated properly by you. There have been tons of SOA failures
and un maintainable systems due to wrong and technology eccentric SOA
implementations.
Don’t let SOA features drive your system. But let the system
requirements and business processes drive the SOA.
