Catalog analysis

The Catalog analysis report shows engineering metrics across all of your catalog entities. You can filter down the entities to create a specific cohort, and see how each cohort of entities performs relative to the baseline of all entities.

For example, you can view engineering metrics for all services that are written in JavaScript (an entity property); or view key metrics for all entities that have a Gold score on the Security Vulnerability scorecard.

This report helps teams:

• Correlate scorecard compliance with key metrics — Measure how passing a check or reaching a scorecard tier actually moves the organizational metrics you’re trying to improve.
• Communicate the ROI of setting standards — Show leadership concrete evidence that the standards you’ve defined are improving productivity and effectiveness, all in one easy-to-digest view.
• Identify areas for improvement — Spot which entities are underperforming on cycle time, throughput, or developer experience, and understand what sets them apart.

Setting up cohorts

The report starts with two groups: a Baseline and Cohort 1. You can add up to two more (three total in addition to the baseline) using the Add cohort button.

• Baseline — The reference group that all other cohorts are compared against. By default this is “All entities,” but you can customize it to any set of entities that match your criteria.
• Cohort 1–3 — Comparison groups. Select filters to define the entities that make up each cohort.

Defining a cohort with filters

Each cohort is defined by setting one or more filters and scoping down the list of entities. You can apply the following filters to scope down your selection:

• Entity type — select entities that are Services only or APIs only.
• Score on a specific scorecard or check — select entities that received a Gold score on the Production Readiness scorecard or entities that passed the check for having a README.md file.
• Entity relationships — select entities that are a part of a certain Application or Product Area.
• A specific property value — select entities that have their Language property defined as JavaScript, or their Service Tier property defined as Critical.
• Owner or owning team — select entities owned by a certain team or individual user.

Filters support both inclusion and exclusion:

• is / is any of — Include users matching the selected filter values.
• is not / is not any of — Exclude users matching the selected filter values.

You can combine multiple filter groups within a single cohort for more targeted comparisons (e.g., “Language is Javascript and score on Production Readiness scorecard is Gold”).

Metrics

Each metric is displayed as a tile in a responsive grid. Use the tiles dropdown (grid icon) to choose which metrics to display. Your tile selection is saved across sessions.

How aliases connect entities to metrics

Aliases connect catalog entities to external resources like GitHub repositories, PagerDuty services, or Jira projects (see all supported aliases). DX uses these aliases to calculate engineering metrics for each entity.

For example, to measure pull request cycle time for an entity, DX looks at the entity’s repository aliases (e.g. GitHub or Bitbucket), pulls all PRs from the associated repos, and calculates median time for the PR to move from open to merge. Beyond repositories, DX also uses aliases for projects, deployments, and incident services to power the full set of metrics listed below.

If an entity is missing the required aliases, DX can’t calculate its metrics. You’ll see a warning on the report when this happens:

Available metrics