zalando/tech-radar: static technology radar with D3

What the Zalando Tech Radar Communicates

zalando/tech-radar solves a documentation and communication problem: making a set of technology choices visible and comparable across an engineering organization. The README says the public radar helps Zalando engineering teams align on those choices, and identifies ThoughtWorks as the original pioneering work on which it is based. The repository contains the code for the visualization, rather than a separate management system for collecting or approving technology decisions.

Each entry has a label and a position defined by a quadrant and a ring. A movement value also communicates whether the entry moved out, stayed in place, moved in, or is new. This makes the graphic useful when the position itself carries meaning, such as a change in adoption status between radar editions. The design is intended for publishing a curated view, not for collecting votes or tracking dependencies.

How the D3 Radar Is Configured

The visualization runs in the browser. The README instructs users to include D3 and `radar.js`, create an empty `svg` element, then call `radar_visualization` with a configuration object. The `svg_id` identifies the target element, while `width`, `height`, and `scale` control the drawing size. The `title`, `font_family`, and color values affect the surrounding presentation.

The configuration contains two positional structures. `quadrants` names the four sections. `rings` names the four concentric bands, from `INNER` through `OUTER`, with a color assigned to each one. An entry references a quadrant index and ring index, both using zero-based values. The README describes the quadrant order as clockwise, starting at the bottom right, and the ring order as starting from the inside.

The `moved` field changes the marker shape. The documented values are `-1` for moved out, `0` for no movement, `1` for moved in, and `2` for new. The README also states that entries are positioned automatically so that they do not overlap. That placement logic is part of `radar.js`; the repository exposes it through the visualization function rather than through a separate layout configuration.

A First Browser-Based Radar

The simplest documented setup uses the published `d3.js` and `radar.js` assets. This approach creates a static page without requiring a build step for the visualization itself. The following is the exact HTML setup described in the README:

<script src="https://d3js.org/d3.v7.min.js"></script>
<script src="https://zalando.github.io/tech-radar/release/radar-0.12.js"></script>

Add an empty SVG element after loading the scripts. The identifier must match the `svg_id` passed to `radar_visualization`:

<svg id="radar"></svg>

The next configuration example establishes the dimensions and visual zones. It uses the four quadrant names and the documented ring order shown in the README:

radar_visualization({
  repo_url: "https://github.com/zalando/tech-radar",
  svg_id: "radar",
  width: 1450,
  height: 1000,
  scale: 1.0,
  colors: {
    background: "#fff",
    grid: "#bbb",
    inactive: "#ddd"
  },
  font_family: "Arial, Helvetica",
  title: "My Radar",
  quadrants: [
    { name: "Bottom Right" },
    { name: "Bottom Left" },
    { name: "Top Left" },
    { name: "Top Right" }
  ],
  rings: [
    { name: "INNER",  color: "#5ba300" },
    { name: "SECOND", color: "#009eb0" },
    { name: "THIRD",  color: "#c7ba00" },
    { name: "OUTER",  color: "#e09b96" }
  ],
  print_layout: true,
  links_in_new_tabs: true,
  // entries: see the entry shape below
});

The `entries` array is where a team supplies its technology labels and positions. The README gives this entry shape:

entries: [
  {
    label: "Some Entry",
    quadrant: 3,
    ring: 2,
    moved: -1
  }
]

Replace the sample entry with the organization’s own records. The exact link behavior is controlled by `links_in_new_tabs`, and `print_layout` is included in the documented configuration for print-oriented output. The repository points to `docs/index.html` as a working example, so that file is the relevant reference for the complete page.

Running the Repository Locally

For development, the README specifies Yarn or npm for dependency installation and starts a local static development server through the `start` script. The documented commands are:

yarn
yarn start

The `start` script is `browser-sync docs -w`, as defined in `package.json`. It serves the `docs` directory and watches it for changes. The README states that the browser should open `http://localhost:3000/` automatically. If it does not, the documented URL is the address to open manually.

The repository also defines lint commands. `npm run lint` runs `lint:js` and `lint:html`, which use ESLint against `docs/*.js` and `docs/*.html`. The project therefore has a small, inspectable development surface: a documentation directory, browser synchronization, and static linting. The package is marked `private: true`, so the local workflow should be understood as repository development rather than an advertised public package installation.

Static Deployment and Upgrade Scope

The README says the radar is a static page and can be deployed to any hosting provider that offers static page hosting. That makes the deployment boundary clear. There is no documented server component, database, authentication flow, or background worker in the README. A deployment can therefore focus on serving the page and its referenced assets.

The page uses external script URLs in the README example, including D3 and a published radar script. A site that copies this setup must preserve those asset relationships or provide the corresponding files through its own hosting arrangement. The README does not document a rollback procedure, a content migration tool, or an administrative process for changing radar entries.

There are no GitHub releases listed for the repository. The README notes that version v0.12 uses D3 v7 and points readers to a related pull request for changes needed in a fork. For maintenance planning, the repository’s last push was on 2026-10-17 and it is not archived. That status does not by itself define upgrade compatibility for a fork. The package metadata still contains development dependencies such as `browser-sync`, `eslint`, `eslint-plugin-html`, and `socket.io`, so dependency updates should be checked separately from visualization changes.

License and Adoption Boundaries

The repository is licensed under the MIT License, with the license text in `LICENSE.txt` and the package metadata declaring `"license": "MIT"`. The stated permission covers use, copying, modification, merging, publication, distribution, sublicensing, and sale, subject to the conditions in the license text. The license also requires the copyright notice and permission notice to remain with copies or substantial portions of the software. This article does not provide legal advice.

The project is a reasonable fit for an engineering organization that already decides what belongs in its radar and wants to publish that decision as a static visual. It is also a workable starting point for a fork because the README invites adaptation. The trade-off is that the repository provides a rendering layer, not a process for producing radar content. A team still needs to define its categories, ring semantics, entry inventory, and review process.

Limits of the Static Radar

The largest practical limitation is the absence of documented data management features. The configuration is supplied directly to `radar_visualization`, and the README does not describe a database, import format, editing interface, or validation layer. An organization with frequent changes may therefore have to edit JavaScript or the working page source and redeploy the static files.

The project is also tied to browser-side rendering. The README documents D3 v7 and a browser page, but it does not describe server-side rendering, accessibility testing, or automated visual regression checks. The note that some font families can lead to font size issues is particularly relevant for publishing. The README names Arial, Helvetica, and Source Sans Pro as examples that seem to work well, which signals that typography can affect the rendered output.

A separate architecture is more appropriate when the radar must be backed by an authenticated service, edited by many users, queried programmatically, or integrated with an automated technology inventory. Such a system would place the entries in a data store and render them through an application layer. zalando/tech-radar instead favors a small static page whose configuration is close to the presentation.

Editorial conclusion

Adopt zalando/tech-radar when the team needs a static, configurable technology radar and accepts that the application is a client-side visualization rather than a content service. Do not choose it if you need documented validation, server-side persistence, or an administrative interface for radar data. Verify first that your entries, browser, D3 integration, typography, and deployment output produce an acceptable radar before publishing it through `docs/index.html`.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. zalando/tech-radar on GitHub