Hybrid Cloud Cookbook: IT Service Catalog Design
In this blog I’m touching an important concept of true cloud – self-service and service catalog. These concepts are considered to be the above the line part of ITaaS, which is visible to the users. On the other hand, the below the line part is automation, which I have covered in a separate blog. Note that services can be consumed both through portal and the application programming interface (API).
The service catalog is much more than a page in a self-service portal. It is where you set and implement your IT policies in the self-service world. With this, when you define your service catalog, you need to define all of the elements needed to deliver ITaaS in addition to any policies and contracts (as depicted below.
- Characteristics: what you get as part of the service (both fixed parts and user selectable parts)
- Policies: the optional and mandatory policies you associate with the service (like data protection, compliance or approval thresholds)
- Contract: cost of the service, SLA, reporting of the usage, etc. Also, how and when the service is terminated.
Many Levels of Services
A typical service in a service catalog would “provision one Windows 2008 server.” A service can also be directed to an end user audience such as “onboard a new employee” or “deploy development environment”. In turn, such end user facing services are often composed of lower level services, sometimes described as service elements. You can think of the services in a catalog as a hierarchy, where multiple low level services are used to accomplish a more complex service (as seen below).
Approach for Building a Service Catalog
Building a comprehensive service catalog is not a trivial project, so you also need to think of how you approach it. You have two fundamental approach choices – top down or bottom up. Top down means that you publish a service item to the catalog but you do not necessarily have the entire technical solution in place to deliver the service in an automated fashion. On the other hand, the bottom up approach means that you build the low level, fully automated technical services first, and only then start to build more complex higher level services.
Technical IT staff usually prefers the bottom up approach (needs to be 100% ready before you release something) but I personally prefer the principle of agility – only build for need. You can go ahead and publish your top 20 or 50 services and only implement a bare minimum technical solution (for example, an email to the appropriate person who would then do it the old way). Only when you learn which services are actually needed will you start to build the low level services below it with the associated automation. The benefit of this approach is that it starts teaching the organization to use the self-service catalog and to start thinking about your IT as service. Expectations must still be managed for execution time, as this does not improve much more due to the provisioning still being performed the old, manual way.
In real life, you seldom attain (and should not attempt) to have a fully implemented, end-to-end, automated service catalog. There are several reasons for this. First, such an investment is quite substantial. You may reap most of the benefits by focusing on a smaller set of critical or frequently consumed services. Secondly, not all business services easily lend themselves to automation or to such a hierarchical delivery model. In such cases, it makes more sense to still use humans as the service integrators and equip them with the tools, skills and rights to do that.
The last point to consider is governance and user rights – who can do what. A good self-service portal allows user group specific views and shows only allowed services. You need to consider both “right to do” and “skills to do” aspects. Technical services are usually too complex for non-technical users, and even for technical users, you want to limit how big the services are and how many of them they can go and provision automatically without any control (cost, capacity, etc). You also need to consider segregation of duties and compliance aspects.
Implementing a service catalog is a main element when it comes to using the cloud. Similar to what I explained in my automation blog, I suggest not overdoing the service catalog design. Instead, it is better to build it as a process where you learn what is important to your organization, as neglecting the basic parts can lead to situations where fully automated self-services lead to a dramatic rise in cost (no control, unlimited term, etc.), and to compliance and user satisfaction issues (too complex and services that are too technical).
In my next blog, I will write about new role and skill requirements.