Service Catalog

📘

TL;DR

A real-time, clear and precise inventory of an organizations’ services and associated APIs, which can be further expanded to capture dependencies, from both a technical (e.g., licenses, libraries in use) and business operations perspective (e.g., what is available and being worked on, and by whom).

Background

The steady growth of DevOps has leveraged fairly technical concepts into major building blocks of modern IT strategy and even business models. Product teams use Microservices and well-aligned APIs to split work into domains, allowing them both for rapid advancement and low coupling. Business teams seek to unlock new business models & look for API monetization, while Enterprise Architects face the challenge to ensure governance and drive integration between self-developed software, SaaS and no-code/low-code developments.

Development speed and ingenuity can now be best achieved by empowering autonomous teams. But in fast-scaling development organizations and service landscapes, increasing complexity can quickly become a burden. Therefore, managing DevOps complexity is critical to driving development efficiency and software reliability.

Key starting points here are a clear and up to date overview of an organization's Services and the APIs that connect them which can then be expanded to capture further dependencies, both technical (used Libraries, Licenses and more) and business such as Team Ownership. In the following we will break down the LeanIX VSM approach to Service Catalogs and API Catalogs from the basic benefits, what's in it for the different types of benefactors as well as a start to setting things up:

What's in there for me?

As a member of a product team: Save time by automated documentation, get fast access to information & people by a well-maintained knowledge base.

As a product leader: Get a big picture of Teams & Technologies in your organization, help teams to streamline governance & foster knowledge exchange

As an enterprise architect: Automate the intake of self-developed software to boost governance (e.g. am I allowed to use a Cloud Service in this region) & technology standardization use cases.

As an engineering leader: Facilitate new team members onboarding by providing them with a centralized knowledge base while promoting reusability of existing software components.

What do I need?

Buy-in from product leadership (at least in your sub-organization) to boost transparency & knowledge sharing based on a central catalog

Access to at least one of the systems described at Discovery - Overview. We highly recommend starting with out-of-the-box integration to show results fast.

❗️

Don't shoot the messenger

Transparency can be painful. Reinsure yourself that you have the necessary buy-in, and be prepared to learn that establishing central standard might be tedious - yet, it's the base for every following optimization

Service Catalog

The basics

In a diverse, fast changing landscape of services, be they microfrontends, microservices or different setups clear and easy to access transparency is key to control complex, understand dependencies and take action where needed. With the VSM Service Catalog the necessary level of documentation is automated through integration with tools already widely used in engineering - from code repos over CICD pipelines to various engineering management tools - to minimize documentation overhead and ensure information is reliably up to date.

A baseline of Services

Team Responsibilities

👍

Hint:

The information on teams can be further expanded upon in our Engineering Efficiency case, which adds metrics on performance and efficency.

API Catalog

🚧

Work in Progress!

Please reach out for any questions!