The ability to enforce policies at run time is very important to SOA. In our example, the need to do this was introduced when the Center of Excellence determined that organizations managing the service must support up to three versions in production. Keeping in line with the definition of governance, the Center of Excellence recognized that the desired behavior was to support the changing needs of consumers while not overburdening the team providing the service. Remember, however, that governance is about people, policies, and process. In this case, the policy exists, but to ensure things are successful, appropriate processes must be put in place. This process is service lifecycle management.

Consider how our example could get worse, despite the policy that was put in place by the Center of Excellence. There were several assumptions that were made by the Center of Excellence in coming up with the policy, largely around the frequency of changes that would be necessary for a service, or a consumer. As an organization embraces SOA, the number of interdependencies between systems will increase. Previously, organizations may have only updated applications every 12 to 18 months, and those updates were self-contained to the application itself. Now, due to the increased number of interdependencies, those updates may involve other components outside of the application's direct control. Look across many applications, and the possibility exists that a service gets one request for a change every month for four months straight, and then a period of no changes for several months.

In order to mitigate this, an organization must change the way that these changes are managed. As a point of comparison, let's look at the interaction that organizations have with their technology vendors. When an organization runs into a bug, or requests a new feature, it normally isn't delivered on its own. Rather, the vendor maps the feature request to their release schedule, and delivers it as part of a collection of features and bug fixes that were requested by a variety of customers. If an organization doesn't adopt a similar approach for its internal development efforts, they run a risk of being crippled by the interdependencies that were intended to increase agility, not stifle it.

Service lifecycle management takes a product management approach to services. Rather than viewing service development as a project that ends when the service is placed into production, the lifecycle of a service needs to be viewed as a process of continual change and improvements, each one occurring through a managed release. This can be a difficult concept to grasp when an organization is used to thinking only in terms of projects.

Next Page: SOA Development - Service Lifecycle Management - Page 2