ARCHITEKTURARTEFAKTE
Drei Artefakte, drei unterschiedliche Fragen.
Diagramm, Decision Log und Schnittstellenvertrag ergänzen sich. Keines davon ersetzt die anderen.
Einordnung und Kontext
Diagramm
Was ist miteinander verbunden?
Das Diagramm zeigt Systeme, Schnittstellen und Abhängigkeiten. Es schafft Orientierung – erklärt aber nicht automatisch, warum eine Verbindung genau so umgesetzt wurde.
Decision Log
Warum wurde dieser Weg gewählt?
Der Decision Log hält Entscheidung, Kontext, geprüfte Alternativen und Folgen fest. Damit bleibt die Begründung später überprüfbar.
Schnittstellenvertrag
Wie soll sich die Verbindung verhalten?
Der Vertrag beschreibt Daten, Semantik, Fehlerverhalten und technische Erwartungen an die Schnittstelle.
Zusammen beantworten die drei Artefakte: Was ist verbunden, warum wurde es so entschieden und wie soll die Verbindung funktionieren?
ÄNDERUNGEN
Lebende Historie statt stiller Überschreibung
Architekturentscheidungen ändern sich. Entscheidend ist, alte Einträge nicht einfach zu überschreiben. Wird eine Entscheidung ersetzt, sollte der neue Eintrag auf die vorherige Entscheidung verweisen und erklären, was sich geändert hat.
So bleibt sichtbar, welche Annahme früher galt, warum sie nicht mehr passt und welche Entscheidung heute gültig ist.
- Diagramm: Was ist verbunden?
- Decision Log: Warum dieser Weg?
- Schnittstellenvertrag: Wie verhält sich die Verbindung?
Häufige Fragen zum Decision Log
Wie ausführlich muss ein Eintrag sein?
So ausführlich wie nötig, damit ein anderes Team die Entscheidung später nachvollziehen kann. In vielen Fällen reichen wenige Absätze zu Kontext, Entscheidung, Alternativen, Auswirkungen und Verantwortlichen.
Muss jede technische Entscheidung dokumentiert werden?
Nein. Ein Decision Log lohnt sich vor allem bei Entscheidungen mit längerfristigen Auswirkungen – zum Beispiel bei Systemgrenzen, Integrationsmustern, Datenverantwortung, Security oder Betriebsmodellen.
Ersetzt ein Decision Log Diagramme oder technische Dokumentation?
Nein. Der Decision Log ergänzt bestehende Artefakte um die Begründung. Diagramme zeigen Zusammenhänge, Verträge beschreiben Verhalten und der Decision Log erklärt, warum eine Variante gewählt wurde.
KONTEXT ERHALTEN
Halten Sie die Begründung nah an der Verbindung
Eine Entscheidung verliert schnell ihren Wert, wenn sie losgelöst von Architektur und Schnittstelle abgelegt wird. Verknüpfen Sie den Eintrag deshalb direkt mit den betroffenen Systemen, Diagrammen und technischen Artefakten.
- Entscheidung mit dem betroffenen Systembild oder Diagramm verknüpfen
- Relevante Schnittstellen- oder Datenverträge referenzieren
- Owner und Betriebsverantwortung sichtbar halten
- Nachfolger und frühere Entscheidungen miteinander verbinden
Weitere Schritte (1)
- Reviews und offene Rückfragen direkt am Eintrag dokumentieren
PRÜFKRITERIEN
Was in einen brauchbaren Decision Log gehört
Entscheidung
Was wurde entschieden – und für welchen Prozess, welches System oder welche Schnittstelle gilt die Entscheidung?
Fachlicher Kontext
Welches Ziel, welche Einschränkung oder welches Risiko machte die Entscheidung notwendig?
Systeme & Verantwortung
Welche Systeme sind betroffen – und wer trägt fachlich und technisch Verantwortung?
Alternativen
Welche realistischen Optionen wurden geprüft – und warum wurden sie verworfen?
Weitere wichtige Prüfkriterien (3)
Folgen & Betriebsrisiken
Welche Auswirkungen hat die Entscheidung auf Daten, Security, Fehlerbehandlung, Support und spätere Änderungen?
Datum & Verantwortliche
Wann wurde entschieden – und wer trägt die Entscheidung fachlich und technisch mit?
Prüfauslöser
Welche Änderung an Prozess, Volumen, Plattform, Risiko oder Verantwortung macht eine erneute Bewertung nötig?
Wie dieselben Kriterien auf Salesforce-Lösungsoptionen angewendet werden, zeigt Salesforce Standard oder Custom? Eine Entscheidung mit Augenmaß.
NÄCHSTE SCHRITTE
Die nächsten konkreten Schritte
01
Kontext festhalten
Dokumentieren Sie zunächst Ausgangslage, Ziel und die Annahmen, die für die Entscheidung relevant sind.
02
Entscheidung prüfen
Vergleichen Sie realistische Alternativen nach denselben fachlichen und betrieblichen Kriterien.
03
Historie fortführen
Ändert sich die Entscheidung später, legen Sie einen neuen Eintrag an und verknüpfen ihn mit der bisherigen Historie.
Quellen und weitere Informationen
Für die fachliche Einordnung und weiterführende Details sind insbesondere diese Quellen hilfreich:
- Salesforce Architects – Integration Decision GuidesGeprüft am
Unterstützt den Aufbau und die Abgrenzung von Architekturentscheidungen, Integrationsmustern und Decision Records; alle drei Primärquellen vor Veröffentlichung erneut prüfen, ohne eine Empfehlung von Salesforce oder Microsoft zu behaupten.
- Salesforce Architects – Integration PatternsGeprüft am
Unterstützt den Aufbau und die Abgrenzung von Architekturentscheidungen, Integrationsmustern und Decision Records; alle drei Primärquellen vor Veröffentlichung erneut prüfen, ohne eine Empfehlung von Salesforce oder Microsoft zu behaupten.
- Microsoft Azure Well-Architected – Architecture Decision RecordGeprüft am
Unterstützt den Aufbau und die Abgrenzung von Architekturentscheidungen, Integrationsmustern und Decision Records; alle drei Primärquellen vor Veröffentlichung erneut prüfen, ohne eine Empfehlung von Salesforce oder Microsoft zu behaupten.
Themen dieses Beitrags
SO KÖNNTE ES IM ALLTAG AUSSEHEN
Drei Ansichten, die Entscheidungen nachvollziehbar machen.
Fiktive Arbeitsbereiche zeigen Entscheidung, Abhängigkeiten und den nächsten Betriebsschritt. Redaktionelle Illustrationen, keine Live-Produktscreenshots.
Entscheidungskontext · Grenze finden
Eigene Kontextkarte: Aktualität und Verantwortung erklären die Ereignisgrenze.
Mit dem Finger wischen oder mit gedrückter Maustaste ziehen. Alternativ die Bildauswahl oder Pfeiltasten nutzen.
Bild 1 von 3: Entscheidungskontext · Grenze finden
Passend weiterlesen
Salesforce-Integration: Robust statt Punkt-zu-Punkt
Eine direkte Verbindung zwischen zwei Systemen kann völlig sinnvoll sein. Problematisch wird es erst, wenn mit jeder neuen Anforderung weitere Sonderwege entstehen und niemand mehr klar sagen kann, wer für Daten, Fehler und Änderungen verantwortlich ist. Robuste Integration beginnt deshalb nicht mit einem bestimmten Tool, sondern mit klaren Systemgrenzen, Datenverträgen, Fehlerwegen und Betriebsverantwortung.
Beitrag lesen
Salesforce Standard oder Custom? Eine Entscheidung mit Augenmaß
Standard, Low-Code oder Custom: Die technisch einfachste Lösung ist nicht automatisch die beste. Entscheidend ist, welche Variante den fachlichen Bedarf erfüllt und auch später noch verständlich, testbar und wartbar bleibt. Der Vergleich sollte deshalb nicht nur auf Entwicklungsaufwand schauen, sondern auch auf Abhängigkeiten, Berechtigungen, Betrieb und spätere Änderungen.
Beitrag lesen
Agentforce-Pilot: Vom Prototyp zum sicheren Betrieb
Ein funktionierender Prototyp zeigt, dass etwas technisch möglich ist. Ein guter Pilot geht weiter: Er prüft Nutzen, Daten, Berechtigungen, Grenzen, Übergaben und Betrieb unter realistischen Bedingungen. Am Ende sollte deshalb nicht nur „funktioniert“ stehen, sondern eine belastbare Entscheidung: produktiv setzen, gezielt nachbessern oder bewusst stoppen.
Beitrag lesen