Doing SOA right is not only hard, but it can be a bit like a movie director pitching an idea to a Hollywood studio: once you’ve sold them the idea, the real work begins. (But that, of course, is completely ignoring all the hard work and refining it took to just get to the meeting and make the sale).

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 but it’s really 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.

In my previous column, I brought up the concept of SOA registries and their ability to track services. But what’s needed to support the entire lifecycle requires more than just tracking the technical aspects of services—it also requires that companies set up ways to track, communicate and collaborate on the definition, creation, deployment and management of services.

Registries are great for keeping track of some of the programmatic requirements for services, but they don’t necessarily help you learn about the service—they can’t help you understand when and where to use a service or how to use the service, they can’t provide suite of associated test modules, and they don’t necessarily provide insight into the definition or requirements or discussions that went into the creation of the service.