A Services Lifecycle
Recycling some older bits for another test post to Medium. I’ve almost got it working but the titles aren’t coming through properly…
This post is a bit old but much of the content is still relevant. Feedback is always welcome!
Services, like applications, participate in a lifecycle in which they are designed, developed, deployed and eventually retired or replaced.
A Service comes to life conceptually as a result of the rationalization of a business process and decomposition and mapping of that business process into the existing IT assets as wells the new IT assets to fill the gaps. The new IT assets once identified will be budgeted and planned for SDLC activities that result in deployable services (assuming that our goal is to create reusable IT assets).
Following are various important activities that happen (not necessarily in this strict order) during the life time of a service from the service provider perspective:
Service Analysis is the rationalization of business and technical capabilities with the express notion of enabling them via services. Other aspects such as SLAs, localization / globalization, and basic service contracts will be established for future use in the life cycle.
Rationalization of contracts and designing new contracts will be one of the primary activities in this phase. Object libraries supporting the service implementation will be acquired or designed. Security policies, trust boundaries, authentication/authorization, data privacy, instrumentation, WSDL, etc. will be the outcome of this phase. Distributing WSDL or service consumer proxies will be strategized during this phase.
Services will be unit, smoke, functional and load tested to ensure that all the service consumer scenarios and SLA ranges are met.
Service metadata as identified in the “Service Consumption” will be deployed into the directory. This will be associated with a deployment record into a repository that models deployment environment. Supported SLA policies will be an important metadata for successful operation of a service. Service gets a production endpoint in an appropriately designed production infrastructure. Support teams will be trained and appropriate processes for support among various roles (business versus IT) will be established. Access to service consoles and reports will be authorized to these roles.
This is the most important activity since the ROI will be realized through the operation of the services in production. The management infrastructure will do the following:
- Service Virtualization
- Service Metering (client usage metering and resource metering)
- Dynamic discovery of service endpoints
- Uptime and performance management
- Enforce security policies (authentication, authorization, data privacy, etc.)
- Enforce SLAs based on the provisioning relationship
- Generate business as well as technology alerts for a streamlined operation of the service
- Provide administrative interfaces for various roles
- Generate logs and audit trails for non-repudiation
- Dynamical provisioning (additional instances of the service as necessary)
- Monitor transactions and generate commit/rollback statistics
- Integrate well with the systems management tools
- Service, contract and metadata versioning
- Enforce service decommissioning policies
- Monetization hooks
This activity is equally applicable to service consumers and providers as providers may consume services as well. During this activity, services will be discovered to understand the following:
- Service security policies
- Supported SLA policies
- Service semantics (from the lifecycle collateral attached to the service definition)
- Service dependencies
- Service provisioning (will be requested by the consumer)
- Pre and post-conditions for service invocation
- Service development schematics (proxies, samples, etc.)
- Service descriptor artifacts
- Service impact analysis
- Other documentation (machine readable as well as for human consumption
During this activity, service consumers will be authorized to discover the service and its metadata. SLAs will be pruned to meet the desired level of availability based on the negotiated contract.
Service Change Management
Service like any IT application asset will go through several iterations during its lifetime. Service contracts will change, service security as well as SLA policies will change, the implementation will change, and the technology platform may change. Some of the above changes may be breaking changes. So, the management infrastructure has to be resilient for all the mutations by providing necessary deployment support across all the above changing dimensions.
As a result of a change in the business strategy or as a result of better alternatives or as a result of waning consumer interest, a service may be decided for decommissioning. Management infrastructure should be able to enforce retirement policies by gracefully servicing the consumers until the last request.