Many of my recent consulting interactions with service organizations and their customers has been making one strong statement:Visibility_Page_Header

Service Portfolio needs to be brought into a larger mainstream role over Service catalogue in service provider scenarios. Or in other words, Service Catalogue might have to have a larger scope than just the ‘live and currently offered services’.

First, let us set the context here:

ITIL® has been clear on one aspect:

  • Service Catalogue is the only part of the service portfolio published to customers (ITIL® Service strategy publication).
  • Also the diagram in figure 2.6 in the same publication indicates Service catalogue as the only portion of the Portfolio that is visible to customer

In a typical IT Service management scenarios (especially in external, retail service scenarios), this is more or less logical and accurate.

However, in today’s world of ‘so-called’ Business-IT integration (which ITIL® has been describing from its 2007 edition onward), will this be sufficient?

Let us look at the two scenarios of service providers:

a) An Internal IT Provider:

In this scenario, the business units are the key customers for the Service provider (internal IT department or a shared service unit). In this case, if only the Service Catalogue is visible and used in interactions with the customers, will that suffice for an effective business-IT integration?

It is quite apparent that a visibility into the Service Pipeline is highly essential to achieve effective levels of business and IT integration. In the internal Service scenario, the pipeline will be largely driven by the business strategy and priorities, and hence it is important for the business to have a visibility into the Service Pipeline of IT in order to understand and fine-tune (if and as required) the IT’s strategy and capabilities to ensure alignment to business.

So it is clear that, in an internal service scenario, the Service Portfolio (selective portions of the same, in some cases, where applicable) need to be visible to the ‘customer’ organization to ensure proper alignment and integration.

 b) An External Service provider:

Recently I happened to have interactions with the external customers of an IT solution/service provider. One of the key challenges that were repeatedly voiced by the key stakeholders in customer organization was:

  • Lack of visibility into the future solutions that the solution/service provider was planning to offer and/or the roadmap for the existing solutions/services in terms of enhancements and features.

Why is this important to the customer organization? (more…)


In 2003-04, I have led a team of consultants in a Middle East based Bank for adoption of ITIL (at that time V2) practices into their IT organization. One of the deliverables was definition of a suitable Service Catalog framework for the IT Services. We found the guidance in ITIL documentation for Service Catalog to be not adequate enough to satisfy the needs of the Bank.

Through a series of brainstorming sessions and with significant inputs and involvement from the Bank’s IT management, we have zeroed in on a high-level categorization of IT Services into 3 groups:

  • Business Banking services – IT Services that are built into the Bank’s business services – like Core banking applications, Internet banking etc; for which the users are end-customers of the bank.
  • Business Support Services – IT Services that are supporting the bank’s business processes such as email, HR applications etc; for which the users are the Bank’s employees involved in Bank operations
  • IT Internal Services – Supporting services within IT such as System allocations, IP address management etc; for which the users were within IT.

We found the framework to be immensely useful for the Bank’s IT to manage the IT Services in an effective manner.  I have expected to see such guidelines for proper definition and categorization of services to be available in ITIL V3 – but was a bit disappointed (or, I could not find it, if it was defined in some corner of the vast documentation). I always thought that is a significant aspect in IT Service management framework which can have a direct impact on how other aspects/practices in ITSM are defined and governed.

Now, I am happy to see such a Service categorization has been documented in ITIL 2011.  The new revision of the ITIL gives details of Services to be categorized into:

  • External customer-facing services
  • Internal Customer facing Services
  • Support Services – for the interdependencies within IT

Especially the third category – Support Services, clarifies a long-pending confusion for IT outsourcing companies:

IT Outsourcing companies such as those into infrastructure Outsourcing provide services such as network administration/management, Service administration/management, Monitoring etc for which the customers are usually IT personnel in the customer organization. These services were often deemed confusing in the whole discussion of Business-IT Alignment and Integration context.

Now, with this categorization, the services provided by the outsourcing service providers can predominantly fit into the Category 3: Support Services.

While professionals world over were struggling (and many are even continuing to struggle) to get the ‘Service catalog’ right as per ITIL V2, ITIL V3 has introduced the concepts of Business and Technical service catalogues!

These concepts takes the Services in the Service catalog and build their linkages/relationships to Business units and  processes (in Business Service catalog) and underlying IT systems (Technical Service catalog).

However, let us analyze a couple of points : Why these two views of the catalog and How to approach for putting those in place?

Question 1:  WhyBusiness service catalog (BSC) and technical service catalog (TSC)?

ITIL states that BSC will make the SLM process more proactive and pre-emptive.

How? Let us look at it this way: Business is well aware of the criticality and impact of business functions and processes. So, when they need to decide the service levels of IT service(s), the key thing they would like to know is : which all business functions/processes are dependent on that particular IT service(s). Hence, linkages of IT services to the business processes/functions is a key input to the business/customer and the BSC provides just that.

Technical service catalog (as ITIL mentions)  is useful for building of OLAs, UCs etc – from an SLM point of view. Now for a core technical person in the IT, his/her ownership (or responsibility)  might be limited to a particular system or network component or activity within IT. Now, for him/her to understand the criticality of the component/activity, he need to get a perspective of which all services are dependent on (and will be impacted by) that particular component/activity – and the TSC just provides that.

Thus a combination of BSC and TSC will provide an excellent model and view of how the services and underlying components/sub-services are linked to the business.

Question 2: How to build it? (more…)

Can’t help it – but to reinitiate the topic.

ITIL V3 documentation could have handled these topics much better.

I introduced this topic in a previous blog here – on the confusion created about positioning the service porfolio – either in Service Strategy phase or Service design phase.

My discussions with one of the authors of ITIL V3 – Service Design – Mr. Colin Rudd has clarified the same to a great extent- and I blogged about that too.

But the ITIL V3 documentation has much more confusing elements such as below:

  • Designing Supporting systems, especially Service portfolio (Sec 3.6.5 – Service Design): After talking about the statuses a service can undergo through out the life cycle (and as should be updated in the Service portfolio) , the section explains that those Services which are between ‘chartered’ and ‘operational’ will be included in the Service catalog. So we have to understand that even the services in the stages of ‘design’, ‘develop’, ‘build’, ‘test’ etc are also to be included in the Service catalog.

  The same section goes ahead and explains – Service pipeline contains ‘those business requirements  that has not become services released to live environment’. Does this indicate that the services in the design/develop stages are part of Service pipeline also? So where is the clear differentiation/boundary between Service pipeline and Service catalog?