🔎 Context:

Our architecture model follows a natural hierarchy of relations, for example:

• Domain <-Business Service -> System <-Component <- App Version <-Deployment (EKS Workload / ArgoCD Application / ECS Task Definition)

• Component <- Quality Analysis (SonarQube Project)

On the Component level in reports and widgets we need to see information coming from multiple related entities.

• Domain Architect from Domain

• Domain, Business Owner from Business Service

• Deployment metrics from EKS / ArgoCD / ECS (deployment type, health rating, environments, AWS accounts, regions).

• Quality metrics from SonarQube Project (size rating, coverage, complexity, link to SonarQube)

On the Deployment / Quality Analysis level we also need to see properties coming from the Component, for example:

• Status

• SRE / DevOps owner

⚠️ Problem

Currently this is difficult to achieve because:

1. Reports and widgets can only be based on a single entity, which makes it hard to build cross-entity views.

2. Mirror properties cannot be used flexibly, because:

• mirror properties cannot mirror another mirror property

• mirror properties cannot be used from the reversed direction of a relation

Because of these limitations we are forced to introduce workarounds such as:

• duplicating relations in both directions

• creating additional direct relations between entities

• using automations to maintain bidirectional links

This leads to relation explosion in the data model and significantly increases model complexity. It also might have a performance impact building more infrastructure and automations than conceptually required, which adds operational overhead and system load.

💡Possible solutions

Any of the following improvements would help solve this problem.

1️⃣ Flexible reports / widgets

Allow reports or widgets to aggregate data from multiple related entities, not only a single entity.

2️⃣ Mirror properties as aggregation properties

Allow mirror properties to be defined using a relation path, for example:

Component → App Version → Deployment → health_rating

Component <- SonarQube Project → coverage

Component -> System <- Business Service → Domain

3️⃣ At minimum Support:

• mirroring a mirrored property through a direct relation

• mirroring a property from the reversed direction of a relation (related idea https://roadmap.getport.io/ideas/p/mirror-properties-from-the-other-direction-of-relation)

📈 Impact

We have successfully connected all the required data sources to Port (infrastructure, deployments, and quality analysis). As a result, the catalog already contains the necessary operational and architecture data.

However, due to the current limitations around mirror properties and cross-entity reporting, we are struggling to turn this data into useful dashboards and reports.