Organizational and process changes are required to leverage SOA

I have been observing the time it takes for organizations to move applications into production after development is complete and this is a matter of concern as this process seems to be the same regardless of the size of the application that is being deployed. Building and deploying business components as opposed to packages is a much smaller project. Examples are address change, Policy Inquiry. These are discrete functions and typically the development process is weeks and not months or years. Currently development, QA and testing groups are seperate organizations and the QA/testing groups typically are brought in after the development cycle is complete. The testing has to be done with data from several backend systems and the setup time is the same whether you are rolling out 1 component or 10. This adds significant time and cost to the project and some of the benefits of using pre-built components and a rapid development process is lost.

There is a need to change the process, organization and testing infrastructure in order to cut down the time it takes to put components into production. From a process perspective the teams should include developers and testers right from the beginning. Organizationally the development and deployment of business services ( components) should be with a single group in order to cut accross organizational boundaries and rigidity. In terms of testing methodology and infrastructure this has to be planned for a group of components and the investment made upfront even though the deployment schedule may involve only a few components in the initial cycles.