| Backgrounder: |
A Service Portfolio Plan identifies and describes an integrated collection of software services, and defines a set of policies which direct Portfolio Planning and Service Provisioning.
The scope of the Plan is expected to be an enterprise, though it might be narrower than this: for example, an autonomous division of a large corporation. But it is not expected to be as narrow as a single application or a single business process.
We have suggested that the Plan is built incrementally, a business domain at a time. If service-consuming projects are already underway, then the Planning may need to focus on narrower project-related views of the business, but this is subsequently broadened to entire business domains. Generally, the planners are aiming to take a broad perspective on the business, with a view to the services being provisioned to be shared by multiple software solutions and useful within different business processes – so as to reduce redundant logic and data, and to promote consistency.
The Plan includes lightweight descriptions of services, but not detailed specifications. It does not attempt to define every operation offered by a service. That comes when services are provisioned (built in-house, or acquired from external sources). It is generally assumed that services can be provisioned incrementally, growing in functionality over time.
Also over time, the Plan will include a mixture of available and planned services, and may reflect the compromises that have been made, thus displaying a divergence from earlier Planning ideals, in order to exploit pre-existing services or get results faster. So the Plan is intended to be a living document, which progressively shifts from being a vision of the future, to a picture of the available enterprise services.
The Plan (besides being subdivided into business domains) is depicted at three levels of abstraction: the service view, the implementation view and the deployment view
The policies represent a fourth aspect of the Plan. The policies range from general tactical decisions through to rules governing the service lifecycle, the minimum service quality requirements, the industry standards to be adopted and a reference architecture for service design.
This report, however, is not intended as a primer in Service Portfolio Planning, and we need to move on. More information can be found in two earlier Journal articles.
The goal of this report is to explore the possibility of Service Planning being performed within the service-consuming Solution Delivery projects; to investigate the value of a separate service Portfolio Planning team; to challenge the view that services need to be acquired in advance of Solution Delivery projects; and to suggest ways in which SOA responsibilities can be delegated.
|
Home