Technology Catalogue

The Technology Catalogue is your organisation's authoritative list of technologies and their standing. Every framework, database, SaaS tool, cloud service, or programming language used across your estate has an entry here with a lifecycle status: is it preferred, allowed, on the way out (Sunset), or actively forbidden (Ban)? When you connect catalogue entries to Landscape elements, Northwise's Git Tech Discovery scanner can automatically raise Findings when a Sunset or Banned technology shows up in a mapped application's dependencies.

What it does

• Maintains a categorised list of technologies with their architecture standing: preferred, allowed, sunset, forbidden
• Links catalogue entries to Landscape elements (which applications use this technology?)
• Links entries to Principles (which architecture standards does this technology choice relate to?)
• Serves as the reference set for Git Tech Discovery — scans check dependencies against this catalogue and raise Findings on violations
• Tracks lifecycle status of the entry itself (draft → approved → deprecated) separate from the tech's standing

When to use it

• Documenting your technology radar for the first time — what's in and what's out
• An application team asks "is React still approved?" — they look it up here
• You want Plumbline to know that log4j < 2.0 is Banned — you add it with tech_status=forbidden
• You're migrating off a legacy platform — set it to sunset, link the replacement, and watch Git Tech Discovery surface every repo still using it
• An audit requires evidence of your approved technology standards

How it works

The four tech statuses

| Status | Meaning | How Northwise uses it | | ------------- | ------------------------------------------------------------------- | --------------------------------------------------------- | | Preferred | This is the recommended choice in its category | Highlighted in Tech Discovery scans; shown in green | | Allowed | Acceptable but not the default recommendation | No special treatment in scans | | Sunset | Still in use but being phased out; new usage requires justification | Git Tech Discovery raises a warning Finding | | Forbidden | Must not be used; existing usage is a violation | Git Tech Discovery raises a violation Finding immediately |

Anatomy of a catalogue entry

| Field | Purpose | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Name | Technology identifier, e.g. "Camunda 8", "React", "PostgreSQL 16" | | Category | Free-form category (workflow_engine, frontend_framework, datastore, iam, observability, …). Autocompletes from existing values in your tenant. | | Tech status | preferred / allowed / sunset / forbidden (see above) | | Version constraint | Optional version range, e.g. >=8.0, <2.0.0. Git Tech Discovery matches discovered versions against this constraint. | | Notes | Markdown. The reason for the status, alternatives to consider, migration notes. | | Related principles | Principles this entry relates to (e.g., a "cloud-first" principle governs which cloud services are preferred). | | Owner | Architect accountable for keeping this entry current. |

Lifecycle of the entry

The entry itself has a lifecycle — separate from the technology's standing:

draft → approved → deprecated

draft means you're still deciding. approved makes it visible to the rest of the organisation. deprecated means the entry is no longer actively maintained (the technology may have been removed from the estate entirely).

Linking to Landscape elements

On the catalogue entry detail page, the Linked Elements tab shows which Application Components and System Software elements use this technology. Links are bidirectional — you can also add them from the Linked Technology tab on any Landscape element.

These links are what Git Tech Discovery uses to determine which application is violating a standard. Without a link, a discovered dependency in a repo has no architectural context.

Linking to principles

If a principle says "All new datastores must be Postgres", that principle governs the choice of Postgres. Link Postgres (Preferred) and all other databases (Allowed/Sunset/Forbidden) to that principle. The Referencing Technology tab on the principle detail page shows this list.

The flat list vs. grouped view

The Technology Catalogue list page (/standards/technology) toggles between:

• Flat list — sortable, searchable, with filters for category, tech status, and lifecycle status
• Grouped by category — organised into your category taxonomy; useful for "show me everything in the messaging-broker category"

Common workflows

• Setting up drift detection for the first time — add your top 20 technologies with their statuses; link each to the Application Components that use them; connect a Git source in Tech Discovery; wait for the first scan.
• Changing a technology from Allowed to Sunset — edit the entry, change tech status to sunset, add migration notes. The next Git scan will start raising warning Findings.
• Finding which apps still use a Sunset technology — on the catalogue entry detail page, the Linked Elements tab shows them all.

Related