Kennen Sie Ihre Werkzeuge: die neun Fragen

🌐 Auch in 28 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · 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) · Deutsch (Schweiz)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen

Modul 6 von 7 im Kapitel Denken wie Datenarchitekt:innen, dem ersten Kapitel des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Für heute bauen. Für morgen planen. Für das Scheitern planen. · Weiter: Datenarchitekt:innen im Zeitalter der KI

Die Frage, die dieses Modul beantwortet: Wie beurteilt man ein Werkzeug, auch eines, das man noch nie gesehen hat?

Architekt:innen brauchen Urteilsvermögen. Aber Urteilsvermögen ohne Wissen nützt nicht viel. Sie müssen Ihre Werkzeuge trotzdem kennen.

Ich bilde seit Jahren Architekt:innen aus, und ein Rahmen, den ich verwende, ist eine Reihe von Fragen, die Sie zu jedem wichtigen Werkzeug und jeder wichtigen Funktion Ihrer Architektur beantworten können sollten. Ursprünglich habe ich acht Fragen unterrichtet. Eine neunte ist hinzugekommen. Die Technologien ändern sich, Salesforce ändert sich, neue Produkte erscheinen und alte Funktionen entwickeln sich weiter, und KI beschleunigt all das. Diese Fragen funktionieren weiterhin.

Die neun Fragen

Wann immer Sie eine Technologie lernen oder beurteilen, fragen Sie:

1. Was ist es?
2. Wo wird es eingesetzt?
3. Wie verwende ich es?
4. Welche Alternativen habe ich?
5. Was sind seine Stärken?
6. Was sind seine Schwächen?
7. Wie erkläre ich es dem Entwicklungsteam, dem Fachbereich und Führungskräften?
8. Wie wird es langfristig gewartet?
9. Was kostet es, welche Lizenzen erfordert es, und wo liegen seine Grenzen?

Wenn Sie alle neun beantworten können, beginnen Sie, das Werkzeug so zu verstehen, wie Architekt:innen es verstehen. Beachten Sie, was nicht auf der Liste steht: „Kann ich es konfigurieren?“ Das ist wichtig, aber nur ein Teil davon, das Werkzeug zu kennen.

Click to enlarge

1. Was ist es?

Beginnen Sie mit der offensichtlichen Frage, denn sie wird überraschend oft übersprungen. Wir hören einen Produkt- oder Funktionsnamen und diskutieren sofort, ob wir es einsetzen. Langsamer. Was tut es eigentlich? Für welches Problem wurde es entworfen? Wo sitzt es in der Architektur, und was ist es nicht? Architekt:innen sollten eine Technologie beschreiben können, ohne die Marketingbeschreibung zu wiederholen. Wenn ich etwas nicht in ein paar Sätzen erklären kann, verstehe ich es wahrscheinlich noch nicht gut genug.

2. Wo wird es eingesetzt?

Zu wissen, was etwas tut, ist nicht dasselbe wie zu wissen, wann es in eine Architektur gehört. Für welche Art von Problemen ist es gut? Unter welchen Bedingungen ist es angemessen, und welche Bedingungen sollten mich misstrauisch machen? Das ist der Schritt von „Ich kenne diese Funktion“ zu „Ich erkenne das Problem, das diese Funktion löst“, und es ist ein großer Schritt. Sie wollen nicht herumlaufen und nach Stellen suchen, an denen Sie Ihre Lieblingstechnologie einsetzen können. Sie wollen Probleme erkennen und wissen, welche Werkzeuge dazu passen.

3. Wie verwende ich es?

Ja, Architekt:innen sollten die Umsetzung verstehen. Sie müssen nicht jede Komponente bauen, aber Sie sollten genug verstehen, um zu wissen, was Sie von anderen verlangen. Wissen Sie, wie es konfiguriert wird, wie man in der Entwicklung damit arbeitet, wie Daten hinein- und herauskommen, wie es bereitgestellt und abgesichert wird und wie es im Betrieb aussieht. Ich möchte nicht, dass jemand in der Architektur um eine Technologie herum entwirft, die nur von einer Produktfolie bekannt ist. Machen Sie sich die Hände schmutzig: Bauen Sie etwas, machen Sie etwas kaputt, sehen Sie, wie es sich wirklich verhält. Architektur wird besser, wenn sie in der Wirklichkeit verankert ist.

4. Welche Alternativen habe ich?

Das ist vielleicht die wichtigste Frage auf der Liste. Wenn Sie nur einen Weg kennen, ein Problem zu lösen, haben Sie keine Architekturentscheidung, sondern einen Standard. Wann immer jemand eine Technologie vorschlägt, möchte ich wissen, was wir sonst tun könnten. Eine andere Salesforce-Funktion? Etwas Deklaratives oder Code? Könnte die Funktion außerhalb von Salesforce liegen? Könnten wir die Daten lassen, wo sie sind, statt sie zu kopieren, ein Ereignis statt eines API-Aufrufs verwenden oder gar nichts bauen? Alternativen schaffen Abwägungen, und Abwägungen sind das Herz der Architektur.

5. Was sind seine Stärken?

Jedes Werkzeug existiert aus einem Grund. Verstehen Sie, worin es wirklich gut ist: was es leicht macht, wo es gut skaliert, welche Komplexität es beseitigt, welche Probleme es elegant löst. Setzen Sie Technologien dort ein, wo ihre Stärken zum Problem passen. Das klingt selbstverständlich, aber es ist sehr leicht, ein Werkzeug zu wählen, weil wir es schon besitzen, das Team es kennt, es neu ist oder jemand eine Demo gesehen hat. Das können Faktoren sein. Es ist nicht dasselbe wie architektonische Eignung.

6. Was sind seine Schwächen?

Das ist genauso wichtig. Jede Technologie hat Schwächen, jede. Wenn Ihnen jemand nur die Stärken einer Technologie nennen kann, führen Sie noch keine Architekturdiskussion. Was kann sie nicht gut? Wo entsteht Komplexität, und was passiert im großen Maßstab? Welchen Betriebsaufwand und welche Abhängigkeiten bringt sie mit? Welche Anforderungen drängen sie aus ihrem Idealbereich? Eine Schwäche heißt nicht immer, dass wir die Technologie nicht einsetzen sollten. Sie heißt, dass wir wissen müssen, was wir in Kauf nehmen. Eine Abwägung, die Sie verstehen, kann eine Architekturentscheidung sein. Eine Abwägung, die Sie nicht verstehen, kann zur Überraschung werden.

7. Wie erkläre ich es verschiedenen Zielgruppen?

Das ist eine der Fragen, die technisches Wissen von architektonischem Können trennen. Können Sie dieselbe Technologie dem Entwicklungsteam, dem Fachbereich und einer Führungskraft erklären? Das sollten nicht dieselben Erklärungen sein. Das Entwicklungsteam braucht die APIs, das Transaktionsverhalten, die Sicherheit, die Fehlerbehandlung und die Umsetzungsmuster. Den Fachbereich interessiert, was es ermöglicht und wie sich sein Prozess ändert. Die Führungskraft interessiert sich für Kosten, Risiko, Zeit, Auswirkungen auf die Organisation und dafür, welche Optionen die Entscheidung offenhält oder verschließt. Sie ändern nicht die Wahrheit; Sie ändern die Abstraktionsebene. Wenn Sie eine Technologie nur im Vokabular ihrer Dokumentation erklären können, arbeiten Sie weiter an Ihrem Verständnis.

8. Wie wird es langfristig gewartet?

Projekte enden. Systeme nicht, oder wir hoffen es zumindest. Jemand muss verantworten, was wir bauen, nachdem das Projektteam gegangen ist. Das heißt zu wissen, wie es überwacht, aktualisiert und Fehler darin gesucht werden, wer die Fähigkeiten braucht, um es zu betreuen, wie Änderungen bereitgestellt und getestet werden und was passiert, wenn sich die Technologie weiterentwickelt oder Salesforce darunter etwas ändert. Stellen Sie es sich in drei Jahren vor. Ich habe Architekturen gesehen, die am Tag des Go-Live sehr clever waren und danach eine Qual im Betrieb. Das ist kein Erfolg. Wartbarkeit ist Teil der Architektur.

9. Was kostet es, welche Lizenzen erfordert es, und wo liegen seine Grenzen?

Das ist die Frage, die ich den ursprünglichen acht hinzugefügt habe, und heute halte ich es für unmöglich, sie wegzulassen. Eine Technologie kann die perfekte technische Lösung und trotzdem die falsche Architekturlösung sein, wenn die Wirtschaftlichkeit nicht stimmt. Ist sie in unseren Lizenzen enthalten oder ein Zusatzprodukt? Wird sie nach Benutzer, Nutzung, Verbrauch, Speicher oder Transaktionen lizenziert? Was passiert mit den Kosten, wenn wir skalieren?

Dann gibt es Grenzen, und jede Plattform hat sie: API-, Speicher-, Abfrage-, Transaktions-, Parallelitäts-, Durchsatz- und Lizenzgrenzen. Manche sind hart, manche weich; manche lassen sich anheben und manche nicht; manche spielen bei unserer Größe keine Rolle, bis wir eine weitere Null hinzufügen. Sie müssen nicht jede Salesforce-Grenze auswendig lernen, und das wäre eine furchtbare Verwendung Ihrer Zeit. Sie müssen wissen, dass es die Grenzen gibt, welche für Ihre Architektur zählen und wann Sie die aktuelle Zahl nachprüfen sollten. Die Zahlen werden sich ändern. Die Architekturfrage bleibt.

Ein durchgerechnetes Beispiel: Apex-Freigabe

Hier ist eines meiner häufigsten Beispiele für die Fragen in der Praxis. Wir erhalten eine Anforderung für eine komplizierte Freigabe, die sich mit keiner der eigentümer- oder kriterienbasierten Freigaberegeln erfüllen lässt. Das führt uns zur Apex-Freigabe (Apex Sharing): Code, der die Freigabedatensätze selbst schreibt. Jetzt müssen wir also wissen, was Apex-Freigabe ist, wo sie eingesetzt wird, wie man sie verwendet und so weiter. Es ist eine Eskalation: Apex-Freigabe ist die Alternative (Frage 4) für den Fall, dass die benötigten Regeln über das hinausgehen, was eigentümer- und kriterienbasierte Freigabe ausdrücken kann.

Jetzt zu ihren Schwächen (Frage 6). Angenommen, wir haben eine Kunden-Community mit 10 oder 20 Millionen Mitgliedern und verwenden die Lizenz Customer Community, nicht Customer Community Plus. Das sind Benutzer mit hohem Volumen. Sie haben keine Rollen und nutzen das Freigabemodell überhaupt nicht: Ihr Zugriff kommt aus Freigabesätzen und Freigabegruppen, zugeordnet über ihren Account und Kontakt. Es gibt keinen Freigabedatensatz, den Apex für sie schreiben könnte, also funktioniert Apex-Freigabe für sie nicht. Und die Frage nach Kosten und Lizenzen (Frage 9) hat uns dorthin gebracht: Die Lizenzwahl hat entschieden, welche Freigabewerkzeuge es überhaupt gibt.

So wie Apex-Freigabe die Alternative zu eigentümer- und kriterienbasierten Regeln war, kann Ihnen also ein Fall begegnen, in dem Sie eine Alternative zur Apex-Freigabe brauchen. Und an diesem Punkt gibt es wirklich keine konfigurationsbasierten Optionen für komplexe Freigaberegeln mehr. Am Ende machen Sie das Objekt schreibgeschützt und steuern den Zugriff über Apex. Deshalb stellen Sie alle neun Fragen, bevor Sie wählen, nicht danach.

Lernen Sie die Plattform nicht auswendig

Das ist am wichtigsten, wenn Sie Salesforce-Architektur lernen. Versuchen Sie nicht, Salesforce auswendig zu lernen. Das geht nicht: Die Plattform ist zu groß und ändert sich zu schnell. Ich arbeite seit Langem mit Salesforce und lerne immer noch dazu. Das ist normal.

Was Sie entwickeln sollen, ist ein Rahmen zum Lernen. Wenn Salesforce morgen eine neue Funktion veröffentlicht, muss ich sie nicht schon gesehen haben. Ich weiß, was ich fragen muss: Was ist es, wo passt es hin, wie verwende ich es, was könnte ich sonst verwenden, worin ist es gut, wo hat es Schwierigkeiten, wie erkläre ich es, wie betreibe ich es, und was kostet es und wo sind die Grenzen? Jetzt kann ich anfangen, es zu beurteilen. Das ist viel wertvoller, als eine weitere Funktionsmatrix auswendig zu lernen.

Über die Prüfung hinaus: KI beantwortet die neun Fragen schneller, und irrt sich dabei leichter. Begegnen Sie einer Technologie, die Sie nicht kennen, können Sie die KI bitten, sie zu erklären, drei Ansätze zu vergleichen, ihre Grenzen und typischen Fehlerbilder aufzulisten oder gegen ihren Einsatz zu argumentieren. Das ist ein bemerkenswerter Rechercheassistent. Aber er kann falschliegen, veraltet sein oder zwei ähnlich benannte Produkte oder Editionen selbstbewusst verwechseln. Für alles, was eine Entscheidung beeinflusst, prüfen Sie nach: Folgen Sie der Quelle und prüfen Sie die aktuelle Dokumentation, Grenzen und Lizenzen. Vertrauen, aber überprüfen (Modul 7).

Lernen Sie die Fragen, nicht nur die Antworten

Wir werden in diesem Kurs vielen Technologien begegnen. Ich möchte nicht, dass Sie Antworten sammeln; ich möchte, dass Sie die Fragen üben. Wenn wir über Big Objects, externe Daten, Data 360, Integrationsmuster oder eine KI-Funktion sprechen, die Salesforce sechs Monate nach dem Schreiben dieses Kapitels veröffentlicht, stellen Sie dieselben neun Fragen.

Die Antworten werden sich ändern. Die Fragen sind beständig. Das macht dies zu einem Architekturrahmen statt zu einem Lernleitfaden.

Kennen Sie Ihre Werkzeuge: worin sie gut sind, worin sie schlecht sind, was Sie sonst verwenden könnten, was sie kosten und wo sie brechen. Und wissen Sie genug, um die Entscheidung den Menschen zu erklären, die damit leben müssen. So lernen Architekt:innen Technologie.

Was Architekt:innen hier entscheiden

• Ob ein Werkzeug zum Problem passt, beurteilt anhand aller neun Fragen, nicht nur danach, ob es sich konfigurieren lässt.
• Welche Alternativen es gibt und was Kosten, Lizenzen und Grenzen des Werkzeugs in Ihrer Größenordnung bedeuten.
• Wer es in drei Jahren warten wird, und wie.
• Welche Fakten über das Werkzeug zu prüfen sind, bevor man sich darauf verlässt.

Weiterlesen

• About High-Volume Community or Site Users (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-10-09; erneut geprüft am 2026-10-12): Benutzer mit hohem Volumen (die Lizenzen External Apps, Customer Community, High Volume Customer Portal und Authenticated Website) haben keine Rollen; ihr Zugriff kommt aus Freigabesätzen und Freigabegruppen; sie können nicht in eigentümerbasierte Freigaberegeln aufgenommen werden, und Datensätze, die ihnen gehören, können nicht manuell freigegeben werden.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (auf Englisch, geprüft am 2026-10-09; erneut geprüft am 2026-10-12): Benutzer mit hohem Volumen (Customer Community, High Volume Customer Portal, Authenticated Website) nutzen das Freigabemodell nicht, weil ihre Lizenzen keine Rollen unterstützen; der Zugriff funktioniert über die Zuordnung des Benutzers zu den Account- und Kontakt-Nachschlagefeldern, über Freigabesätze oder Freigabegruppen. Dieselbe Seite nennt, wann die Apex-verwaltete Freigabe das richtige Werkzeug ist.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), Frage in der Trailblazer Community, November 2024 (auf Englisch, geprüft am 2026-10-09; erneut geprüft am 2026-10-12): Ein Praktiker berichtet, dass das Einfügen von Freigabedatensätzen für Benutzer mit hohem Volumen mit einem Fehler scheiterte. Ein Erfahrungsbericht, keine offizielle Dokumentation. (Die Online-Trailblazer-Community wird am 30. Oktober 2026 schreibgeschützt; der Link kann sich ändern.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-10-09): Ein Freigabesatz gewährt Zugriff auf Datensätze, die mit dem Account oder Kontakt des Benutzers verknüpft sind.