img > Issue XLVI: January 2011 > Service Portfolio Management - Part I
Toufic Boubez

Toufic Boubez


Dr. Toufic Boubez is a well-respected SOA and Web services pioneer and co-author of the SOA Manifesto. He is a Certified SOA Architect and Security Specialist, as well as a consultant and Certified SOA Trainer for SOA Systems Inc. He is the founder of SOA Craftworks and the founder and CTO of Layer 7 Technologies, one of the most successful vendors in SOA Governance and Security. Prior to Layer 7, he was the Chief Architect for Web Services at IBM's Software Group, and the Chief Architect for the IBM Web Services tools. At IBM, he founded the first SOA team and drove IBM's early XML and Web Services strategies. As part of his early SOA activities, he co-authored the original UDDI specification, and co-authored a service description language that was a precursor to WSDL. His current activities span SOA Security, SOA Governance and the impact of Cloud Computing.

Toufic is a sought-after presenter and has chaired many XML and Web services conferences, including XML-One and WebServices-One. He has also been actively involved with various standards organizations such as OASIS, W3C and WS-I. He was the co-editor of the W3C WS-Policy specification, and the co-author of the OASIS WS-Trust, WS-SecureConversation, and WS-Federation specifications. He has also participated on the OASIS WS-Security, SAML and UDDI Technical Committees. He is the author of many publications and several books, including "Building Web Services with Java" and the upcoming titles "SOA Governance" and "SOA Security: Practices, Patterns, and Technologies for Securing Services". InfoWorld named him to its "Ones to Watch" list in 2002, and CRN named him a Technology Innovator for 2004. Dr. Boubez holds a Master of Electrical Engineering degree from McGill University and a Ph.D. in Biomedical Engineering from Rutgers University.


rss  subscribe to this author


Service Portfolio Management - Part I

Published: January 15, 2011 • SOA Magazine Issue XLVI PDF


Service portfolio management is the discipline whereby an organization creates and maintains the optimum set of services to support its mission of solving specific business problems and enhancing overall business agility, flexibility and operational efficiency.

This article will focus on two important SOA constructs, the business service model and the service portfolio itself:

  • Business Service Model – is an abstract representation of how an organization conducts its business operations, which describes the workings of part or all of the organization in terms of a set of business services. Business services represent functional capabilities exhibited by one part of the organization (the service provider), that provide value to other parts of the organization (service consumers). The service model is purely conceptual; it describes what the functions of the business services are, but contains no information as to how they are implemented.
  • Service Portfolio – is a real physical object, consisting of the set of services from the business service model that are planned to be or have already been physically realized in the form of software assets. The service portfolio thus represents a primary SOA asset of the organization. Once services have been selected for development, they spend the whole of their lifecycle in the service portfolio.

Figure 1 – The relationship between the business service model and the service portfolio.

We will describe an approach to identifying the optimum portfolio of physical services based on the prioritization of business needs, the use of business modeling to capture detailed service requirements, followedby an estimation of the feasibility development effort required for each candidate service. We will close with an explanation of the lifecycle of the service portfolio.

The key aspects to consider with respect to service portfolio management are:

  • Which business and IT organizations have significant input into the planning of the service portfolio.
  • The processes for identifying and approving the future development of services to expand the service portfolio.
  • How the service portfolio will be used with the Service Lifecycle process (for example, SOA governance should ensure the reuse of existing services instead of building new ones whenever that makes sense).

Organizational Guidance and Planning of the Service Portfolio

Many organizations regard their Information Technology division as a cost center. IT is seen as a vital tool in reducing operating expenses but not regarded as a means to generate business value. However, IT is often considered an inhibitor to business innovation and agility due to the long lead time needed to create and implement effective IT solutions. Even when IT provides a custom or commercial application to solve aparticular business need, the result creates a patchwork quilt of independent solutions rather than an integrated gestalt solution. It is commonplace for IT departments to devote well over half of their resources on maintenance and compliance issues, leaving only a small fraction of IT resources available to support new business initiatives or to provide more seamless systems integration.

Service Portfolio Organizational Guidance

IT departments are often viewed as operating at a distance from the other business divisions, operating to a different set of priorities and being more interested in the technology than the business goals of the organization as a whole.

Many organizational approaches have been created in an attempt to align IT closer with the corporate culture, including the creation of a separate IT group within each business division, but all of these approaches have their own issues. Creating a central Program Management Office with a remit across the whole organization and requiring the majority of Business Analysts to report directly to a business departmentare effective approaches, but they only partially address the alignment of business and IT.

The key to success in any enterprise is to identify your customer base, determine what those customers need, and provide that at a cost that the customer can afford. In many organizations, different divisions and operating units usually compete for the available resources, with each division head attempting to demonstrate that their individual business issues should take priority over those of any other division. Typically, IT resources are assigned by approval or disapproval of specific projects, where the winners gets all or most of what they ask for and the losers get nothing. Often, the decision to support one project proposal over another is affected by political considerations.

SOA certainly offers a potential solution to create holistic and agile IT solutions, but the portfolio of services provided by IT needs to be planned carefully to ensure that IT is focusing its effort and energy on creating those services. Effective service portfolio Management is the key to producing real synergy between business and IT. The service portfolio should represent a contract between IT and all other business operating units that formally defines the mutually agreed development priorities.

Planning How the Service Portfolio will be Governed

A good service portfolio planning process can help to de-politicize the selection or rejection of IT projects and ensure that IT resources are used in a way that provides maximum business leverage.

An optimum service portfolio should manage the development and deployment of a set of services that:

  • matches the value and urgency of the associated business needs
  • most effectively supports the organization's business goals such as operational efficiency, profitability and business agility
  • can be realized cost-effectively, using the IT skills and resources available, in a reasonable timeframe

This approach to managing the service portfolio involves the following steps:

  • Understand the organization's consensus on business vision, strategy, focus areas, objectives and investment priorities to define which areas of the business should receive the most attention, and in what priority. This involves the creation of a 'heat map', showing the critical focus areas within each business domain (business unit or division), followed by an overall prioritization process.
  • Match those business priorities to specific business process improvement opportunities that define a target set of business capabilities to support all of the key business objectives and assign ownership or sponsorship to each of them.
  • For each high priority business capability, create detailed models that describe the associated business processes. Typically, this will create a hierarchy of business processes and sub-processes that have many interdependencies that the business models need to reflect. For each process or sub-process, the Business Analyst should determine specific business requirements, rules and any constraints that apply, as well as establishing the timing, inputs and outputs of each process.
  • Transform those business processes into business services, by defining the logical or physical entities that act as their inputs and outputs.
  • Since the set of possible candidate business services will probably by now have grown quite large, there needs to be a prioritization process to establish the most viable set of physical services for IT to develop, given their available resources. This prioritization process needs to be performed by experienced technical professionals, such as solution architects and service architects, who can assess the feasibility and likely effort required to develop IT assets to provide or support each of the identified business services.

This process for producing and prioritizing the service portfolio should not be seen as a one–off or an annual event. Rather, it should be an ongoing dynamic process, with all steps repeated regularly, to ensure the continued vitality and maturity of the service portfolio.

Governing the Process of Creating the Service Portfolio

Defining the Business Priorities

Within a well–run organization, good enterprise governance practices should set and refine the business priorities every year. Typically, this business prioritization process works as follows:

  • The CEO, President, and other senior executives meet to set the organization's key strategic objectives for the next year. Typically, these are broad in scope and change relatively slowly year–to–year.
  • The functional management heads receive these corporate goals and develop their own specific goals that support the key strategic objectives. To be of value, these goals should be associated with quantitative target metrics.
  • The functional management heads meet, in a structured workshop, to share and peer-review their functional goals. The head of IT should naturally attend this workshop, since IT is just another functional group.
  • The CEO, President, and other senior executives meet again to review and confirm the set of functional goals, then assign priorities to specific business capabilities that they consider to require most focus. Those business capabilities might represent new business opportunities, problem areas requiring better processes or support systems to resolve issues, or candidates for outsourcing or offloading.

A typical visual output from this business priority planning process is termed a heat map, consisting of a series of columns representing individual business units, each containing a set of capabilities or responsibilities of that unit. Those 'hot spot' areas that require specific attention are shown in a different color. Separate explanatory text describes the type of attention that each focus area needs. The creation of a heat map begins with the documentation of the set of major business operating units or domains that comprise the organization.

In a well–organized company, each domain will have full responsibility for a specific aspect of the business (such as finance, human relations, and so on). For most commercial enterprises, each major business domain will be controlled by an individual executive, typically a Vice President or Director. The responsibilities of the high–level domains are usually self–evident (such as, an HR domain is responsible for all aspects of personnel management and employee relations).

For most large organizations, many of these domains will be split up into sub–domains or departments, each of which will be controlled by a separate executive or manager. For the purposes of defining a heat map, the top one or two domain levels should generally suffice.

In order to fulfill its responsibilities, each domain has to have certain business capabilities, for example, the ability to perform certain essential business activities. Assigning a business capability to a specific domain implies assigning ownership of that capability to that domain, but does not imply that it is exclusively involved in execution of that capability. Indeed, most business activities involve interaction between multiple business domains. Developing the heat map begins by creating a list of the capabilities owned by each domain.

The next step in heat map construction is to define which of those identified business capabilities need to be improved or enhanced in some way to meet specific corporate strategic goals or business objectives for any of the following reasons:

  • business capabilities that are strategic but are considered to be performed ineffectively
  • one or more new business capabilities to reflect new business opportunities or threats
  • business functionality whose performance needs to be improved
  • areas of business activity that need to be downsized
  • business activities that might be candidates for outsourcing or selling off

The easiest way to document these hot areas is to use a different color – typically red or orange – to indicate visually those 'hot' business capabilities that need to be enhanced. This is how the term 'heat map' originated. This heat map is a major input to maximizing the contribution SOA makes to business value and ROI.

There should be no sense of blame – or credit – attached to the domain that owns a 'hot' capability. Any domain without 'hot' areas may well just be performing efficiently, while the presence of hot spots might just indicate the effect of market forces.

What is essential is that the key executives of the organization reach consensus on what these hot capabilities are. Structured workshops are an effective mechanism for achieving such common agreement.

This heat map is a major input to the service portfolio, as it represents a consensus view of the business priorities, at least at a high level. It has the additional benefit of providing a high–level view of the internal structure of an organization.

Business Capabilities and Business Processes

The next step in the service portfolio process that requires governance is the identification of the new business capabilities that need to be created and the existing business capabilities that need to be enhanced. The business capabilities described by the heat map effectively prioritize the business problems to address but do not, at this stage, provide much of an insight into how those problems may be addressed.

Governance must first ensure that that the stakeholders for each strategic business capability have been identified. Stakeholders are those individuals or business units that are impacted or likely to be impacted by any new or enhanced business capabilities. Stakeholders should be interviewed to establish which business processes need to be created or enhanced to meet the required business capabilities. It is likely that additional stakeholders will be identified as the number of target business processes increases.

For any given business process needed to create an enhanced capability identified by the business heat map, stakeholders will include:

  • The owner of that business process, who may very well be someone other than the owner of the business capability identified by the heat map.
  • All users of that business process, who might be individuals, other business operating units or other business processes.
  • Individuals involved in performing that business process.
  • Any party involved in monitoring that business process, or who will be affected by the way that process is performed.

As additional constituent or related business processes are identified and their stakeholders interviewed, the Business Analyst should attempt to identify and answer the following questions (at least at a high level).

  • What specific business needs does that stakeholder have for the process?
  • What success criteria would that stakeholder apply to the execution of that process?
  • What additional major business processes would be impacted (favorably or otherwise) by changes made to that business process?
  • Are there any additional stakeholders for that business process that should be consulted?

At this stage, governance should ensure the analyst is creating a list of the major business process enhancements needed to achieve each required business capability, rather than a detailed description of how those business processes are carried out (that level of detail is established in the next step of the portfolio management process). Typical leading questions the Business Analyst might use are:

  • How would you or your business unit be involved in providing this business capability?
  • What do you believe the success criteria are, and do you agree with the success criteria established so far?
  • What inhibitors are there to you meeting these success criteria?
  • What or who could help you achieve these targets?

Responses of the type "Well, I would need to be able to....", or "I can't do that because..." should provide an experienced analyst with a candidate set of business processes – or perhaps business relationships – that need to be improved.


Both the business and IT must be involved in the service portfolio planning process. A good service portfolio planning process can help to de-politicize the selection or rejection of IT projects and ensure that ITresources are used in a way that provides maximum business leverage. In Part II of this article, we will be looking at business requirements gathering and the steps necessary to identifying business entities.