Der Umkehrbarkeitstest
Auch in 28 Sprachen
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada)
Modul 3 von 7 im Kapitel Denken wie Datenarchitekt:innen, dem ersten Kapitel des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Das Datenmodell ist das Skelett · Weiter: Architektur ist die Kunst der Abwägung
Die Frage, die dieses Modul beantwortet: Wie unterscheidet man eine Architekturentscheidung von einer gewöhnlichen?
Architekt:innen treffen viele Entscheidungen.
Aber nicht jede Entscheidung ist eine Architekturentscheidung.
Das ist ein wichtiger Unterschied. Wenn wir jede Entscheidung als Architektur behandeln, verbringen wir unsere ganze Zeit damit, über Dinge zu diskutieren, die sich relativ leicht ändern lassen. Wenn wir die Entscheidungen nicht erkennen, die wirklich Architektur sind, können wir heute in fünf Minuten etwas entscheiden, das fünf Jahre braucht, um wieder aufgelöst zu werden.
Wie erkennen wir also den Unterschied?
Ich stelle gern eine einfache Frage:
Wie schwer wird es später sein, diese Entscheidung rückgängig zu machen?
Ich nenne das den Umkehrbarkeitstest.
Je schwerer etwas rückgängig zu machen ist und je mehr andere Dinge davon abhängen werden, desto mehr Aufmerksamkeit aus Architektursicht verdient es.
Manche Entscheidungen lassen sich billig ändern
Abschnitt betitelt „Manche Entscheidungen lassen sich billig ändern “Beginnen wir mit etwas Einfachem.
Wir nennen ein Feld Kundenkategorie. Sechs Monate später stellt das Geschäft fest, dass es eigentlich alle Kundensegment nennen. Wir ändern die Beschriftung. Vielleicht muss etwas Dokumentation angepasst und ein wenig geschult werden, aber das ist kein grosses Architekturereignis. Mit dem ursprünglichen API-Namen müssen wir allerdings leben, denn den zu ändern hat viel grössere Folgen. Es bedeutet also vielleicht nur, mit einer Umbenennung umzugehen und der Verwirrung, die sie mit sich bringen kann.
Wir haben eine Entscheidung getroffen. Wir haben unsere Meinung geändert. Wir sind weitergegangen.
Vergleichen Sie das jetzt mit einer anderen Entscheidung.
Wir schaffen eine Kennung für Kunden. Wir legen fest, was sie bedeutet, welches Format sie hat und welches System sie erzeugt. Dann veröffentlichen wir sie.
Salesforce verwendet sie. Das Data Warehouse verwendet sie. Die Integrationsplattform verwendet sie. Das Kundenportal verwendet sie. Fünf andere Anwendungen beginnen, sie zu speichern. Berichte und Datenpipelines verwenden sie. Vielleicht sehen die Kunden sie irgendwann.
Drei Jahre später sagt jemand:
Wir hätten die Kennung wahrscheinlich nicht so entwerfen sollen.
Das ist ein ganz anderes Gespräch.
Der Unterschied ist nicht, dass die eine Entscheidung technischer ist als die andere.
Der Unterschied ist die Umkehrbarkeit.
So kann das passieren. Angenommen, das Unternehmen bildet seine Schlüssel aus einem Teil des Kundennamens plus einer Nummer. Das funktioniert jahrelang, weil nie jemand einen Namen ändern musste. Dann, ein Jahr oder später, ändert sich doch ein Name, und plötzlich passen die Schlüssel nicht mehr zu dem Muster, das der Rest der Daten erwartet. Das ist einer der Gründe, warum Schlüssel keine eigene Bedeutung tragen sollten.
Architektur erzeugt Schwerkraft
Abschnitt betitelt „Architektur erzeugt Schwerkraft “Um eine Architekturentscheidung sammeln sich mit der Zeit Dinge an. Ich nenne das Schwerkraft.
Wählen Sie ein Objektmodell, und Automatisierung wird darum herum gebaut.
Wählen Sie einen Schlüssel, und andere Systeme beginnen, ihn zu speichern.
Wählen Sie, wo Stammdaten liegen, und Integrationen beginnen, zu ihnen hin und von ihnen weg zu fliessen.
Wählen Sie ein Freigabemodell, und Geschäftsprozesse beginnen davon abzuhängen, wer was sehen kann.
Wählen Sie ein Integrationsmuster, und Systeme beginnen, von seinem Timing und Verhalten abzuhängen.
Je länger diese Entscheidungen bestehen, desto mehr Schwerkraft entwickeln sie. Irgendwann bedeutet eine Änderung der ursprünglichen Entscheidung, alles zu ändern, was sich um sie herum angesammelt hat.
Auch KI spürt diese Schwerkraft. Ein KI-Werkzeug arbeitet mit dem, was schon im System ist: Sobald ein zentrales Entwurfselement da ist, behandelt jede KI-Interaktion danach dieses Element als Tatsache und baut weiter darauf auf, und weiter, und weiter. Die Entscheidung hallt durch viele weitere Entscheidungen nach, und kein Mensch geht je zurück, um die ursprüngliche zu überdenken. Jede Generierung verstärkt die Schwerkraft.
Deshalb ist es so wichtig, dass das Datenmodell «das Skelett» ist. Wir sind nicht vorsichtig, weil Veränderung schlecht wäre. Wir sind vorsichtig, weil Abhängigkeiten Veränderung teuer machen.
Stellen Sie zwei Fragen
Abschnitt betitelt „Stellen Sie zwei Fragen “Wenn ich mir eine Entwurfsentscheidung ansehe, stelle ich zwei Fragen:
Wie schwer ist das rückgängig zu machen?
Wie viel wird davon abhängen?
Sie hängen zusammen, sind aber nicht identisch. Etwas kann technisch leicht zu ändern sein und trotzdem Hunderte von Nutzenden haben. Früher hat man Standardobjekte der Klarheit halber umbenannt, etwa Account in «Kunde». Leicht gemacht. Dann wollte ein anderes System Accounts für Partner nutzen, und es ging nicht. Etwas anderes hat vielleicht nur wenige Nutzende, braucht aber eine enorme Migration, um es zu ändern, wie der API-Name eines Objekts, auf den intern an vielen Stellen verwiesen wird. Von aussen sieht ihn niemand, aber ein falscher verwirrt das Team immer wieder. Beides verdient Aufmerksamkeit.
Denken Sie an einige häufige Datenentscheidungen:
- Welches Salesforce-Objekt bildet dieses Geschäftskonzept ab?
- Was ist die eindeutige Kennung?
- Welches System ist das führende System?
- Werden diese Daten in Salesforce kopiert oder anderswo abgerufen?
- Ist das ein Objekt oder mehrere zusammenhängende Objekte?
- Wem gehören die Daten, und wie lange bewahren wir sie auf?
- Was sind unsere standardmässigen Zugriffsgrenzen?
- Wie bewegen sich diese Daten zwischen Systemen?
Das ist etwas ganz anderes als die Entscheidung, wo ein Feld auf einer Lightning-Seite erscheint. Seitengestaltung ist auch wichtig. Aber die Kosten eines Irrtums sind andere.
Denken Sie an den Explosionsradius
Abschnitt betitelt „Denken Sie an den Explosionsradius “Eine andere Art, über Umkehrbarkeit nachzudenken, ist der Explosionsradius: Wenn ich diese Entscheidung ändere, was bewegt sich sonst noch?
Angenommen, etwas, das wir als Feld modelliert haben, muss eigentlich ein untergeordnetes Objekt werden. Das ist nicht nur eine Schemaänderung. Was passiert mit den vorhandenen Daten? Mit den Berichten, den Integrationen, die dieses Feld erwarten, dem Apex und den Flows, die darauf verweisen, der Sicherheit, den Analysen, einem KI-Agenten, dessen Aktionen von der ursprünglichen Struktur abhängen?
Je grösser der Radius, desto sorgfältiger sollten wir die ursprüngliche Entscheidung treffen.
Deshalb müssen Architekt:innen auch über ihren eigenen Teil des Systems hinausblicken. Aus Salesforce heraus mag eine Änderung leicht aussehen. Aus Sicht des Unternehmens betrifft sie vielleicht zwölf andere Systeme.
Unternehmensentscheidungen und Salesforce-Entscheidungen
Abschnitt betitelt „Unternehmensentscheidungen und Salesforce-Entscheidungen “Datenarchitekt:innen denken auf zwei Ebenen.
Innerhalb von Salesforce entscheiden wir über Objekte, Beziehungen, Schlüssel, Volumen, Zugriff, Automatisierung und darüber, wie sich Daten auf der Plattform verhalten.
Im gesamten Unternehmen stellen wir grössere Fragen. Wo lebt der Kunde eigentlich? Wem gehört das Produkt? Welches System erzeugt einen Auftrag? Was ist unsere massgebliche Kennung? Welche Informationen werden zwischen Systemen kopiert, und welche bleiben, wo sie sind?
Die beiden Ebenen müssen zusammenpassen. Ich habe Salesforce-Implementierungen gesehen, deren internes Modell für sich genommen völlig sinnvoll war, aber nicht zum Unternehmen darum herum passte. Das reicht nicht. Salesforce-Strukturen müssen auf Unternehmensebene abgebildet werden, und Unternehmensentscheidungen müssen in Salesforce zurückfliessen.
Architektur ist Gegenverkehr.
Bremsen Sie bei den teuren Entscheidungen
Abschnitt betitelt „Bremsen Sie bei den teuren Entscheidungen “Eine Gefahr in der Technologie ist, dass die am leichtesten umzusetzenden Entscheidungen wie die am leichtesten zu treffenden aussehen können. Das ist nicht dasselbe.
Ein weiteres benutzerdefiniertes Objekt zu erstellen ist leicht. Ein weiteres Feld zu erstellen ist leicht. Eine weitere API anzubinden wird immer leichter, und KI macht all das noch leichter.
Aber wie leicht etwas umzusetzen ist, sagt uns fast nichts über die Kosten der Architekturentscheidung.
Halten Sie vor einer schwer umkehrbaren Entscheidung lange genug inne, um zu fragen: Welches Problem lösen wir eigentlich? Welche Alternativen haben wir erwogen? Was nehmen wir an? Was passiert, wenn das Volumen wächst und wenn sich das Geschäft ändert? Was wird sonst noch davon abhängen? Was passiert, wenn wir falschliegen?
Wir brauchen nicht jedes Mal sechs Monate Prüfung, wenn wir ein Objekt erstellen. Wir brauchen aber Nachdenken im Verhältnis zu den Kosten eines Irrtums. Ist es ein Objekt für eine einzelne Abteilung oder ein Teilsystem, können Sie schneller vorgehen. Sind es Referenzdaten, ein zentrales Kundenobjekt oder etwas, das systemübergreifend genutzt wird, nehmen Sie sich die Zeit, es gründlich zu durchdenken.
Schreiben Sie das Warum auf
Abschnitt betitelt „Schreiben Sie das Warum auf “Es gibt noch ein Problem mit wichtigen Entscheidungen: Die Leute vergessen, warum sie getroffen wurden.
Jemand betrachtet eine Architektur drei Jahre später und fragt: «Warum sollte jemand das so entwerfen?» Manchmal lautet die Antwort, dass es ein schlechter Entwurf war. Das kommt vor. Aber manchmal gab es einen sehr guten Grund: eine Einschränkung der Plattform, die es nicht mehr gibt, eine regulatorische Anforderung, ein anderes System, das den bevorzugten Ansatz nicht unterstützen konnte, eine bewusst akzeptierte Abwägung, um eine Frist zu halten.
Wenn wir nur festhalten, was wir entschieden haben, und nicht warum, können die nächsten Architekt:innen es nicht wissen.
Schreiben Sie es bei wichtigen Entscheidungen auf. Es muss kein 50-seitiges Dokument sein. Eine nützliche Entscheidungsaufzeichnung kann sehr klein sein:
Kontext: Welches Problem lösen wir?
Optionen: Welche realistischen Alternativen haben wir erwogen?
Entscheidung: Was haben wir gewählt?
Folgen: Was gewinnen wir, und was geben wir auf?
Verantwortlich: Wer steht für diese Entscheidung ein?
Überprüfung: Welcher Anlass oder welches Datum sollte uns dazu bringen, sie erneut zu betrachten?
Der Wert liegt nicht im Dokument. Der Wert liegt darin, die Begründung zu bewahren.
Und wenn sich eine Entscheidung ändert, löschen Sie die ursprüngliche nicht. Ersetzen Sie sie. Die Entscheidung, die 2027 richtig war, ist 2030 vielleicht nicht mehr richtig, denn Volumen, Geschäft, Salesforce und unser Verständnis ändern sich. Was ich bewahren möchte, ist die Geschichte: Das war der Kontext, das war die Entscheidung und warum, das hat sich geändert, und das entscheiden wir jetzt. Das ist weit wertvoller, als so zu tun, als hätten wir die Antwort immer gekannt.
Über die Prüfung hinaus: KI verkürzt die Zeit von der Entscheidung zur Abhängigkeit. Ein KI-Werkzeug kann in Sekunden ein Datenmodell vorschlagen und dann die Objekte, die Automatisierung, den Integrationscode und die Benutzeroberfläche darauf aufbauen. Früher dauerte es Monate an Entwicklung, bis viel von einer fragwürdigen Entscheidung abhing; heute entstehen die Abhängigkeiten fast sofort. Prüfen Sie also die Entscheidungen unter dem Ergebnis, nicht nur das Ergebnis. KI kann helfen: Sie kann Optionen auflisten, Annahmen hinterfragen und die Entscheidungsaufzeichnung entwerfen. Aber die Entscheidung liegt weiterhin bei Architekt:innen, und je schwerer sie rückgängig zu machen ist, desto mehr zählt dieses menschliche Urteil.
Wissen, welche Entscheidungen zählen
Abschnitt betitelt „Wissen, welche Entscheidungen zählen “Eine der Fähigkeiten, die Sie entwickeln sollen, ist zu wissen, wohin Ihre Aufmerksamkeit gehört.
Machen Sie nicht aus jeder Konfigurationsentscheidung einen Architekturgipfel.
Aber treffen Sie auch nicht beiläufig eine Entscheidung, mit der die Organisation das nächste Jahrzehnt leben wird.
Fragen Sie:
Wie schwer wird das rückgängig zu machen sein?
Wie viel wird davon abhängen?
Lauten die Antworten sehr schwer und sehr viel, haben Sie wahrscheinlich eine Architekturentscheidung gefunden.
Bremsen Sie. Verstehen Sie die Anforderung. Prüfen Sie die Alternativen. Machen Sie die Abwägungen sichtbar. Treffen Sie die Entscheidung. Und schreiben Sie das Warum auf.
Das Ziel von Architektur ist nicht, Entscheidungen zu treffen, die sich nie ändern können.
Das Ziel ist, die Entscheidungen zu erkennen, bei denen eine spätere Meinungsänderung teuer wird.
Was Architekt:innen hier entscheiden
Abschnitt betitelt „Was Architekt:innen hier entscheiden “- Welche Entscheidungen Architektur sind: schwer rückgängig zu machen, und vieles hängt von ihnen ab.
- Wie viel Aufmerksamkeit jede Entscheidung bekommt, im Verhältnis zu den Kosten eines Irrtums.
- Welche Entscheidungen aufgeschrieben werden, mit Kontext, Optionen, Folgen, Verantwortlichem und Überprüfungszeitpunkt.
- Wie die Salesforce-Entscheidungen zu denen des Unternehmens passen.
Weiterlesen
Abschnitt betitelt „Weiterlesen “- Object Relationships Overview (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-10-09; erneut geprüft am 2026-10-12): In einer Master-Detail-Beziehung folgen Zugriff und Eigentümerschaft des Details dem Master, und das Löschen eines Masters löscht seine Details.
- Considerations for Object Relationships (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-10-09; erneut geprüft am 2026-10-12): Eine Nachschlagebeziehung lässt sich nur dann in Master-Detail umwandeln, wenn jeder Datensatz darin einen Wert hat; die Umwandlung ändert das Freigabemodell (auf «Controlled by Parent», durch übergeordnetes Element gesteuert), und der Beziehungstyp entscheidet, welche Standardberichtstypen verfügbar sind.
- Roll-Up Summary Field (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-10-09; erneut geprüft am 2026-10-12): Rollup-Zusammenfassungsfelder gibt es nur bei Master-Detail-Beziehungen, und sie müssen gelöscht werden, bevor eine Master-Detail-Beziehung zu einer Nachschlagebeziehung werden kann.