*Editor’s note: This article is an expanded version of The SOA Collaboration Challenge, published in May 2006 on ebizQ.

Moving to SOA isn’t just about implementing new technologies, defining interfaces and creating services. It’s also about creating, fostering and enabling a more collaborative development process and collaborate technology environment that most organizations are used to.

While the payoffs from transitioning to SOA can be big—greater 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.

With SOA, the work begins when a development team starts to create a new service—but the work actually starts once that service is successful and the team needs to find efficient ways to support that service across multiple applications and across different projects throughout a company, coordinating updates, providing support, and ensuring consistency and quality over time and over different forms of deployment.

As a result, SOA development isn’t just about development. It’s also about collaboration and lifecycle support. Doing SOA right requires taking the longer view with an understanding to not just how services will be used, but re-used. You also need to understand what it will take to actually support, service and upgrade those services as they fan out across a distributed organization.

For example, a developer or business user may be using a service that was created by another department or IT group. What happens when they want to report a problem with it—theoretically they would contact a support engineer who would help them capture the environmental artifacts that can reproduce the problem for the developers or testers to verify against and fix. The service developer would come in and fix the service, run it through testing, and then release an updated version. The challenge is capturing all the relevant information for that process (and others) in a consistent and usable manner so that different production teams and users are operating effectively and efficiently.

In other words, it’s the SOA lifecycle and reuse challenge. Let’s look at what it takes to meet the SOA lifecycle challenge and make services reusable. 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.