Five best practices for deploying a successful SOA
Scope creep can also be a contributing factor that leads to poor project results. A best practice is to have a control on the scope of exactly what is included in the pilot or proof of concept. Without this, the project can spiral out of control and not achieve the stated objectives. It is important for the project manager to encourage continual feedback, along with frequent review points and demonstrations. The project manager will also need to translate the experience from a proof- of-concept technical jargon into business vocabulary when reporting to stakeholders. This feedback and communication will help drive the project toward successful completion.
SOA enablement requires use of the latest technology features and product versions, so you will need to provide continuous training and mentoring to reduce risk. Time to install products tends to be significantly underestimated. Integrating various software, hardware and services can be difficult and time-consuming, so even though products may be designed to work together, they may not be easy to implement.
Ensuring the scalability of your SOA Like the case studies evaluated in the IBM study, your SOA implementation will most likely involve hundreds of connections. As much as you can, use known solutions to meet reliability and performance requirements. Then design, test, and retest to confirm that your performance, scalability and interoperability requirements are met. Never deploy a solution without properly addressing and testing these nonfunctional requirements.
A best practice is to utilize standards-based compliance test tools, enforcing compatibility checks as part of the development process. You can also leverage product functionalities such as mock services, which are part of the IBM WebSphere® Business Fabric, to get an early indication if business objectives are being met. Create a baseline for your Web services performance using appropriate instruments and measurements for your Web services so that you have some tangible information to compare and improve upon. Finally, for planning purposes, keep in mind that given the number of variables in a SOA environment, your staff may need to generate a significant number of test cases—and plan for this accordingly.
When lack of requirements, schedule constraints or variable system requirements do not allow for formal capacity planning and server acquisition, you should utilize automation and virtualization to provision a test environment. Finally, always validate your SOA implementation with a technical architecture review from an independent consultant or test lab. This validation will give you the confidence that your architecture and the products selected will operate within the expected performance envelope.