What is a Service Catalog?

Coming to this article you may be in two learning mindsets. You’re curious about building a service catalog and want to know some of the basics. Or you’re curious about FireHydrant’s philosophy around this growing space.

Service Catalog at a Glance

At a basic level, a service catalog is an organized space for organizations to store their services with detailed information. Some companies build their own service catalog internally as an almanac to monitor service changes over time. They help explain how a business tool or application may work as well as who is responsible for it. Vendors and open source tools have popped up to provide this functionality as companies start scaling to the hundreds and thousands of services with an equal number of engineers supporting them.

A service catalog can be a key differentiator in establishing better service reliability for maintaining and growing products. Principal functionalities like who built this service, why it’s important, and labeled metadata can decide the output of how to iterate upon a given service or how to respond to an incident the respective service is involved in. Mature service catalogs also enable process automation to ensure newly created services adhere to requirements set by the engineering organization.

A robust service catalog has value outside of the engineering organization. Curated service information can provide insight, such as what a service does, to team members that sit outside of engineering. Members can learn more about their company’s services and how each service can impact their own teams and even customers.

Homegrown Service Catalogs

Many companies will organically start building out an internal service catalog which can quickly fall apart. As teams scale, the project needs significantly more investment than was initially planned. Many engineering teams begin building out rudimentary service catalogs in Google Sheets or Confluence to house important details on their applications and subject matter experts in case of failure. In many cases, these catalog implementations become wildly out of date and are more harmful than they are helpful.

There are two key issues with organic development of a service catalog as outlined above. Mediums like Google Sheets and Confluence are ever-changing and can be edited at any time by anyone. You may ask: “What if I restrict these docs?” Restricting edit access loses the ability to capture the transparency and fluidity of these ever-changing services. Additionally, who will be the point person to maintain these docs while trying to stay up to date with the exponential growth of service changes? A second key takeaway is that creating static documentation leaves out one of the key pieces needed in a service catalog: interaction.

FireHydrant’s Service Catalog Philosophy

FireHydrant’s answers to these issues are 1.) Establishing a source of truth via code 2.) Capturing changes, impact, and people responsible for a service. With this information, engineers or other team members can understand how to build on top of their service architecture or fix them during an incident. Establishing a source of truth that tracks this information can be crucial in growing a development team's operational maturity. Those are some loaded words coming for a Product Manager. But imagine having a sacred place for newly onboarding engineers to come into, poke around, and have the most important information available to them.

An even more critical scenario would be: You’re an on-call engineer responding to an incident on a service you don’t know anything about. Having a fully built-out service catalog can allow you to digest the most important information on the service or reach out to the right team for further info. With the most up-to-date information on this service, you can efficiently identify the problem and begin solving it immediately.

A service catalog can be that powerful.

Check out How Service Catalog Increases Productivity