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

Source: http://en.wikipedia.org/wiki/Service_catalog

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

Ownership

Executive Ownership

Erik Deets

ed01@test.domain

Application Ownership

Lenore Leep

ll01@test.domain

Support Ownership

Julianne Obyrne

jo01@test.domain

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

Sql1@test.domain

 

2nd Level Support

SQL Admin – LVL 2

Sql2@test.domain

Operational Staff

1st Level Support

TEST\SQL ADMINS – LVL 1

TEST\SQL ADMINS – LVL 2

 

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.