From 37ca9e1434fb8fe31d463457fac1bec7d9142948 Mon Sep 17 00:00:00 2001 From: Marc Bruggmann Date: Mon, 1 Jun 2020 17:06:00 +0200 Subject: [PATCH] Clarify that we start by only implementing the Component entity --- docs/architecture-decisions/adr005-catalog-core-entities.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/architecture-decisions/adr005-catalog-core-entities.md b/docs/architecture-decisions/adr005-catalog-core-entities.md index f14f8c8179..1014019f8a 100644 --- a/docs/architecture-decisions/adr005-catalog-core-entities.md +++ b/docs/architecture-decisions/adr005-catalog-core-entities.md @@ -10,7 +10,7 @@ We want to standardize on a few core entities that we are tracking in the Backst ## Decision -We maintain a catalog of the following core entities: +Backstage should eventually support the following core entities: * **Components** are individual pieces of software * **APIs** are the boundaries between different components @@ -18,6 +18,8 @@ We maintain a catalog of the following core entities: ![Catalog Core Entities][catalog-core-entities] +For now, we'll start by only implementing support for the Component entity in the Backstage catalog. This can later be extended to APIs, Resources and other potentially useful entities. + ### Component A component is a piece of software, for example a mobile application feature, web site, backend service or data pipeline (list not exhaustive). A component can be tracked in source control, or use some existing open source or commercial software. It can implement APIs for other components to consume. In turn it might depend on APIs implemented by other components, or resources that are attached to it at runtime. @@ -72,4 +74,4 @@ spec: ## Consequences -We will start with fleshing out support for the Component entity in the catalog, and expand to APIs and Resources later down the line. +We will continue fleshing out support for the Component entity in the Backstage catalog.