Concept: Service Portfolio
This concept addresses the idea of an IT-centric services portfolio that is maintained at the organizational level. We discuss approaches for categorizing and maintaining the portfolio elements.
Relationships
Related Elements
Main Description

"IT portfolio management" -- the application of systematic management to large classes of items managed by enterprise IT capabilities -- presupposes that the items being managed are reasonably well understood. Traditionally, we have dealt with portfolios of applications and projects.  As the industry moves toward the use of services -- generally much finer-grained than applications -- to realize business functions, understanding and effectively managing the portfolio of services that an organization uses and/or maintains becomes increasingly important.

The Enterprise View

Both projects and development teams have a limited scope and also a limited visibility into the wider capabilities, requirements and goals of the IT services and more importantly the business the services support. It is therefore critical that, during the move toward Service-Oriented Solutions and the horizontal view of integrated solutions, the architects on the IT side are able to visualize the portfolio of services supporting the business solutions required for the business itself to operate. One advantage to modeling services is that an abstract model is able to elide certain details and therefore present the broad view of the service portfolio in a scalable manner.  In the presence of many services the model is able to present views of the portfolio, supporting decision making for the SOA Architect and the Application Architect.

As organizations transition to Service-Oriented Architecture, there will be a growth in services.  So, the portfolio will not start as a large model, but it is possible to capture the state of the transition in terms of available as well as planned services. Service Partitioning is also vital in organizing the model and categorizing services as the portfolio is developed.

Categorizing Services

By Service's Lifecycle

From a lifecycle perspective, we can think of Candidate Services, services that are under development, and services that are in production.  Candidate services (Capabilities for which a service exposure decision has not been made) can be organized and described within a separate Candidate Services Portfolio, if desired.  If the organization wishes to lump all services together into a unified list, some information with respect to service lifecycle state needs to be associated with each service.

By Organizational or Functional Considerations

We commonly see categorization language in terms of a service's purpose, ownership, or organization.  As has been mentioned before, some type of partitioning strategy that realizes the chosen taxonomies needs to be used. 

For example, the following diagram (or some variant) has been developed by a number of companies to help visualize the "types" of services in the portfolio. This categorization, while common, is simply one possible way to segment the service portfolio. 

Diagram is described in the textual content.

  • User Interaction Services are used to describe how the user interacts with the application; for example, for a service that might need to assign work to a human user, there needs to be services that know how to notify the user of this work and then notify the originating service of the work completion.
  • Application-Specific Services are services that are developed as a part of a development activity that have been deemed as not appropriate for reuse and so are not considered a part of the portfolio. It is also possible that, as services are composable entities, that a service might be part of the portfolio, yet nested services it uses are not published.
  • Process Integration Services are services, usually provided by commercial middleware, that provide the choreography of services so that processes can be enacted in the middleware and utilize the services in the portfolio to implement a process.
  • Information Integration Services are again commercial middleware services that provide services for the mediation of data formats and message content between services. For example, a customer message can be generated by the service which is an aggregation of data retrieved from other services in the portfolio.
  • Business Services are those services specific to the business, developed for the business, and providing direct support to the applications developed to support the business. Examples might be CustomerMgmt, Inventory, HR, etc.
  • Infrastructure Services are services that provide common IT functions required not only by the Business Services but by the integration services as well. Examples might be Messaging, Directory, Authentication, Legacy access, etc.

Service Repositories 

So, apart from a model of the service portfolio, it is important that Designers and Developers have access to service specifications in a detailed fashion at design and implementation. It is also possible for multiple services to implement the same specification.  So, a registry allowing queries of the form "all services implementing the IOrdering specification" enables developers to compose solutions from existing services, and integration developers to identify which services to use to satisfy business or technical requirements.

Service repositories are also able to use the classification values introduced using the service partitions above to pre-populate the values as meta-data describing the services held by the repository.

For example, a solution might call for a shipping service.  The registry might identify three services that provide shipping.  Two provide secure message exchange.  One does so over Java Message Service (JMS), while the other provides SOAP over HTTP. Business requirements only specify that customer information be kept private, and so a secure message exchange is required. IT standards recommend that JMS not be used to a remote service, and so we have narrowed down our choice.

The following presents some of the technical implementations available currently for service registries.

  • UDDI; The web services standard registry, this has wide adoption and was intended to support both development and integration time queries. However, the level of customization required to keep track of all of the data associated with a service specification has certainly led to some questions about whether UDDI as it stands today is enough to support the enterprise service portfolio we discuss here.
  • RAS Repository; The Reusable Asset Specification was intended to support a customizable meta-data description for reusable assets, and does have a meta-data profile for web services. While it was not the intent for RAS to provide a service portfolio, it would be possible to do so for development time meta-data, although it is not currently appropriate for integration time queries.
  • Custom; Many organizations, faced with these choices, have chosen to implement custom service repositories, managing a set of meta-data or design documents for services at design time and associated web service artifacts for implementation time. In most cases a separate UDDI repository is then used when deploying production services for integration time queries.  
More Information