Is service catalog the modern CMDB?

It takes a village to build a large-scale digital service. Like a machine with a million moving parts, each is built and operated by dozens (sometimes hundreds) of individual teams, typically operating independently with their own strategy and tooling.

Infrastructure complexity is a problem of the past, application complexity is the problem of the future

AWS CTO

To maintain control while moving fast, it's important for communication to flow between those teams. A critical part of that flow is knowledge:

• Understanding the big picture, and how your piece of the puzzle fits with the others

• Standardizing reporting for what matters

• Alerting stakeholders when there’s a problem

CMBDs, once seen as the solution to this challenge, are notoriously difficult to implement, with 85% of CMBD projects reportedly failing. Today, it's the service catalog that is seen as the scalable framework that makes managing complex applications possible. Catalogs define what services you have, the components that are a part of them, and how they come together to form an end user product or service.

What is a service catalog?

A service catalog is a centralized system that keeps track of ownership and information about the software components across your digital service. It makes it feasible for one team to manage multiple services, and for your company to manage thousands.

Developers can get an overview of all the software and platforms their teams manage – such as build pipelines, server utilization, cloud costs, and open incidents – regardless of how and where that information lives. That way, individual teams don’t need to jump between different developer tools and monitoring UI’s. And central operations and executive teams don’t need access to all those developer tools in order to understand KPIs about a given component.

Beyond an organizational framework a catalog is a portal for accessing any data, regardless of its original source including:

• Cloud platform metrics like function duration and cost
• Infrastructure monitoring metrics like CPU and memory utilization
• CI/CD data, like build pipelines and pull requests
• Service Management data like incidents and open tickets

Benefits of capturing knowledge with a service catalog

When knowledge is siloed across individual teams, simple tasks like reporting and troubleshooting are complicated and inefficient. But with knowledge democratized and broadly accessible, teams have several advantages.

A map of a complex digital service

I’ve talked to several developers who don’t understand the role their component or microservice plays in the context of the broader business service. They intimately understand “the trees” but have never seen “the forest”. Granted, this knowledge isn’t critical for every role, but it can be empowering, even for junior engineers.

On the other hand, central operations and executive teams absolutely need that bigger picture. But they often have the opposite challenge – with visibility of “the forest” but no way to drill down if there’s an issue with a service’s health, cost, or availability.

“Shifting Left” during incident response

In the early moments of a service degradation or outage, it’s typically unclear which part of the service is the root cause. Without centralized knowledge and data, there’s no way to troubleshoot without pulling in developers from teams responsible for each of the components. This wastes time and kills morale (we wrote about this in Incident response: Is MTTI the metric that matters most?).

“Shift left” is the concept of transferring a workload from a highly specialized and knowledgeable team to a more central and generalized one. This is only possible if that team is armed with the requisite knowledge to solve the problem.

Publishing KPIs to stakeholders

One of the most common requests we hear at the management level is for an executive dashboard. For mission-critical business services, leaders want visibility of its status, cost, and performance - ideally with KPIs also available for the critical components of that service.

The challenge is that each component is managed using a set of non-standardized tooling, making it difficult and extremely manual to summarize these KPIs across dozens of teams. The role of a service catalog is to provide that standardization, allowing KPIs to be automatically and consistently rolled up, regardless of the underlying tools and platforms.

Three ways to implement a service catalog

If you’re looking to build a service catalog, you have a handful of options, each with advantages and disadvantages:

A service management platform (e.g., ServiceNow)

Benefits: Maps the organizational structure for each application

Challenges: As a CMDB it is very time-consuming and expensive to implement.

An open-source catalog (e.g., Backstage.io)

Benefits: Less time-consuming to implement

Challenges: Lacks a visualization layer, for analyzing data from each component

An observability portal (e.g., SquaredUp)

Benefits:

• Maps the organizational structure for each application or digital service
• Provides a standardized visualization layer (dashboards)
• Integrates with any tool or platform, including ServiceNow and Backstage.
• Low cost and effort to implement

How SquaredUp Builds a Service Catalog

SquaredUp knows how to connect to data from across your tools and platforms. That data is left where it is – simply indexed and streamed into the portal on demand. Data from these tools and platforms is organized and cataloged in workspaces.

Each workspace is represented in SquaredUp as a cube because it acts like a knowledge container – eachcontaining a collection of dashboards, alerts, and KPIs. Workspaces are organized in a hierarchy that represent how a digital service is built and organized. KPIs are standardized and published up from individual workspaces to the parent workspaces above them. That way, any team managing those parent workspaces can drill down to the workspaces beneath them.

Dashboards provide the visualization layer that sits on top of workspaces to build a complete picture of a service catalog. An executive dashboard might be built using KPIs from the workspaces and dashboards which lie beneath it.

You couldn’t navigate a library of books without a catalog (anyone remember the Dewey Decimal System?). So how could you navigate a complex digital service without a service catalog.