Katalog
tool#Architektur#Softwareentwicklung#Produkt

draw.io (diagrams.net)

Browserbasierter Diagrammeditor für Architektur-, Prozess- und Flussdiagramme mit Vorlagen und Cloud-Integration.

draw.
Etabliert
Niedrig

Klassifikation

  • Niedrig
  • Technisch
  • Design
  • Fortgeschritten

Technischer Kontext

Confluence (Einbettung von Diagrammen)Google Drive / OneDrive (Speicherintegration)GitHub (Dateibasierte Versionierung)

Prinzipien & Ziele

Klarheit vor Detail: Diagramme sollen Konzepte schnell kommunizieren.Versionierung: Diagramme als Teil der Projektartefakte versionieren.Wiederverwendbarkeit: Vorlagen und Bausteine standardisieren.
Erkundung
Team, Domäne

Use Cases & Szenarien

Kompromisse

  • Inkonsistente Diagramme ohne zentrale Richtlinien.
  • Veraltete Diagramme, wenn Änderungen nicht nachgeführt werden.
  • Falsche Detailtiefe kann Diskussionen statt Entscheidungen fördern.
  • Verwende standardisierte Vorlagen für wiederkehrende Diagrammtypen.
  • Halte Diagramme fokussiert; verlinke Details statt alles darzustellen.
  • Versioniere Diagramme zusammen mit zugehörigem Code oder Docs.

I/O & Ressourcen

  • Anforderungen oder Zielbeschreibung
  • Bestehende Architektur- oder Prozessdokumente
  • Zugriff auf Team- und Cloud-Speicher
  • Diagramme in PNG, SVG, XML
  • Eingebettete Diagramme für Confluence/Docs
  • Vorlagen und Bibliotheken wiederverwendbarer Shapes

Beschreibung

draw.io (diagrams.net) ist ein browserbasierter Diagrammeditor zur Erstellung von Architektur-, Prozess- und Flussdiagrammen. Es bietet kollaborative Bearbeitung, Vorlagen und Integration in Cloud-Speicher. Das Tool eignet sich für technische Dokumentation, Architekturabstimmungen und schnelle Visualisierung von Ideen in Teams. Es unterstützt Exporte in gängige Formate und Einbettung in Dokumentationen.

  • Schnelle Visualisierung komplexer Zusammenhänge für Teams.
  • Einbettung und Export für Dokumentation und Präsentation.
  • Unterstützt kollaboratives Arbeiten und Abstimmungsprozesse.

  • Nicht spezialisiert auf modellgetriebene Architekturbeschreibungen.
  • Bei sehr großen Diagrammen können Performance-Grenzen auftreten.
  • Standardisierung erfordert disziplinierte Vorlagen- und Namensgebung.

  • Anzahl erstellter Diagramme

    Misst die erstellten Diagramme pro Zeiteinheit zur Bewertung der Nutzung.

  • Durchschnittliche Diagrammgröße

    Gibt Komplexität und potenzielle Performance-Auswirkungen an.

  • Anteil versionierter Diagramme

    Zeigt, wie viele Diagramme im Versionskontrollprozess verwaltet werden.

Architekturübersicht eines Websystems

Zentrales Diagramm zeigt Komponenten, Datenflüsse und Schnittstellen einer Webanwendung.

Onboarding-Prozess für neue Mitarbeiter

Flussdiagramm beschreibt Schritte, Verantwortliche und Tools im Onboarding.

API-Integrationsübersicht

Diagramm dokumentiert externe APIs, Authentifizierung und Fehlerflüsse.

1

Richtlinien für Notation und Vorlagen definieren.

2

Integration mit Team-Speicher und Confluence einrichten.

3

Schulungen und Beispiele bereitstellen, erste Diagramme reviewen.

⚠️ Technische Schulden & Engpässe

  • Veraltete Diagramme ohne Verantwortliche.
  • Inkonsistente Vorlagen in unterschiedlichen Projekten.
  • Fehlende Automatisierung für Diagramm-Updates aus Architekturänderungen.
Skalierbarkeit bei großen DiagrammenKonsistenz über autonome TeamsAutomatisierbarkeit von Diagramm-Updates
  • Ein einziges riesiges Diagramm für das ganze System statt modularer Views.
  • Diagramme als Ersatz für Spezifikationen statt Ergänzung.
  • Private Ablage von Diagrammen, die für das Team relevant sind.
  • Ignorieren von Namenskonventionen führt zu unklaren Artefakten.
  • Vergessen von Export- und Zugriffsrechten vor Freigabe.
  • Zu viele Detail-Layer in einem View machen das Diagramm unbrauchbar.
Grundverständnis von Diagrammnotationen (z. B. UML, C4)Fähigkeit, technische Zusammenhänge visuell zu strukturierenVersionierung und Dokumentationspraktiken
Klarheit der Kommunikation zwischen StakeholdernNachvollziehbare und versionierbare DokumentationNahtlose Integration in bestehende Toolchains
  • Notwendigkeit von Richtlinien zur Notation
  • Zugriffs- und Speicherorte (Cloud vs. Self-Host)
  • Kompatibilität mit bestehenden Dokumentationsformaten