I introduced the Cisco Domain Ten^SMframework for data center and cloud transformation back in December, and after my previous blog discussing "Domain 4: the User Portal", it's now time to discuss Domain 5, which considers Service Catalog and Management.  In this post, I'd like to illustrate the important, central role the service catalog has in data center transformation, and also discuss some of the key challenges, considerations and deliberations you should go through as you specify the requirements for, and ongoing evolution of, your IT service catalog.  I'll also point you to a free white paper from our Cisco Services experts.

With automation and self-service being a major focus in modern data center design and evolution, and with the notion of "Self Service" being integral to the definition of cloud (see for example the NIST definition), it should be no surprise that "Service Catalog and Management" is one of our ten domains of data center and cloud transformation.   If you think about it, the concept of well specified, designed and constructed offers is the way the vast majority of organizations have scaled their go to market offer, so it's logical that (eventually) IT should adopt a packaged approach to IT services.  While the concept of the IT service catalog has been around for a few years now, it certainly wasn't common when I started working in IT (showing my age here ).    If you are interested in the historical evolution of the concept of an IT service catalog, my colleague, Rodrigo Flores, wrote an excellent blog post on "Workplace Services. A Brief Personal History of the Service Catalog and Its Evolution" -I'd recommend reading that if you're not too familiar with the history here.

Today I'd like to discuss in this blog are key considerations you should bear in mind when specifying and designing a service catalog.  I will not claim here that these are the most critical considerations, however in my opinion, they are some of the more interesting challenges and/or some of those that are sometimes forgotten about, when  -as all too often happens -the pursuit of the technical evaluation of  "which service catalog tool will we choose" takes over from  the business priority of "what services do we need to run our business, what are the impacts and opportunities" and so on.

(1) The Purpose of a Service Catalog

Let's not forget this.  The purpose of a service catalog is to enable simple service ordering for your customers and/or end users.  It's about making IT easier to do businss with.  It's not (just) an exercise in GUI design nor is it about exposing every service option you can think about (or everything that your customers/stakeholders may ask for! -see following items).

(2) Convincing Your Stakeholders

If you don't have a service catalog already, you'll need to convince your stakeholders that you should introduce one. As with any organizational change, as leading management guru John P. Kotter points out, if often not straightforward.  Information Week's "10 Steps to an IT Service Catalog" discusses the adoption challenges and others that you may need to overcome when pursuing a service catalog approach.

(3) Clearly Identify Your Target Audience

You should be clear on this.   While you can target expert IT users with your service catalog, the real intent of a service catalog in cloud is to enable non-technical users to exploit IT service in a self service, automated manner.  Design your catalog to require knowledge of "LUNs" and the like, and you are restricting your catalog to IT experts.

(4) What Services Should be in Your Portfolio?

Before you build services into a catalog tool, make sure you specify and validate the services required by your end user/customer/stakeholder.  Is there a business case for each service?  Will they be used frequently enough to justify your packaging investment?  Will they be profitable and/or save you money?  Make sure their implementation is feasible.  What options should be in your service?  Is it too complex? If not sufficiently sophisticated, end users will keep asking you for custom work packages (preventing your to scale and costing you more OPEX).  I already talked about the need to standardize components of infrastructure in my Domain 1 blog, in order to achieve the promise of cloud.  Likewise, here with the service definition, you need to standardize the definition of your services into repeatable building blocks.

(5) Who Will Manage Your Service Portfolio?

And I don't mean the IT administrator here.  As you develop more services, we'd recommend you consider adding/appointing a formal "service product manager" to your team, who drives the definition of your services and their evolution, and who is responsible for ensuring that what your engineering team design and build meets the needs and expectations of your end user.

(6) Which Service Catalog Tool to Use -The User Portal

OK I will talk about tool choice   The choice of tool for the User Portal is what can get technical folks really excited and interested.  I've discussed the User Portal in my Domain 4 blog.   I will note here that a service catalog doesn't need a tool (although clearly a good one helps!). You can implement a service catalog on paper.  You could define your chosen cloud services and gain some of the productivity and costs benefits of cloud, without a tool.  Of course manual processes have limits, and there is more scope for error.  A good service catalog tool however does enable you to realise more benefit, and faster.  However don't forget that it's the market relevance [service provider] and/or stakeholder relevance [business/enterprise/organization], and value, that you package appropriately into your service portfolio that delivers on the promise of cloud: the best tool in the world with service definitions  that your customers/stakeholders don't want to use will quickly become "shelf-ware".

As tool of choice, we recommend the Cisco Cloud Portal, part of Cisco Intelligent Automation for Cloud.  This has been evolved from our newScale acquisition.  newScale was already one of the leading service catalog companies when we acquired them a few years back, and we've invested substantially in further development since then, to make it even better and tightly integrated with the Cisco Process Orchestrator, in order to deliver a complete solution for cloud automation and self-service.

I could write on.  Cisco Services' experts stand ready to help you with these challenges -you don't need to conquer all  these on your own.  We have the expertise at hand, globally, to help you and your team be successful in service catalog design and evolution.

I hope I've convinced you that service catalogs and their design is a fascinating, challenging and very valuable topic for you to invest in.    The service catalog  has a central place in data center and cloud transformation, and therefore in our  Cisco Domain Ten model.  If you're interested to read more on the design considerations, please consult our free white paper "The Need for Service Catalog Design in Cloud Services Development" from our Cisco Services experts, and please do get in touch when you need assistance in your specification and design -our Cisco Services team have "been there, seen it and done it" and are ready to help you!