Service Lifecycle Management

Services, like all other development assets and applications have their own lifecycle and as such need to be managed through their lifecycle state transitions.  A Service lifecycle generally models a typical SDLC with stages including design, development, test, QA, production, and deprecation.  Many organizations will add versioning into the process between production and deprecation, although in reality each new version of a service will have its own lifecycle.

An SOA Governance product must be able to manage the lifecycle stage of a service and should provide a workflow-based process for migrating services between stages.  Often this process will closely mirror the original publication process described above.  It will include a set of policies that define criteria a service must meet before it can be migrated.  It will also in many cases include manual approval steps.

The lifecycle stage of a service should be used to determine who can discover the service in the registry and who can access the service at run-time.  It should also define which policy set is used to determine the run-time capabilities and requirements for accessing the service.

In the context of lifecycle management, the act of publishing a service to a registry so that it can be found by a broad audience of interested parties may seem like a simple enough task.  In fact, this is one of the most basic, and yet most important functions of an SOA Governance solution.

The essence of governance can be easily captured in the phrase “encouraging desired behavior.” This simple concept provides a backdrop to help understand what a governance solution should be focusing on, and the capabilities it should provide.  Essentially it is not enough to merely provide a stick with which to beat developers and architects, we must also provide a carrot to encourage people to participate in governance processes.

With this in mind, we need to think about what is the desired behavior for the participants in an SOA.  For many organizations, one of the most important aspects of SOA Governance is the process of ensuring that the services that are published are appropriate.  “Appropriate” in this context is another word a little like “desired.”  It can mean many things, but the reality is that an “appropriate” service is a service that meets a set of criteria defined by the enterprise, often including the following:

  • Is not a duplicate of, or similar to an existing service
  • Meets design criteria for transport, operation type, schema, etc
  • Is at an appropriate level of business functionality granularity (e.g. a ‘top-down’ design rather than ‘bottoms-up’)
  • Is of broad interest and therefore likely to be reused
  • Complies with appropriate industry standards and recommendation (e.g. WS-I basic profile)

Some of these criteria can be readily automated like WS-I basic profile compliance, others will likely require manual steps.  To this end, before a service can be published it should pass through a workflow process that will verify the automatable criteria before requiring a manual approval step.  A well designed SOA Governance solution will manage this workflow as a series of customizable, automatable defined process steps and will allow developers and approvers to see services at appropriate phases of this process.

Akana’s Repository Manager and Policy Manager products combine to provide a comprehensive SOA Lifecycle Management solution.  They share a common state-machine, and common meta-model providing seamless SOA asset lifecycle management capabilities.

For more information about Akana’s market-leading products, click here.