remove terminology from home page since it's now included on entity types page

Author: domalessi

content/en/internal_developer_portal/_index.md

@@ -16,6 +16,9 @@ further_reading:
   text: "How Datadog's Infrastructure team manages internal deployments using the Service Catalog and CI/CD Visibility"
 ---
 
+{{< callout url="https://www.datadoghq.com/product-preview/internal-developer-portal/" d_target="#signupModal" btn_hidden="false" header="Opt in to the preview for Datadog's Internal Developer Portal!" >}}
+{{< /callout >}}
+
 TODO: insert image of IDP
 
 ## Overview
@@ -29,10 +32,10 @@ Datadog's Internal Developer Portal (IDP) unifies live telemetry, metadata, and
 ## Common use cases
 
 {{< whatsnext desc=" " >}}
-    {{< nextlink href="/internal_developer_portal/use_cases/dev_onboarding" >}}Accelerate Developer Onboarding{{< /nextlink >}}
-    {{< nextlink href="/internal_developer_portal/use_cases/incident_response" >}}Improve Incident Response{{< /nextlink >}}
-    {{< nextlink href="/internal_developer_portal/use_cases/dependency_management" >}}Manage and Map Dependencies{{< /nextlink >}}
-    {{< nextlink href="/internal_developer_portal/use_cases/production_readiness" >}}Evaluate Production Readiness{{< /nextlink >}}
+    {{< nextlink href="/internal_developer_portal/use_cases/dev_onboarding" >}}Accelerate developer onboarding{{< /nextlink >}}
+    {{< nextlink href="/internal_developer_portal/use_cases/incident_response" >}}Improve incident response{{< /nextlink >}}
+    {{< nextlink href="/internal_developer_portal/use_cases/dependency_management" >}}Manage and map dependencies{{< /nextlink >}}
+    {{< nextlink href="/internal_developer_portal/use_cases/production_readiness" >}}Evaluate production readiness{{< /nextlink >}}
 {{< /whatsnext >}}
 
 ## Main features

content/en/internal_developer_portal/software_catalog/_index.md

@@ -24,9 +24,6 @@ algolia:
 
 Built on real-time telemetry and automated metadata collection, Software Catalog extends beyond traditional software catalogs by offering integrations with observability, security, and cost management tools. It empowers engineering, SRE, security, and platform teams to maintain visibility, streamline operations, and ensure service reliability at scale.
 
-{{< callout url="https://www.datadoghq.com/product-preview/internal-developer-portal/" d_target="#signupModal" btn_hidden="false" header="Opt in to the preview for our Internal Developer Portal!" >}}
-{{< /callout >}}
-
 ## What you can do in Software Catalog
 <br>
 {{< img src="tracing/software_catalog/software_catalog_tabs.mp4" video=true alt="A video overview of the Software Catalog, with the Services component type selected, that scrolls through the Ownership, Reliability, Performance, Security, Costs, and Delivery tabs" style="width:100%;" >}}
@@ -83,31 +80,13 @@ Every entry in Software Catalog is categorized as a component type:
 
 {{< img src="tracing/software_catalog/select-component.png" alt="Software Catalog component selector" style="width:30%;" >}}
 
-Datadog populates Software Catalog entries and determines their associated component type based on collected span attributes for APM ([peer tags][10]), but also based other collected telemetry types (USM, DSM, RUM, etc...).
+Datadog populates Software Catalog entries and determines their associated component type based on collected span attributes for APM ([peer tags][10]), but also based other collected telemetry types (for example: USM, DSM, RUM).
 
 **Note**: The component supersedes the `type` filter (derived from the `span.type` span attribute), as it detects more reliably and more granularly the different entity types. For instance, you can filter by datastore technology using the `datastore type` facet.
 
 [10]: /tracing/services/inferred_services#peer-tags
 {{< /site-region >}}
 
-## Key terminology
-
-Service
-: In APM, a [service][10] is a group of related endpoints, queries, or jobs that perform a piece of work for your application. For example, a service could be a group of endpoints, a group of DB queries, or a group of periodic jobs. Through custom instrumentation in APM, you can create an arbitrary `service`. In practice, microservice-based architecture includes multiple APM services, each measuring the performance of sub-components of the application through [Trace Metrics][2]. In the Software Catalog, you can collect non-instrumented services by declaring them through [metadata][12]. You can also import additional services through external sources like [Backstage][13] or [ServiceNow][14].
-
-System
-: In the Software Catalog, a system is a group of components that cooperate to perform a broader function. For example, you can group multiple instrumented APM services into a system because they are operated by the same team. You can also use `system` to represent a full microservice-based architecture, and include components like APIs, datastores, queues, and other common building blocks.
-: **Note**: **System** in Datadog has the same meaning as in Backstage's [System Model][15]. 
-
-Component
-: In the Software Catalog, a component represents the smallest building block of modern microservice-based architecture. A component can be an instrumented APM service, an [inferred][16] or manually declared datastore, an API, or a queue. 
-
-Endpoint
-: An endpoint refers to a specific route or path within a service that handles requests. For example, `/api/v2/messages/send`. Software Catalog contains HTTP endpoints that are automatically discovered by APM. The concept of endpoints correspond to [APM resources][19] for an APM web service. APM provides performance metrics such as request count, latency, and error rate. Users can also add other unmonitored endpoints to Software Catalog through metadata [Definitions][17]. 
-
-API
-: In the Software Catalog, an API refers to a collection of endpoints that belong together logically. APIs offer an alternative way to group endpoints beyond APM services (the mapping between endpoints and services are not modifiable). Users can define team and add additional endpoints (regardless of whether they are monitored by APM) by providing a `kind:API` metadata [Definition][18] in Software Catalog. 
-
 
 ## Further reading
 
@@ -128,7 +107,7 @@ API
 [13]: /software_catalog/customize/import_entries_backstage
 [14]: /software_catalog/customize/import_entries_servicenow
 [15]: https://backstage.io/docs/features/software-catalog/system-model/
-[16]: /tracing/services/inferred_services/?tab=agentv7551#naming-inferred-entities
+
 [17]: /software_catalog/service_definitions/v3-0/
 [18]: /software_catalog/service_definitions/#add-metadata-to-endpoints
 [19]: /tracing/glossary/#resources

content/en/internal_developer_portal/software_catalog/entity_model/entity_types.md

@@ -5,7 +5,7 @@ disable_toc: false
 
 ## Overview
 
-As of schema v3.0+, Software Catalog supports multiple kinds of entities, such as service, queue, datastore, system, and API. Custom entities are also supported.
+In Software Catalog, an entity represents the smallest building block of modern microservice-based architecture. As of [schema definition v3.0][1]+, an entity can be an instrumented APM service, a datastore, a system, an API, a queue, or even a custom-defined entity. 
 
 See GitHub for [full schema definitions][1]. 
 
@@ -230,4 +230,5 @@ Example YAML:
 {{< /tabs >}}
 
 
-[1]: https://github.com/DataDog/schema/tree/main/service-catalog/v3
+[1]: https://github.com/DataDog/schema/tree/main/service-catalog/v3
+[2]: /tracing/services/inferred_services/?tab=agentv7551#naming-inferred-entities