How to avoid risks in SOA implementation?

SOA project may go haywire if things are not planned,managed and designed properly.

It is very important to know your customer's requirements,expectations and improved business processes in advance before starting any analysis and design exercise.A continuous communication with your client is must so that you can understand their business processes very well and should be able to identify problem areas with some concrete solutions in mind.If you have a suggestions related to business processes improvement then get an approval from your client on business requirements as they keep changing all the time.So scope of work is clearly defined to you and your customer with extensive project planning.If a customer does not see any qualitative improvement in complex business processes simplification/replacement with new improved business processes,he is going to make a lot of hue and cry about introducing new technological architecture.An organisation is always interested in synchronisation and improvement of its business process with its customers,suppliers and partners for improved productivity irrespective of what technological steps are required to achieve it.Hence if anything goes disastrously wrong then SOA will bear all blame along with people involved.

Do not end in developing spaghetti services,it means,do not jump into implementation of services right away without analyzing its impact and overall inclusion in a large picture.Avoid duplication of services and create standards based infrastructure to build services upon.A service must be properly designed to address unexpected issues which may come in future.A solution to avoid spaghetti services is creation of a single Enterprise Services Bus(ESB). An ESB is a distributed infrastructure that is based on service standards.It is a single point for routing,securing messages(single sign on etc.).It enables any system to talk to other systems which are plugged in to ESB by providing necessary transformations required to messages to do that.An ESB empowers network administrators to monitor and audit all message traffic to provide with accurate metrics, giving complete visibility into how the services are being used, and how performance can be tuned.

As SOA is paradigm shift from object oriented technology to messages, which is a base unit of a service, based development, it is quite significant to distinguish and application from a service.So segregation of application team from a services team leads to a focused approach where applications developed will have interfaces which are consumed by services.The interfaces give lot of flexibility in order to integrate applications with services, so a great care should be taken in mind in designing and developing them.

A multi-layered services development is a smart approach of building services.First chalk out all fine grained services which may exist in SOA based solution and then build coarse grained services aggregating fine grained ones.In this way, the solution will be able to withstand requirement changes occurring every now and then.Even design patterns will also fit well in such scenarios, session facade and mediator design patterns gel very well to web services.

A plan for configuration management,performance tuning and scalability is must.None will care whether SOA is in place or not but how a solution efficiently runs a business that matters most to the end user.They want a high performance and do not want their system to work at snail's pace.The architects have to plan for scaling issues at design time for improved performance of the system.The database resources,session state management,services usage pattern,security of services involving cryptography,XML processing , they all are highly CPU engaging activities.So deciding about the right choice of hardware and scaling techniques are essentials of design time.The grid computing is highly scalable and robust but then the choices made are highly dependent on what requirements one has.