Service Catalogues and The Service Description (Part 1)

Written by Mark Farrugia, Senior Microsoft Premier Field Engineer. A service catalog (or catalogue), as defined in Information Technology Infrastructure Library (ITIL) Service Design, is a list of services that an organization provides, often to its employees or customers. Each service within the catalogue typically includes:

  • A description of the service
  • Timeframes or service level agreement for fulfilling the service
  • Who is entitled to request/view the service
  • Costs (if any)
  • How to fulfill the service


The point of this article is not to go into the full definition of a Service Catalogue, but I do want to focus in on the first bullet defined above – A description of the service. The service description will define in plain language what the service does, what it depends on, which business unit owns it, support details, along with notification details. In addition, the service definition will define the criticality of the service, and its reporting, auditing and security requirements.

When it comes to System Center Operations Manager, the service description will be an Operations Manager administrator’s best friend. As I will post in another article, the true power of Operations Manager is the ability to delegate the console out, and by having all of your services pre-defined in a document, the delegation process will be made considerably easier.

Some major components that should be defined in the service catalogue are:

  • Service name (including any acronyms, aliases, nicknames etc.)

  • Service description

  • Service executive owner – What business division owns this service?

  • Operational support staff and contact details (email, IM, cell phone, etc.)

  • Escalation Points and contact details (email, IM, cell phone, etc.)

  • Service dependencies (does it rely on other services, reference them in the catalogue)

  • Dependent services (what depends on this service?)

  • Service level agreements

  • Reporting and intended recipients

  • Intended run time of the service (24/7?) – scheduled maintenance windows?

  • Is there a compliance requirement to retain the security logs?

  • Monitoring requirements (services, logs, events, configuration data, processes, etc.)

This above can represented by a service map, and this diagram will vary per organization, but this should give you a basic working framework.Service Map


Why bother trying to document your services in your organization? There are many reasons to do so, some of which are:

  • To improve IT and Business Communication by Establishing a Common Vocabulary
  • Discuss Prioritization of Investments in IT
  • Share Information across Geographic and Organizational Boundaries
  • Simplifies Complex Discussions Regarding Infrastructure
  • Start the Conversation with the Business Services that Infrastructure Supports
  • Elevate the Perception of the IT organization to a Service Provider
  • IT can now be Viewed as Providing Value and not just a Cost Center

When defining your services, you can make the definition as verbose or as simple as you would like, as long as it provides meaningful value back to your organization. For the purposes of this posting I am going to build out a simple service definition for my Microsoft SQL Database Service as it applies to my lab environment. (Disclaimer: I have a bunch of randomly generated user names in my lab environment and my lab environment does not represent any real customer data or organization)

Service Definition

SQL Database Service


Executive Ownership

Erik Deets


Application Ownership

Lenore Leep


Support Ownership

Julianne Obyrne


Service Dependencies

Active Directory

Server Platforms



Dependent Services

System Center Operations Manager

Windows Server Update Services

Microsoft Deployment Toolkit



Microsoft Lync 2010



Support Services

1st Level Support

SQL Admin – LVL 1


2nd Level Support

SQL Admin – LVL 2


Operational Staff

1st Level Support




The complexity of completing the following tasks will be greatly reduced when a service is properly documented and catalogued:

  • Console delegation – tells us who to give ownership of that particular piece of the console to
  • Notifications – tells us who to forward critical alerts to
  • Escalations – Describes how we can escalate unanswered notifications
  • Distributed Application Views – build out the appropriate view for proper Service Level Dashboard monitoring
  • Dashboard views – for Network Operations Center
  • Customization of management packs
  • Authoring of management packs – Custom build MPs for custom applications
  • Service Level Objectives

Should you be interested in learning more about Service Definitions with a detailed example, I recommend you go to the following article: Chapter 2 – Service Management. In my next post we will actually apply the concepts discussed in this article to System Center Operations Manager.