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

Source: https://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.

 

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.