Die Frage, die dieses Modul beantwortet: Wie zeichne ich eine Landschaft, die zeigt, wohin die Daten gehen?
Geben Sie mir ein neues Szenario und ein leeres Whiteboard, und eines der ersten Dinge, die ich zeichne, ist die Systemlandschaft. Nicht schön, nicht jede API, noch nicht das Datenmodell. Ich will das Unternehmen sehen: wer die Benutzer sind, welche Systeme beteiligt sind, wo Salesforce sitzt, was es umgibt, woher die Daten kommen und wohin sie gehen. Und dann will ich die Pfeile abgehen. Eine gute Landschaft ist kein Bild aus Kästen. Sie ist ein Weg, Architekturentscheidungen offenzulegen.
Das lasse ich CTA-Kandidat:innen üben. Lesen Sie das Szenario, dann beginnen Sie zu zeichnen. Warten Sie nicht, bis Sie alles im Kopf gelöst haben; das Zeichnen hilft Ihnen beim Lösen. Deshalb ist die Hausaufgabe nach dem ersten Tag, die Landschaft zu beginnen, bevor man einen ersten Versuch am Datenmodell wagt. Zeichnen Sie zuerst das Datenmodell, haben Sie schon angenommen, was in Salesforce gehört. Zeichnen Sie zuerst die Landschaft, sehen Sie die Systeme, die diese Entscheidung prägen sollten.
Beginnen Sie grob, dann gehen Sie in die Tiefe: zuerst das ganze Unternehmen, dann das Detail dort, wo es zählt.
Es gibt viele Wege, eine Systemlandschaft zu zeichnen. Das ist einfach mein Weg, über viele Jahre verfeinert, und ich teile ihn, damit Sie sehen, wie man schnell eine zusammenstellt. Ich verwende ihn für jede Salesforce-Landschaft, und er liest sich wie ein Satz: Menschen links erreichen Salesforce in der Mitte, vertraut über die Systeme darüber, bedient über die Kanäle darunter und verbunden mit dem Backoffice rechts.
Menschen links, von oben nach unten: interne Benutzer, Partner, Kunden. Noch nicht jede Persona; genug, um zu beantworten: Wer versucht, diese Architektur zu erreichen? Jede Gruppe zeigt dorthin, wo sie hereinkommt: interne Benutzer zu Salesforce, Partner zur Partner-Community, Kunden zur Kunden-Community. Systeme existieren nicht für sich. Jemand, oder etwas, versucht, sie zu nutzen.
Schritt 2 von 6: Wer versucht, diese Architektur zu erreichen?
Salesforce in der Mitte. Ein schlichter Kasten. Nicht weil Salesforce der Mittelpunkt des Unternehmens wäre (wir haben gerade drei Module damit verbracht zu sagen, dass es das nicht ist), sondern weil es das System ist, um das herum ich entwerfe. Es ist der Anker.
Die Communities direkt darunter, anliegend. Eine Partner-Community und eine Kunden-Community sind eigene Endpunkte, also bekommen sie eigene Kästen. Aber sie liegen direkt an Salesforce an, denn nichts muss integriert werden, um sie zu erreichen: Sie laufen in derselben Org.
Schritt 3 von 6: Salesforce in der Mitte, die Communities direkt darunter.
Identität darüber. Die Identitätsanbieter kommen nach oben, die, die in der Entwicklung vergessen werden: einer für interne Benutzer, vielleicht ein weiterer für Partner. AppExchange-Pakete kommen ebenfalls dorthin, nach rechts versetzt, denn das sind Funktionen, die in die Org gebracht werden, keine Backoffice-Systeme, die Daten mit ihr austauschen. Öffentliche Websites sitzen oben links.
Schritt 4 von 6: Identität darüber, der Kasten, der in der Entwicklung vergessen wird.
Integration, dann das Backoffice, rechts. Die Integrationsschicht, ein ESB oder iPaaS (oder MuleSoft, wenn es genannt wird), ist ein hoher Balken direkt rechts von Salesforce. Die internen Systeme sitzen dahinter: die ERPs, die Finanzen, das Auftragsmanagement, Altsysteme, das Data Warehouse. Jetzt liest sich die Seite von links nach rechts: Menschen, Salesforce, Integration, Backoffice.
Schritt 5 von 6: Integration, dann das Backoffice.
Kanäle darunter. Alles, was einen direkten Draht zu Kunden hat: E-Mail-to-Case, Web-to-Lead, Telefon, Messaging.
Daten hinein und hinaus, unten rechts. Externe Datenquellen, Archive, Datenladevorgänge.
Data 360 rechts, unter der Integrationsschicht. Benutzer verbinden sich nie damit, und sein Tenant verbindet sich mit vielen Backend-Systemen, also sitzt es bei den Datenleitungen, wo diese Linien kurz bleiben: neben den internen Systemen, dem Data Warehouse und den Daten unten rechts. Datenteams öffnen zwar seine Bildschirme, aber diese Bildschirme sind in der Org: Data 360 ist nahe am Core (Near-Core), auf dem Core verwaltet und außerhalb des Core gehostet (Modul 1). Eine Linie zurück zu Salesforce zeigt, wer es verwaltet. Wo Sie den Kasten platzieren, sollte erzählen, was er tut.
Nichts an dieser Geometrie ist heilig. Der Wert einer Konvention ist, dass ich die Bildsprache nicht jedes Mal neu erfinde, und wer eines meiner Diagramme gesehen hat, liest das nächste schneller.
Halten Sie die Notation einfach. Jedes System ist eine Karte: sein Name, seine Rolle und ein kleines Symbol, das sagt, welche Art von Ding es ist: ein ERP, eine Datenbank, ein Identitätsanbieter, eine Gruppe von Menschen. Die Bereiche, die ich gerade beschrieben habe, werden als blasse, beschriftete Zonen gezeichnet, sodass das Layout selbst sichtbar ist. Eine Legende unten sagt, was jedes Symbol und jede Linie bedeutet.
Packen Sie nicht zu viel in einen Kasten. Nur bei einer sehr komplizierten Landschaft öffne ich Salesforce in seine Teile (Sales Cloud und Service Cloud innerhalb der Org, mit Pfeilen zwischen ihnen). Und erfinden Sie keine fünfzehn Formen, es sei denn, jede sagt dem Betrachter etwas. Ich will, dass jemand die Landschaft dreißig Sekunden lang ansieht und beginnt, die Architektur zu verstehen. Schick hilft nicht. Klar hilft.
Warten Sie nicht auf den Detailentwurf, um über Volumen nachzudenken. Ein Pfeil, der 500 Produkte pro Nacht trägt, und einer, der 200.000 GPS-Messwerte am Tag trägt, können in der Landschaft genau gleich aussehen. Sie sind nicht dasselbe Problem. Also zählen Sie, bevor Sie einen einzigen Pfeil zeichnen, was sich bewegt. Beginnen Sie das Inventar hinter dem Bild mit den Mengen: eine Zeile pro wichtigem Datenbestand, mit seinem Volumen. Die Nullen tauchen vielleicht nie auf den Pfeilen auf, aber Sie müssen wissen, wann Sie in hohe Zahlen kommen: Tausende oder Millionen in einer Stunde, Hunderttausende von Transaktionen, sogar zehn bis hundert Transaktionen pro Sekunde.
Diese Zahlen bestimmen den Mechanismus. Ein paar hundert Datensätze pro Nacht sind ein Batch. Ein Aufruf, auf den jemand wartet, kann synchron sein, wenn das Volumen es zulässt. Zehn bis hundert pro Sekunde brauchen vielleicht Ereignisse, etwa Plattformereignisse, statt eines Aufrufs pro Datensatz. Der Pfeil sieht gleich aus; das Volumen entscheidet, was ihn trägt, also halten Sie es im Inventar fest, wo der Mechanismus gewählt wird.
Der Mechanismus kann sogar die Richtung des Pfeils ändern. Schicken Sie ein paar Datensätze pro Minute, und Salesforce kann einfach hinausrufen: Der Pfeil beginnt bei Salesforce. Schicken Sie weit mehr, und Salesforce veröffentlicht vielleicht stattdessen Ereignisse auf dem Ereignisbus; das externe System abonniert sie und ruft herein, um sie abzuholen, also beginnt der Pfeil jetzt am anderen Ende. Noch größer, etwa eine nächtliche Synchronisierung von Millionen Datensätzen, und es ist ein Batch-Prozess. Kennen Sie Ihre Mengen also früh, wenn Sie beginnen, die Mechanismen zu entwerfen, denn die Mengen können die Pfeile neu zeichnen.
Volumen zählt an zwei Stellen, aus zwei Gründen. In einem Datenmodell brauche ich es, um große Datenvolumen im Blick zu behalten und die Archivierung zu planen; Teil 2 geht darauf ausführlich ein. In einer Systemlandschaft bestimmen die großen Zahlen im Inventar die Wahl des Integrationsmusters und des Mechanismus. Modul 6 setzt echte Nullen in die Landschaft von Steve Trucking und ihr Inventar. Mit den Mengen in der Hand zeichnen Sie die Pfeile.
Mit den Systemen an ihrem Platz verbinden Sie sie, und die Landschaft wird zur Architektur. Ein Kasten ist ein System; der Pfeil zeigt, wer die Verbindung aufbaut. Er beginnt bei dem System, das die Verbindung öffnet, und zeigt auf das, das es aufruft: Client zu Server. Die Beschriftung sagt, was sich bewegt und in welche Richtung.
Diese Regel gilt für Systemlandschaften, in denen Systeme mit Systemen sprechen. In einem Datenflussdiagramm folgt der Pfeil den Daten, wie Sie es erwarten würden. Übertragen Sie die Landschaftsregel nicht auf andere Diagramme; sie stiftet dort nur Verwirrung.
Die Pfeile eingefügt. Jeder Kasten ist, wo er war; jeder Pfeil beginnt bei dem System, das die Verbindung öffnet, und seine Beschriftung sagt, was sich bewegt und in welche Richtung.
Wenn also die Integrationsschicht Produkte in Salesforce schiebt, läuft der Pfeil von der Integrationsschicht zu Salesforce, beschriftet mit Produkte hinein. Wenn Salesforce hinausruft, um sie abzuholen, beginnt der Pfeil bei Salesforce, immer noch beschriftet mit Produkte hinein. Dieselben Daten, ein anderes Gespräch, und dieser Unterschied sagt mir, wer die Anmeldedaten braucht und wer mit dem Fehler umgehen muss. Salesforce schickt den Auftrag durch die Integrationsschicht: Aufträge hinaus. Die Abwicklung des ERP kommt zurück: Auftragsstatus hinein. Jetzt sehe ich, wer jedes Gespräch beginnt, wo Daten in Salesforce hineinkommen und wo sie hinausgehen, welche Flüsse Grenzen überschreiten, wo die Eigentümerschaft wahrscheinlich liegt und wo ich weiter fragen muss.
Und denken Sie an Modul 1: Wann immer ich nur einen Fluss sehe, werde ich besorgt. Auf oberster Ebene hängt ein Pfeil Aufträge hinaus von Rückflüssen ab: Kunden hinein, Produkte hinein, Preise. Schauen Sie noch genauer hin, und da ist der Rückweg: Annahme, Ablehnung, Status, eine Rechnungsnummer, eine Stornierung. Die Pfeile geben mir etwas Konkretes, das ich hinterfragen kann.
Hier hört die Landschaft auf, PowerPoint-Kunst zu sein. Vor dem Prüfungsgremium kann jeder Pfeil drei Fragen auslösen, und ich möchte, dass Sie die Antworten haben:
Wie authentifiziert er sich? OAuth, ein Zertifikat, benannte Anmeldedaten, etwas anderes?
Ist er synchron oder asynchron? Wartet Salesforce auf das ERP, oder veröffentlicht es und macht weiter? Wie schnell braucht das Geschäft das Ergebnis?
Was ist der Mechanismus? Ein REST-Aufruf, ein Ereignis, eine Datei, eine Message Queue, über MuleSoft oder direkt?
Und dann: Was passiert, wenn die andere Seite ausfällt? Jeder Pfeil braucht einen Mechanismus. Wenn Sie ihn nicht erklären können, ist die Linie Dekoration.
Und „Fire and forget“ ist keine Antwort. Es heißt meist: „Ich habe nicht entworfen, was nach dem Abfeuern passiert.“ Ist es angekommen? Wurde es angenommen? Ist es gescheitert? Wird es wiederholt? Wer weiß, dass es feststeckt? Was, wenn dieselbe Nachricht zweimal ankommt? Nichts davon kommt in die Landschaft, die sonst unlesbar würde. Aber der Pfeil soll Sie wissen lassen, dass es diese Fragen gibt.
Zoomen Sie auf einen einzelnen Pfeil, und da sind ein Client und ein Server, und jeder besitzt seine Hälfte. Der Client öffnet die Verbindung: Er braucht den Endpunkt und den Port, holt sich zuerst ein Token vom Authentifizierungsserver, ruft das Protokoll und den Vertrag auf, die der Server festlegt, und entscheidet, ob er wartet. Nur der Client sieht den ganzen Hin- und Rückweg, also kann nur der Client es erneut versuchen. Der Server lauscht, legt Protokoll, Vertrag und Nutzlast fest, validiert, was hereinkommt, und sieht nur seinen eigenen Teil. Wenn ich einen Pfeil zeichne, weiß ich schon, welches Ende welches ist, und das sagt mir, wem jede dieser Fragen gehört.
Ein Pfeil, herangezoomt: Der Client übernimmt, der Server legt fest. Nichts davon kommt in die Landschaft, aber jeder Pfeil hat es.
Jetzt drehen Sie den Pfeil um. Wenn das ERP Salesforce aufruft, ist Salesforce der Server: Es legt die APIs fest, betreibt seinen eigenen Autorisierungsserver und entscheidet über eine External Client App und einen Integrationsbenutzer, was der Aufrufer tun darf. Dieselben Fragen, die andere Seite.
Hier wird in der Architektur oft ein gutes Diagramm ruiniert: Ein Artefakt soll alles beantworten. Die Landschaft bekommt API-Namen, Nutzlasten, Wiederholungen, Fehlerwarteschlangen, Transformationen, jeden Callback, und bald kann sie niemand mehr lesen. Tun Sie das nicht. Die Landschaft ist das große Bild: Systeme und die wichtigen Flüsse zwischen ihnen.
Wenn ich eine Interaktion erklären muss, zeichne ich ein zweites Diagramm, aber nicht für jede Integration. Wenn System A etwas an B schickt, oder sogar fragt und eine Antwort bekommt, reicht der beschriftete Pfeil. Eine Swimlane will ich, wenn der Prozess zu einem Gespräch wird: A ruft B auf, B fragt bei C nach, C antwortet, B legt etwas an und ruft A zurück, eine Person genehmigt, ein anderes System macht weiter. Meine Faustregel: mehr als ein oder zwei Hin-und-her-Wechsel, und die Abfolge bekommt ihre eigene Swimlane. Pfeile in der Landschaft; das Gespräch in der Swimlane.
Und beachten Sie, dass ein Pfeil dort etwas anderes bedeutet. In der Landschaft ist ein Pfeil eine Verbindung: wer sie öffnet und was sich bewegt. In einer Swimlane ist jeder Pfeil eine Nachricht in einem Gespräch, der Reihe nach gelesen: Eine Anfrage geht in die eine Richtung, eine Antwort kommt in die andere zurück, und der nächste Schritt folgt.
Drei Pfeile in der Landschaft; sechs Schritte in der Swimlane. In der Landschaft ist ein Pfeil eine Verbindung; in einer Swimlane ist jeder Pfeil eine Nachricht, der Reihe nach.
Wenn die Landschaft weitgehend fertig aussieht, gehen Sie sie ab, Pfeil für Pfeil. ERP zu Salesforce: Was bewegt sich, wem gehört es, wie authentifiziert es sich, was ist der Mechanismus, synchron oder asynchron, wie aktuell muss es sein? Dann der nächste Pfeil und der nächste. Hier tauchen Lücken auf. „Ach, wir haben nie geklärt, wie der Partner das eigentlich schickt.“ „Wir schicken Aufträge ans ERP, aber wir haben nicht entworfen, wie abgelehnte zurückkommen.“ Gut. Sie haben es am Whiteboard gefunden statt in der Produktion.
Das Bild muss lesbar bleiben, also kommen die Details in das Inventar dahinter. Sie haben es mit den Mengen begonnen; jetzt vervollständigen Sie es, eine Zeile pro wichtigem Datenbestand oder Fluss:
Deshalb mag ich dieses Artefakt: Es hilft mir beim Denken. „Wie berichten wir über Salesforce und das ERP hinweg?“ Das ist die Frage aus Modul 3: Welches meiner Diagramme löst das wunderbar? Die Landschaft. Wenn alles auf dem Core ist, Standardberichte. Wenn die Daten im ERP und im Data Warehouse liegen, sehen Sie es sofort. „Wo sollte dieses Kundenattribut als Stammdatum geführt werden?“ Schauen Sie, welche Systeme es nutzen und welches den Kunden schon besitzt. „Braucht Salesforce jeden GPS-Messwert?“ Wer erzeugt ihn, wer nutzt ihn, was ist die Arbeitslast? Vielleicht braucht Salesforce die aktuelle Position, und eine andere Plattform hält die Historie. Die Landschaft gibt Ihnen nicht die Antwort. Sie gibt Ihnen den richtigen Blick auf das Problem.
Zeichnen Sie den Ist-Zustand, bevor Sie ihn reparieren
Noch eine Disziplin. In einem bestehenden Unternehmen zeichnen Sie, was existiert, nicht was Sie sich wünschen würden. Die Tabelle, die jeden Freitag per E-Mail kommt: zeichnen Sie sie. Die CSV des Partners auf einem SFTP-Server: zeichnen Sie sie. Die Integration, die aus historischen Gründen am ESB vorbeigeht: zeichnen Sie sie. Menschen, die Daten zwischen zwei Systemen abtippen: zeigen Sie es. Beschönigen Sie die Wirklichkeit nicht, während Sie sie dokumentieren. Sie brauchen die aktuelle Landschaft, bevor Sie die Ziellandschaft entwerfen, und genau das tun wir für Steve Trucking in Modul 6.
Über die Prüfung hinaus: Was KI ändert. Die Landschaft wird zur Karte für Agenten. Wenn ein Agent „Wo ist meine Lieferung?“ beantwortet, muss die Landschaft sagen, ob die Antwort aus Salesforce, einem Partnersystem, der Telematik, dem ERP oder einer Mischung kommt. Agenten beseitigen keine Systemgrenzen; sie machen es noch wichtiger zu wissen, welches System maßgeblich ist und wie man es sicher erreicht.
Welche Systeme und Benutzergruppen in die Landschaft gehören und wie ihre Platzierung ihre Rolle zeigt.
Welche Flüsse Systemgrenzen überschreiten, in welche Richtung und was zurückkommt.
Wie jede Verbindung sich authentifiziert, welcher Mechanismus sie trägt und ob sie synchron, asynchron, Batch oder föderiert ist.
Wann ein beschrifteter Pfeil reicht und wann eine Interaktion eine eigene Swimlane braucht.
Was das Inventar hinter dem Bild festhält: Eigentümer, Arbeitslast, Volumen, Org, Timing, Authentifizierung und kopieren, referenzieren oder föderieren.
Die Landschaft zeichne ich nicht, nachdem die Architektur fertig ist. Mit ihr finde ich die Architektur. Und wenn Sie glauben, sie ist fertig, bewundern Sie sie nicht. Gehen Sie sie ab. Jeder Pfeil, den Sie noch nicht erklären können, zeigt Ihnen, wo die Arbeit liegt.
