"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.
-
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.
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.
|