One of the biggest mistakes most Service Catalog implementers make is to leave out Service Categories during planning and design stages. The second biggest mistake made by Service Catalog implementers, after they realize they need to go back and try to implement categories, is to not make them standard and consistent.
Defining a Service Category
A Service Category, also known as a Service Classification or a Service Type is a broad categorization, classification or type of Service.
A Service Category acts like a library index because it behaves like a quick-link to all underlying Service Request Types that are available for that category.
- Database Management Services is a Service Category that groups and points to all database-related Service Request Types.
- Print Services is a Service Category that groups and points to all printing-related Service Request Types.
The IF4IT Taxonomy of Service Types highlights most of the Service Categories / Service Types used by most mature enterprises.
Examples of interactive Service Categories can be found on the IF4IT NOUNZ Service Catalog Page. You’ll notice that drilling into any single Service Category allows you to access all related Service Request Types.
Service Categories also facilitate better Search Engine Optimization (SEO) and search functions. For example searching for “database” or “database services” should lead to a search result of “Database Management Services” that, in turn, is a pointer to all database-related Service Request Types.
Defining a Service Request Type
In short, a Service Request Type (SRT), also referred to as a Service (short form), is a something that can be invoked or accessed to provide a specific solution for a specific problem. So, for example, if we invoke the Service Category for Database Management Services, we might find specific Service Request Types (Services) that can be invoked, such as “Request a new Database,” or Terminate and Existing Database,” or “Change an Existing Database.”
Nontechnical Business Service Categories versus Technical Service Categories
When designing your Service Catalog, it is important to understand the difference between Nontechnical Service Categories and Technical Service Categories.
Technical Service Categories are those Service Categories that revolve around technologies and technology-related functions. For example: Database Management Services, Application Management Services, and Electronic Storage Services.
Nontechnical Business Service Categories (a.k.a. Business Services) are those Service Categories that revolve around business specific functions and often have nothing to do with technologies or technology-related functions. For example: Employee Management Services, Consultant Management Services, Print Services, Sales Quotation Services, etc.
A good Service Catalog always implements, both, Nontechnical Service Categories as well as Technical Service Categories. In fact, one of hte biggest mistakes IT professionals make when designing their Service Catalogs is to only include IT Services (Technical Services). This is a sure way to force the business to deploy their own Service Catalog systems, forcing the enterprise into multiple silo-ed systems, which is an architectural bad practice.
Dial-Tone Services versus Transactional Services
It is also very important to understand the differences between Dial-Tone Services and Transactional Services, and the impacts they have on the design of your Service Catalog, and on your overall Service Management practices.
A Dial-Tone Service is a Service that, like the old-fashioned dial-tone on your telephone, is expected to be there, up and running, without issues, for an expected period of time. Dial-Tone Services are almost always technical systems that perform a service, like an Application.
A Transactional Service is one that is invoked by a Service Request that is accompanied by required inputs, in order to deliver a known, controlled, and repeatable output (i.e. a Service Deliverable). Think of asking someone to do something for you.
Most Service Catalogs exist to deal with Transactional Services. Dial-Tone Services are usually exposed via different tools, such as the Application Catalog. (See an Example Service Catalog, with Transactional Services. See an Example Application Catalog, with Dial-Tone Application Services.
Atomic Services versus Composite Services
An Atomic Service is a small Service that stands on its own and which, does not rely on the invocation of other Services.
An Composite Service is a Service that is composed of or executes other Services, behind its invocation facade.
An example of a Composite Service is a New Employee On-boarding Service. When you invoke a request for setting up and on-boarding a new Employee, numerous other Services need to be invoked for the on-boarding Service to be successful. For example:
- the Request a new Security Badge Service,
- the Request a new Phone Number Service,
- the Request a new Office Services,
- the request a new Laptop Service,
The trait of a Composite Service is that the Service Provider of the Composite Service will invoke and manage all other Service Requests behind the facade of the Service Request you invoked. So, to stay with the New Employee On-boarding Service, you may request the setup of a new employee, however it is the owner of “that” Service that will invoke and manage all other necessary Services (new Security Badge, new Phone Number, etc.), on your behalf.
Best Practice Recommendations:
- It is always more prudent to work on setting up your Atomic Services, first, and then use them to construct your Composite Services, as leveraged building blocks.
- If you are building a Composite Service and, in the process, discover the need for a smaller Composite or Atomic Service, break it out and build it, as quickly as possible so that everyone else can leverage it, too.
- Look for high areas of reuse for Service development. The more reusable a Service is, whether it is Atomic or Composite, the more value many other organizations and people will get from it.
Naming Standards for Service Categories
When designing your categories, it is always a good practice to use consistent naming standards. Doing so will make it easier and more intuitive for your end users to understand the underlying design ontology of the Service Catalog. They’ll quickly know, just by looking at a name, whether they are dealing with a category, a request type or an invocation. And, knowing exactly what they are looking at, they will intuitively know what actions they can perform with the user interface. So, for example, if they’re looking at a name that represents a category, they will intuitively know that from a category they can get to request types, and from request types, they can get to request invocations.
Using a consistent naming standard will also allow you to leverage automation, as automation code always relies on consistent representations and patterns.
The IF4IT recommends using a Discipline-based naming standard. For example, if you start with a Noun, like a Database or an Employee, you can use the related professional discipline name to categorize a set of Service Request Types. For example: Database Management Services and Employee Management Services, respectively.