Tech Stacks API

Give every component a clear purpose

A technology list becomes an architecture inventory when each item has a role and a relationship to the application. Separate the user interface, application services, storage, delivery infrastructure, and operational tooling. Record build tools separately from components that execute in production. This prevents an unused development dependency from being mistaken for a live customer-facing service.

Start from maintained evidence: deployment configuration, package manifests, infrastructure definitions, and confirmation from the responsible team. Use a stable component identifier instead of relying on a display name that may change. A product can appear in several roles or environments, so model those instances explicitly when their ownership or operating conditions differ.

Connect a stack inventory with component records

The SPDX overview describes a standard for exchanging bill-of-materials information, including component metadata and relationships. Such records can inform a stack inventory, but the two should serve clear purposes. Use component-level evidence for software composition; add your own application ownership, deployment environment, and operational context where needed.

Choose a schema around the questions you need to answer. For upgrade planning, support runtime versions and maintenance responsibility. For incident routing, include service owners and upstream dependencies. For onboarding, make the connection between a repository and its deployed application obvious. Resist collecting every field simply because a tool can return it.

Manage disagreements and stale records

An inventory assembled from several sources will contain conflicts. A repository may declare a package that a recent deployment no longer uses. Treat that disagreement as a review task, preserve both observations, and record why one became the accepted value. Silently overwriting evidence makes later investigation harder.

Set review triggers around events the team already handles: a release, an ownership transfer, a major dependency change, or a service retirement. Mark records that have not been reconfirmed. An observation date tells readers when the evidence was collected; it should not be presented as the date the technology was first adopted.

Test the inventory with a change request

Pick one planned runtime upgrade. Can a maintainer identify affected applications, responsible teams, and the evidence behind each match? If the answer needs manual explanation, improve the fields or relationships before expanding coverage. The inventory should shorten a decision, not create another document to interpret.