This article shows how to design and deploy a very simple, very comprehensive, and very low cost Enterprise Service Catalog (a.k.a. Service Catalog) that makes finding and invoking enterprise services quick and easy.
Understanding the purpose of a Service Catalog
In short, the Service Catalog is a Knowledge Management tool that efficiently and effectively routes people with questions or problems to other people or systems that can help address their questions or problems.
In Service Management terms, the purpose of the Service Catalog (SC) is to efficiently and effectively match Supply with Demand. More specifically, it matches or routes a Service Requestor, who needs to place and fulfill a Service Request (i.e. the Demand), with and to a Service Provider that can fulfill that Service Request (i.e. Supply).
Types of Service Catalogs
There are two core types of Service Catalogs… 1) External Service Catalogs and 2) Internal Service Catalogs.
- The External Service Catalog is specifically for external formal customers of the enterprise, such as a Business to Consumer (B2C) web site that allows customers to explore and purchase a company’s products and services.
- The Internal Service Catalog is specifically for internal employees and consultants who wish to find answers to their questions or find people and systems that can help them get specific work done.
When most people say “Service Catalog,” they are referring to an Internal Service Catalog, specifically for workers of an enterprise (e.g. employees and consultants). The reader of this article should assume that all references to Service Catalog also refer to an Internal Service Catalog, unless otherwise specified.
The Biggest Mistakes IT Organizations Make When They Design and Deploy Service Catalogs
Before discussing the design of a Service Catalog, it’s important to use our professional hindsight to understand the most common mistakes made by many IT organizations, when they design and deploy their Service Catalogs…
Mistake #1: Forgetting to implement consistently named Service Categories, which makes it very difficult for End Users to find the right Services that they really need and want to get their work done.
Mistake #2: Inconsistently naming and representing Service Request Types, which leads to a poor User Experience (UX) and unnecessary End User confusion.
Mistake #3: Designing and deploying a Service Catalog that is not consistently registered, made available with and interlinked within other Catalogs (e.g. Product Catalog, Technology Catalog, Organization Catalog, Capability Catalog, etc.).
Mistake #4: Building an IT Service Catalog that leaves out Business Services. This is a sure way to ensure that your enterprise has different and multiple silo-ed Service Catalogs (a bad idea) and a sure way to upset your Business who sponsors and funds your IT organization (an even worse idea).
Mistake #5: Attempting to use complex Business Process Management Software (BPMS) to orchestrate and automate a handful of service provisioning processes (a.k.a. Service Processes) before designing and establishing most other Services that can exist and function without BPMS solutions being applied. While it’s understood that BPMS is important for critical services, keep in mind that a Service Catalog with only 10 fully orchestrated and automated Services is generally considered pretty useless when compared to a Service Catalog that properly maps out and offers many hundreds or thousands of Services which haven’t been orchestrated or automated through BPMS. Also, keep in mind that applying BPMS is expensive and requires long release cycles. Focusing only on the types of Services that should be orchestrated and automated, while leaving all other Services unattended to, leaves most of the people who need Services without them.
This article provides a framework for designing and deploying a very simple and low cost Service Catalog that addresses all of the above mistakes, with very little effort.
Designing a Simple Service Catalog
The design of a Simple Service Catalog uses a Yellow Pages Pattern (YP pattern) for knowledge management. The pattern consistently names, represents, and makes available, many different Services Categories and Service Request Types. The design also scales to allow for the addition or subtraction of Service Categories, in a consistent manner, and also allows for the customization of specific and non-generic Service Request Types.
Start With Enterprise Nouns to Identify Consistent Service Category Areas
Every employee in the enterprise who delivers something for someone else provides a Service. Therefore, it’s important to identify the things that are delivered by workers to other people. We call these things Enterprise Nouns. Enterprise Nouns are the data entities that represent the things that most enterprises build, deliver, inventory, track and manage, throughout the enterprise. Examples of Business Nouns include: Accounts, Employees, Consultants, Organizations, Products, Services, Sales Quotes, etc. Examples of IT Nouns include: Applications, Software, Laptops, Mobile Phones, Servers, etc.
The IF4IT Taxonomy of Data Entities offers a large list of Enterprise Nouns that you can start with. You can shorten the list or add to the list, in order to customize it for your own enterprise.
Read more about Using Consistent and Standard Service Categories.
Use a Professional Discipline Naming Format to Create Consistent Service Category Names
Given our Enterprise Nouns, we can now create consistent Service Category names by using a repeatable pattern. For example, we can wrap each noun in a professional discipline name…
- Application yields Application Management Services
- Employee yields Employee Management Services
- Organization yields Organization Management Services
- Product yields Product Management Services
- Service yields Service Management Services
The IF4IT Taxonomy of Services offers a large list of Enterprise Disciplines that you can start with. You can shorten the list or add to the list, in order to customize it for your own enterprise.
Using consistent Service Category names ensures a consist and intuitive User Experience (UX). End Users use the root Enterprise Noun as a means of understanding where they should be looking for Services. So, for example, if we know we need help with Database related work, it’s natural and intuitive to assume that we can find the appropriate Services which can help us under the category Database Management Services. If we know we need help with Contract related work, it’s natural and intuitive to assume that we can find the Services which can help us under the category Contract Management Services.
We can now see an interactive example what these Service Categories might look like in a Service Catalog. Each Service Category is alphabetically organized, easy to find, and acts as an index or grouping that, via a simple HTML link, leads to the different Service Request Types which can be accessed and/or invoked for that categorical area.
NOTE: This category-based naming pattern for Service Categories is consistent, repeatable, extensible and intuitively simple. It is, therefore, the essence of what can be considered Good Design Practices.
NOTE: Consistent naming standards also ensure a foundation to be able to apply and leverage automation, in the future, as your enterprise matures and can afford such automation.
Identify and Assign Clear Ownership and Accountability to Each Service Category
A Service Category without clear ownership is pretty useless. Therefore, it is important to know who (which people and/or which organizations) own and are accountable for each Service Category. In other words, the Service Provider Organization and the Service Provider Primary Contact should be known for every single Service Category.
Someone in your enterprise (like the Chief Architect) should own the Service Catalog, itself, and should have the responsibility of making sure that all Service Categories always have a clear owner. People leave the enterprise or change roles all the time. This means that a Service that had an Owner, yesterday, does not have an Owner, today. Proactively management and governance of Service Category ownership is a critical and necessary function that should not be taken lightly because if a Service stops, it impedes the work of those who need to find and invoke the Service. Projects can be delayed, budgets can be wasted, and quality can degrade. It is is recommended that you always proactively manage and govern your Service Categories and their ownership.
Collect Enough Attribute Data to Make the Categories Meaningful to the Service Requester
Every category should have meaningful attributes with updated data and information. Examples of such attributes include but are not limited to:
- Service Category Name
- Service Category Description
- Service Provider Organization
- Service Provider Primary Contact Person
- Service Category Contact Email Address
- Service Category Contact Phone Number
You can customize these attributes as you see fit, for your own enterprise.
Applying Repeatable Service Request Types
A Service Request Type (SRT) represents an individual granular Service that can be invoked via the Service Catalog. Each SRT should always have a parent Service Category and most SRTs should follow a consistent and repeatable naming standard, just like Service Categories follow such standards.
Naming standards for SRTs will be loosely based on the CRUD pattern used by Information Technologists. As a reminder, CRUD stands for:
- Create (or Instantiate)
- Read (or Retrieve)
- Update (or Modify)
- Delete (or Purge)
Using this pattern as a baseline, we can now extend it so that each Service Category has a CRUD-like pattern for SRTs, where the most basic will look as follows…
- Request Creation or Instantiation of New
- Request Information About
- Request Modification of Existing
- Request Deletion or Destruction of Existing
This means that if we have different noun-driven Service Categories, we can now have SRTs that can be applied in a consistent and repeatable manner to each categorical area. For example…
For Database Management Services…
- Request Creation or Instantiation of a New Database
- Request Information About a Database
- Request Modification of an Existing Database
- Request Deletion or Destruction of an Existing Database
For Sales Quotation Management Services…
- Request Creation or Instantiation of a New Sales Quotation
- Request Information About an Existing Sales Quotation
- Request Modification of an Existing Sales Quotation
- Request Deletion or Destruction of an Existing Sales Quotation
The pattern is fully extensible and scalable for each and every professional discipline area.
For those enterprises that care about more detailed SRTs and who are mature enough and can afford to automate many different SRTs, we can further extend this interface to include things like Estimation Service Request Types and Support Service Request Types. For example:
- Request an Estimate for a New
- Request an Estimate to Modify an Existing
- Register a Complaint or Incident
- Register a Defect or Flaw
- Register a New Requirement for Enhancement
If you drill into any of the example Service categories that are availalble in the Example Service Catalog, you will see that they all have consistent SRTs.
Customization of Service Request Types
Sometimes, there will be a justifiable need to add custom SRTs to a Service Category. Custom SRTs should be considered the exception, not the rule, and adding them to your Service Catalog should be handled with, both, caution and care. The Service Catalog Owner, who is also responsible for the design and governance of enterprise-wide Service Management, should review the request to add custom SRTs and approve such requests, only when absolutely needed. Too many custom SRTs can lead to significant levels of disorganization and chaos.
Identify and Assign Clear Ownership and Accountability to Each Service Request Type
Just like with Service Categories, and for the same reasons, we want to ensure that every single SRT has a clearly identified and accountable Owner (person and or organization). In other words, the Service Provider Organization and the Service Provider Primary Contact should be known for every single SRT.
In most cases, the Owner information for SRTs can be directly inherited from the parent Service Category that the SRTs exist for.
Collect Enough Attribute Data to Make the SRTs Meaningful to the Service Requester
Every SRT, just like every Service Category, should have meaningful attributes with updated data and information. Examples of such attributes include but are not limited to:
- Service Request Name
- Service Request Description
- Parent Service Category
- Service Request Provider Organization
- Service Request Primary Contact Person
- Service Request Contact Email Address
- Service Request Contact Phone Number
- Invoke This Service
You can customize these attributes as you see fit, for your own enterprise.
Again, most of this information is usually inherited from the parent Service Category. There is one exception, which is the attribute labeled “Invoke This Service” and which acts as a launching End-Point for the SRT that can be used to invoke its specific Service. This attribute’s value can be:
- a simple statement telling the end user to use the phone number or email address, or
- a link to a system that allows electronic form submission to invoke the request.
The Service Catalog as a Facade
Anyone who has ever worked for a very large enterprise understands that BPMS tools are everywhere and that, as a consequence of them being everywhere, different parts of the business and IT have established what can be considered many informal mini-Service Catalogs in many different tools and technologies. Trying to consolidate all those already orchestrated and automated Services into one combined new Service Catalog is often a lose-lose battle. However, we still want one single point of entry for all workers so that there is consistency and repeatability. For this reason, the Service Catalog designed and expressed herein can be used as a master facade that wraps, covers, and leads to all other Services in all other BPMS tools. This can be achieved through the Service End-Point (a.k.a. End-Point), discussed earlier, which depicts to the End User how he or she can and should invoke the Service Request Type (SRT).
The Service End-Point is a means of either directly invoking a desired Service or a means of leading the Service Requester to the appropriate manner or tool for invoking the desired Service.
NOTE: Applying the above design best practices ensures that your Enterprise Service Catalog enables and facilitates a Federated Service Oriented Architecture.
Integrating the Service Catalog into the Digital Enterprise Library
It is important to keep in mind that the Service Catalog is not the only catalog of importance to the enterprise. In fact, there are many catalogs that are important. For example, there is the Application Catalog, the Product Catalog, the Project Catalog, the Organization Catalog, etc. Creating a separate and non-integrated application for your Service Catalog is considered a bad architecture practice. Therefore, when designing your Service Catalog, you should always keep in mind that it needs to be made available with and appropriately integrated into any and all other catalogs. It is the purpose of the Digital Enterprise Library (DEL) (a.k.a. the Digital Library or the Enterprise Library) to accomplish this. The DEL acts as the master knowledge repository and, both, exposes and integrates all/most other catalogs. It is called a Digital Enterprise Library because it is designed in a manner that follows the traditional architecture and concepts of a Library and it is populated with the digital data and information that is relevant to an enterprise and it workers.
See an example of a Digital Enterprise Library’s Master Catalog of Catalogs.
Using Data Compilers to Generate The Service Catalog
When building your Service Catalog, you will need to make a decision about whether to use traditional 3-tier application architectures with relational databases or a data compiler that can synthesize your entire Digital Enterprise Library, along with your Service Catalog. The IF4IT always recommends using data compilers, like the NOUNZ Data, Information and Knowledge Management Platform. We believe the complexities and costs to be far lower, and Time-to-Value to be much shorter, especially when taking into account that many things will continuously change and data compilers allow for short, tight and low cost change cycles.
What path you take will always be up to you. However, should you go down the path of building or buying your own 3-tier application for a Service Catalog, we suggest you put away significant funds for integrations to/from other systems and for changes to your platform. We also suggest you plan to hire and maintain multiple resources with the appropriate skills, as your Service Catalog will become critical for work performance, over time.
IF4IT Service Management Education and Consultancy Services
If you’d like to learn more about Service Catalog design and implementation, Service Management, or any other area of IT management and governance, the IF4IT offers education and consulting services to help address your needs. Feel free to Contact Us to discuss your interests and needs.