SOA is hard. While the payoffs can be biggreater agility, increased efficiency, etc.doing SOA right requires some significant changes to the traditional development lifecycle.
Or, more appropriately, it requires a rededication and realignment of the traditional development lifecycle. Especially when it comes to capturing the benefit of reuse.
Service oriented architectures require services, and to use more than one service you need to have a way of keeping track of services. Reusing services requires the ability to find, identify and use pre-existing services. Hence the rise of SOA service registries. SOA registries are services which themselves keep track of other services. Organizations can use service registries based on web services standards such as UDDI to help them identify and connect to appropriate services for their needs. It’s the initial step toward creating an environment where services can be re-used.
But, SOA registries aren't enough when it comes to creating an effective and efficient SOA infrastructure. What’s needed is a collaborative SOA environment.
Organizations of all kinds are turning to SOA solutions to make their business more effective and their IT more efficient. However, leveraging SOA requires more than simply implementing standards-based services--it also requires creating and maintaining a collaborative environment for service identification, definition, development, deployment, management and revisioning.
The transition to SOA is more then a revolution in the how to break down applications and functionality into bite-sized services that can be composed into processes or composite applications to deliver business functionality. It’s also a change for development organizations and the development, deployment and management process. Part of the problem is that monolithic or hierarchical development organizations with responsibility for monolithic (or at least cohesive) projects need to be able to transition into discreet teams and smaller groups that are responsible for specific services that may be used across a wide range of applications.
In some regards, the transition to SOA-enabled development organization is analogous to creating a mini-ISV within an organization. The SOA development teams might be broken down into groups of 15 or so IT people and include architects, developers and testers (as well as potentially support personnel) working together to support services throughout their lifecycle.
-1-