Marketplace-Integrationen: Live-Daten Ihrer Tools auf Ihrer Architektur
Letzten Monat beobachtete ich ein Team beim Debuggen eines Produktionsvorfalls über sieben Browser-Tabs. Datadog für die Metriken. GitHub für die Deploy-Historie. SonarQube für das Quality Gate, das jemand möglicherweise übersprungen hatte. ArgoCD, um zu bestätigen, dass der Pod tatsächlich die Version ausführte, die sie glaubten. Und irgendwo im Hintergrund ihr Architekturdiagramm in einem anderen Tab, perfekt akkurat, perfekt statisch, perfekt nutzlos für das vorliegende Problem.
Das Diagramm sagte ihnen, was das System war. Es konnte ihnen nicht sagen, wie es ihm ging.
Das ist kein Tooling-Versagen. Jedes dieser Tools ist hervorragend in dem, was es tut. Das Problem ist die Lücke dazwischen — der ständige Kontextwechsel, das mentale Modell, das man bei jedem Sprung von einem Dashboard zum nächsten neu aufbauen muss, die implizite Frage, die niemand laut stellt: "Welches dieser sieben Tools zeigt mir gerade das, was ich wirklich sehen muss?"
Wir haben die Marketplace-Integrationen gebaut, um diese Lücke zu schließen.
Die Idee
Die Prämisse ist einfach: Ihr Architekturdiagramm ist bereits die Karte Ihres Systems. Dort gehen Sie hin, um zu verstehen, was existiert, wie Dinge verbunden sind, welche Protokolle sie sprechen. Warum sollte es nicht auch der Ort sein, an dem Sie sehen, wie die Dinge laufen?
Archyls Marketplace ermöglicht die Verbindung externer Dienste — Datadog, GitHub, GitLab, Prometheus, SonarQube, ArgoCD, PagerDuty — und zeigt deren Daten als Live-Widgets auf Ihren Projekt-Dashboards. Keine Screenshots. Keine Links. Tatsächliche Live-Daten, alle 30 Sekunden aktualisiert, direkt neben Ihren C4-Diagrammen.
Ein Deployment-Status-Badge neben dem Container, den es deployt. Ein Code-Coverage-Zähler verknüpft mit dem Service, den er misst. Eine Alertliste, die zeigt, was gerade brennt, im Kontext der Architektur, die betroffen ist.
Was Sie verbinden können
Wir haben mit sieben Produkten gestartet, ausgewählt, weil sie die Toolchain abdecken, die die meisten Teams bereits nutzen:
Datadog — Monitor-Gesundheit, Metrik-Abfragen, aktive Alerts, eingebettete Dashboards. Wenn Sie Datadog bereits zur Überwachung Ihrer Infrastruktur nutzen, können Sie dieselben Daten in Ihrem Architektur-Workspace anzeigen, ohne eine einzige Abfrage zu duplizieren.
GitHub — Workflow-Status, offene Pull Requests, Repository-Statistiken, Dependabot-Alerts, Secret Scanning, Code Scanning. Die Sicherheits-Widgets allein sind die Einrichtung wert — statt den Sicherheits-Tab jedes Repos einzeln zu prüfen, sehen Sie die Ergebnisse kontextualisiert gegen die Architektur.
GitLab — Pipeline-Status, Merge Requests, Projektstatistiken und die komplette Security-Scanner-Suite: Schwachstellenanalyse, SAST, Secret Detection, DAST. Dieselbe Idee wie GitHub, nativ im GitLab-Ökosystem.
Prometheus — Instant-Abfragen für aktuelle Metrikwerte, Range-Abfragen als Zeitreihendiagramme gerendert, und Target-Health-Monitoring. Wenn Sie bereits PromQL-Abfragen für Ihre wichtigsten Metriken haben, können Sie diese direkt in Ihrem Architektur-Workspace anzeigen.
SonarQube — Quality-Gate-Status, Projektmessungen (Coverage, Bugs, Schwachstellen, technische Schulden), Issues nach Schweregrad, Security Hotspots und Sicherheitsbewertungen. Das Quality-Gate-Widget ist besonders nützlich: ein grünes oder rotes Badge pro Service sagt Ihnen sofort, ob der Code Ihren Standards entspricht.
ArgoCD — Anwendungsgesundheit und Sync-Status, Anwendungsinventare, Kubernetes-Ressourcenlisten und Anwendungszähler mit Filtern. Für Teams auf Kubernetes verwandelt dies Ihr C4-Diagramm in ein Deployment-Dashboard.
PagerDuty — Vorfallstatus, aktive Vorfallslisten, Bereitschaftspläne, Dienstgesundheit und Vorfallzähler. Für Teams, die Incident Response verwalten, bringt dies Ihre operativen Alerts in den Kontext der betroffenen Architektur — kein Springen mehr zwischen PagerDuty und Ihrem Systemdiagramm, um herauszufinden, welcher Dienst tatsächlich brennt.
Jedes Produkt unterstützt mehrere Widget-Typen — Zähler, Status-Badges, Listen, Zeitreihendiagramme und eingebettete Iframes — damit Sie die richtige Visualisierung für die Daten wählen.
Wie es funktioniert
Das System hat drei Ebenen:
Verbindungen leben auf Organisationsebene. Ein Admin erstellt eine Verbindung mit Zugangsdaten (ein API-Schlüssel, ein Token, eine Server-URL). Eine Verbindung kann Widgets über alle Projekte der Organisation hinweg versorgen. Sie können mehrere Verbindungen zum selben Produkt erstellen — etwa eine für Ihr Produktions-Datadog-Konto und eine weitere für Staging.
Widgets leben auf Projektebene (oder Element- oder Organisationsebene). Sie fügen ein Widget hinzu, indem Sie eine Verbindung wählen, einen Widget-Typ auswählen und die Abfrage konfigurieren. Ein GitHub-Widget "Offene Pull Requests" braucht einen Owner und Repository-Namen. Ein Prometheus-Widget "Range Query" braucht einen PromQL-Ausdruck und einen Zeitraum. Ein SonarQube-Widget "Quality Gate" braucht einen Projektschlüssel.
Das Grid ist der visuelle Ort der Widgets. Es ist ein 12-Spalten-Drag-and-Drop-Layout mit benannten Sektionen. Sie können Sektionen wie "Monitoring", "Sicherheit", "CI/CD" erstellen, einklappen, neu ordnen und einzelne Widgets skalieren. Alles wird automatisch gespeichert.
Die Einrichtung eines typischen Widgets dauert etwa 30 Sekunden. Verbindung wählen, Typ wählen, Config einfügen, fertig. Das Widget beginnt sofort mit dem Datenabruf.
Warum Widgets statt Dashboards
Wir hätten ein traditionelles Dashboard-Produkt bauen können. Reihen von Charts, eine Filter-Sidebar, das Übliche.
Haben wir nicht, weil das bereits existiert. Datadog hat Dashboards. Grafana hat Dashboards. Sie brauchen kein weiteres Dashboard-Tool. Was Sie brauchen, ist eine Möglichkeit, die richtigen Daten im richtigen Kontext zu sehen — und der Kontext ist Ihre Architektur.
Ein Grafana-Dashboard, das CPU-Metriken für zehn Services zeigt, ist nützlich. Aber es sagt Ihnen nicht, welcher dieser Services das API Gateway ist, welcher der Payment Processor und welcher das Notification System. Ihr Architekturdiagramm schon. Die CPU-Metrik auf die Architektur zu setzen, neben den Container, zu dem sie gehört, bedeutet, dass Sie diese mentale Zuordnung nie selbst machen müssen.
Das ist dasselbe Prinzip hinter allem, was wir bei Archyl bauen: Architekturdokumentation sollte der einzige Ort sein, an den Sie gehen, um ein System zu verstehen. Nicht nur seine Struktur — seine Entscheidungen (ADRs), seine Spezifikationen (API-Verträge), seine Deployment-Historie (Releases) und jetzt seine operationale Realität (Marketplace-Integrationen).
Sektionen und Organisation
Wir wussten von Anfang an, dass eine flache Wand von Widgets nicht skalieren würde. Wenn Sie fünfzehn Widgets in einem Projekt haben — manche für Monitoring, manche für Sicherheit, manche für CI/CD — brauchen Sie Struktur.
Widgets sind in benannte Sektionen organisiert. Sie erstellen sie, benennen sie, ordnen sie durch Ziehen der Überschriften um und klappen die ein, die Sie gerade nicht brauchen. Jede Sektion wirkt wie ein Panel, das Sie öffnen oder schließen können.
Im Bearbeitungsmodus können Sie:
- Widgets ziehen, um sie innerhalb einer Sektion neu zu positionieren
- Widgets zwischen Sektionen verschieben
- Widgets von einem kompakten Badge bis zu einem Diagramm in voller Breite skalieren
- Sektionsüberschriften ziehen, um ganze Gruppen neu zu ordnen
- Sektionen erstellen, umbenennen und löschen
Das Grid kompaktiert vertikal, sodass keine Lücken entstehen. Wenn Sie mit dem Arrangieren fertig sind, klicken Sie auf "Fertig" und das Layout wird fixiert.
Geltungsbereich: Organisation, Projekt, Element
Nicht alle Daten gehören auf dieselbe Ebene.
Organisationsweite Widgets sind in allen Projekten sichtbar. Nutzen Sie diese für Metriken, die global wichtig sind — gesamte Deployment-Anzahl, unternehmensweiter SonarQube-Quality-Gate-Status, organisationsweite GitHub-Sicherheitsergebnisse.
Projekt-Widgets erscheinen nur im Integrationen-Tab eines bestimmten Projekts. Das sind die häufigsten — Monitoring-Dashboards, CI/CD-Status, Code-Qualitätsmetriken für die Services in diesem Projekt.
Element-Widgets werden direkt an ein C4-Element angehängt. Öffnen Sie das Detailpanel eines Containers und Sie sehen seine Widgets neben seinen Beziehungen, ADRs und API-Verträgen. Das ist der mächtigste Geltungsbereich: operationale Daten kontextualisiert am architektonischen Element, zu dem sie gehören.
Was sich dadurch ändert
Vor den Marketplace-Integrationen bedeutete das Verständnis des operativen Zustands eines Systems, mehrere Tools zu öffnen, Daten abzugleichen und die Zuordnung zwischen "Monitoring-Dashboard" und "Architekturdiagramm" im Kopf zu behalten.
Danach: Sie öffnen einen Workspace. Die Architektur sagt Ihnen, was existiert. Die Widgets sagen Ihnen, wie es läuft. Die Releases sagen Ihnen, was ausgeliefert wurde. Die ADRs sagen Ihnen, warum es so gebaut wurde. Die API-Verträge sagen Ihnen, wie die Schnittstellen aussehen.
Ein Ort. Ein Kontext. Kein Tab-Wechsel.
Das ist die Vision, die wir seit Tag eins aufbauen. Architekturdokumentation, die echte Fragen beantwortet — nicht nur "Was ist dieses System?" sondern "Ist dieses System gesund?", "Ist dieser Service sicher?", "Wann war das letzte Deployment?" und "Wie ist der Quality-Gate-Status dieses Codes?"
Marketplace-Integrationen sind ein großer Schritt in Richtung dieser Vision. Und wir fangen gerade erst an — weitere Produkte kommen.
Erste Schritte
- Gehen Sie zu Organisationseinstellungen > Marketplace
- Verbinden Sie ein Produkt (Sie benötigen einen API-Schlüssel oder Token)
- Öffnen Sie den Integrationen-Tab eines beliebigen Projekts
- Klicken Sie auf Anpassen, dann Widget hinzufügen
- Wählen Sie eine Verbindung, wählen Sie einen Widget-Typ, konfigurieren Sie, fertig
Die gesamte Einrichtung dauert weniger als fünf Minuten. Ihre Architekturdiagramme werden sich nie wieder gleich anfühlen.
Möchten Sie sehen, wie andere Funktionen Ihre Architektur zum Leben erwecken? Entdecken Sie das Release-Management für Deployment-Tracking, oder die API-Verträge zum Verknüpfen Ihrer API-Spezifikationen mit dem Diagramm.