Architektur ist die Kunst der Abwägung

🌐 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 4 von 7 im Kapitel Denken wie Datenarchitekt:innen, dem ersten Kapitel des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Der Umkehrbarkeitstest · Weiter: Für heute bauen. Für morgen planen. Für das Scheitern planen.

Die Frage, die dieses Modul beantwortet: Wenn mehrere Lösungen funktionieren könnten, wie wählen Architekt:innen aus, und wie erklären sie die Wahl?

Ginge es in der Architektur einfach darum, die richtige Antwort zu finden, wäre sie viel leichter. Die Plattform lernen, die Muster lernen, die Grenzen lernen, das Richtige wählen, fertig.

So funktioniert echte Architektur nicht. Die schweren Entscheidungen fallen meist nicht zwischen einer offensichtlich guten und einer offensichtlich schlechten Lösung. Sie fallen zwischen mehreren Lösungen, die funktionieren könnten, jede mit Vor- und Nachteilen, jede bewegt die Architektur in eine etwas andere Richtung. Genau dort verdienen sich Architekt:innen ihren Platz am Tisch.

Viele Wege, das Problem zu lösen

Eine Version dieses Beispiels habe ich beim Unterrichten von Architekt:innen schon oft verwendet.

Es kann in Salesforce viele Wege geben, ein Problem zu lösen. Manchmal nenne ich eine Zahl, sagen wir zehn, aber das ist ein Bild, keine Zählung. Viele der Optionen haben von Anfang an Schwächen: Sie stoßen an eine Grenze der Plattform, verfehlen eine entscheidende Anforderung oder schaffen ein Sicherheits- oder Leistungsproblem, das wir nicht hinnehmen können. Die können wir schnell beiseitelegen. Einige andere funktionieren heute, bekommen aber Probleme, wenn die Daten wachsen. Sie sind technisch funktionsfähig, halten aber dem Wachstum nicht stand, von dem wir schon wissen, dass es kommt.

Was übrig bleibt, ist eine kleine Zahl von Optionen, die Ihre Anforderungen auch in Zukunft tragen können, und jetzt wird es interessant. Jede davon könnte funktionieren, skalieren und die Anforderungen erfüllen. Welche ist also richtig? Vielleicht alle. Die Aufgabe von Architekt:innen ist es, die Unterschiede zu verstehen.

Selbst etwas so Einfaches wie eine Auswahlliste funktioniert heute und kann Probleme bekommen, wenn die Daten wachsen. Eine Auswahlliste ist für Benutzer einfach. Aber fragen Sie, woher die Werte kommen und wie viele es werden können. Auswahllisten funktionieren am besten mit weniger als etwa 20 Werten. Gelegentlich gehen wir bis 50, wie bei den US-Bundesstaaten, und selten über 100, wie bei Ländern, und die werden schon unhandlich. Kennen Sie also bei jeder Auswahlliste die Obergrenze. Und die Werte einer Auswahlliste zu ändern ist eine Metadatenänderung, keine Datenänderung.

Verwenden Sie stattdessen eine Nachschlagebeziehung, wird die Benutzeroberfläche etwas komplexer. Aber die Liste kann ohne Obergrenze weiterwachsen, und neue Werte können aus einer Integration kommen. Das ist eine Abwägung gegen die Benutzerfreundlichkeit. Das ist die Balance.

Click to enlarge

Optimal heißt nicht perfekt

Ich verwende das Wort optimal mit Bedacht. Eine optimale Architektur ist nicht eine, in der jede einzelne Entscheidung perfekt ist; diese Architektur gibt es wahrscheinlich nicht. Es ist eine, in der die Gesamtlösung ausgewogen ist.

Angenommen, Lösung A bietet die beste Leistung, ist aber teuer und schwer zu warten. Lösung B kostet weniger und ist leichter zu betreiben, gibt aber etwas Leistung auf. Lösung C ist für die Zukunft flexibler, bringt heute aber mehr Komplexität. Welche ist optimal? Aus diesen Fakten allein kann ich das nicht beantworten. Ich muss das Geschäft, die Anforderungen und die Prioritäten kennen und wissen, welche Einschränkungen echt sind und welche Vorlieben. Architektur hängt vom Kontext ab. Deshalb kann das Muster, das für einen Kunden richtig war, für den nächsten völlig falsch sein.

Und Ihre Aufgabe in der Datenarchitektur ist es, diese Entscheidungen auszubalancieren. Dutzende davon treffen Sie selbst oder mit Ihrem Team. Wissen Sie, welche das sind, und erkennen Sie, wann eine Entscheidung größere Auswirkungen auf Kosten, Zeit oder Funktionalität hat und an die maßgeblichen Entscheidungsgremien gehen muss.

Eine suboptimale Entscheidung kann Teil einer optimalen Architektur sein

Das ist eine der wichtigsten Ideen in diesem Kapitel. Manchmal treffe ich bewusst eine suboptimale Entscheidung in einem Teil der Architektur, weil sie die Gesamtlösung besser macht.

Vielleicht dupliziere ich eine kleine Menge Daten, weil das Entfernen der Duplizierung unnötige Integrationskomplexität schaffen würde. Vielleicht wähle ich ein einfacheres Datenmodell, weil das theoretisch sauberere Berichte und die tägliche Arbeit viel schwerer machen würde. Vielleicht nehme ich kleine Leistungseinbußen in Kauf, weil die Alternative Infrastruktur erfordert, die die Organisation noch nicht betreiben kann.

Betrachten Sie irgendeine davon isoliert, und Sie würden sagen, sie ist nicht optimal. Richtig. Aber in der Architektur geht es nicht darum, jede Komponente für sich zu optimieren, sondern das System. Eine lokal suboptimale Entscheidung kann Teil einer global optimalen Architektur sein, solange wir die Abwägung verstehen, die wir treffen. Gefährlich ist, die Abwägung zu treffen, ohne zu wissen, dass man sie trifft.

Wissen, was Sie dafür hergeben

Wann immer mir jemand sagt „Das ist die beste Lösung“, lautet meine nächste Frage „Die beste worin?“ Die schnellste? Die billigste? Die einfachste? Die skalierbarste, sicherste, flexibelste? Am leichtesten zu betreiben, am schnellsten zu liefern, am wenigsten abhängig von Spezialwissen? Es gibt fast immer eine andere Dimension, in der die Antwort nicht „die beste“ lautet. Das ist die Abwägung. Ich will wissen, was wir bekommen, und ich will auch wissen, was wir aufgeben.

Nehmen Sie zwei Optionen für einen großen Bestand an Unternehmensdaten. Die eine kopiert die Daten in Salesforce, was Salesforce-eigene Funktionen leichter nutzbar macht, aber nun sind wir dafür verantwortlich, sie zu bewegen, zu speichern, zu synchronisieren, eine weitere Kopie abzusichern und mit Latenz umzugehen. Die andere lässt die Daten, wo sie sind, und ruft sie bei Bedarf ab. Wir haben etwas Duplizierung entfernt, aber jetzt zählen Verfügbarkeit, Abfrageleistung, Netzwerkabhängigkeiten und die Fähigkeiten des entfernten Systems mehr. Keine der beiden Beschreibungen sagt uns, was wir wählen sollen. Sie sagen uns, welche Fragen wir stellen müssen.

Anforderungen sind nicht alle gleich

Abwägungen zwingen uns auch zu sehen, dass nicht jede Anforderung gleich viel Gewicht hat.

Jemand sagt: „Die Daten müssen sofort verfügbar sein.“ Gut, was heißt sofort? Eine Sekunde, zehn Sekunden, eine Minute? Und warum? Vielleicht geht es um Betrugserkennung, wo Sekunden zählen. Vielleicht wartet nur jemand nicht gern auf den nächtlichen Ladelauf. Das sind sehr unterschiedliche Anforderungen, und in der Architektur fragen wir so lange nach, bis wir wissen, welche wir haben.

Ich mag Anforderungen, die Nachfragen standhalten: wie viel, wie viele, wie schnell, wie oft, für wen, und was passiert, wenn nicht? „Schnell“ ist keine Architekturanforderung. „95 Prozent der Kundenaktualisierungen müssen den Servicemitarbeitenden innerhalb von 30 Sekunden zur Verfügung stehen“ kommt einer schon viel näher. Jetzt können wir Abwägungen beurteilen.

Einschränkungen ändern die Antwort

Manchmal ist die Architektur gar nicht durch Technologie eingeschränkt. Sie ist eingeschränkt durch Geld, Menschen, Zeit, Lizenzen oder die Reife der Organisation.

Eine Architektur, die technisch hervorragend ist, aber ein Betriebsteam braucht, das das Unternehmen nicht hat, ist keine gute Architektur. Eine Funktion, die das Problem elegant löst, aber Lizenzen erfordert, die der Kunde nicht kaufen wird, ist auch nicht die Lösung. Und die perfekte dreijährige Transformation hilft einem Unternehmen nicht, das in acht Wochen starten muss.

Nichts davon heißt, dass wir gute Architektur wegen einer Frist aufgeben. Es heißt, dass wir verstehen, welche Kompromisse wir eingehen, warum und welche Folgen wir akzeptieren, und idealerweise, wie wir vom Kompromiss von heute zur Architektur von morgen kommen.

Architekt:innen brauchen ein Bild von „optimal“

Hier liegt eine interessante Spannung. Ich sage Ihnen, dass es oft nicht die eine perfekte Antwort gibt, und gleichzeitig möchte ich, dass Sie ein Bild davon im Kopf tragen, wie eine optimale Lösung aussieht. Das widerspricht sich nicht. Sie brauchen einen Bezugspunkt.

Wenn ich ein Datenmodell betrachte, möchte ich wissen, was ich bauen würde, wenn ich ohne unnötige Einschränkungen für die Anforderungen optimieren könnte. Wenn uns dann echte Einschränkungen von diesem Entwurf wegdrängen (wir machen einen Teil des Modells flacher, duplizieren Daten, verschieben eine Integration, akzeptieren einen vorübergehenden manuellen Prozess), mache ich keine zufälligen Kompromisse. Ich weiß, in welche Richtung ich mich vom Optimum wegbewege und warum. Das ist die Kunst der Architektur, und das Gespür dafür braucht Übung.

Zeichnen Sie es

Eine der besten Arten, eine Abwägung zu verstehen, ist, sie zu zeichnen. Architekturdiagramme sind keine Dekoration für einen Foliensatz; sie sind Denkwerkzeuge. Wenn wir zwischen zwei Ansätzen wählen, zeichnen Sie beide. Wo liegen die Daten, und wohin bewegen sie sich? Wem gehören sie? Wo sind die Grenzen, und wo wird Sicherheit durchgesetzt? Was passiert, wenn etwas ausfällt, und was ändert sich, wenn das Volumen wächst?

Ein Diagramm holt Unklarheiten ans Licht, und es gibt allen dasselbe Bild, auf das sie zeigen können.

Wie wichtig das ist, habe ich bei einem Projekt mit einem Versorgungsunternehmen gelernt. Besprechung um Besprechung erklärte ich dieselben Konzepte erneut und führte das Gespräch zurück zum ursprünglichen Entwurf. Also änderte ich, wie ich diese Besprechungen leitete: Jede Besprechung begann mit dem Datenmodell auf dem Bildschirm. Nicht das detaillierte mit jedem Feld. Ein zusammenfassendes Modell: Ein Account hat Kontakte, dieser Datensatz hat untergeordnete Datensätze, hier hängt die Arbeit dran. Im Raum saßen vor allem Führungskräfte, und es dauerte ein paar Minuten.

Weil es Besprechung für Besprechung dieselben Leute waren, wurde das Diagramm unsere gemeinsame Sprache. Die Leute begannen, seine Namen zu verwenden. Die wiederholten Fragen verschwanden, und die Besprechungen wurden viel einfacher. Ich nenne das die Besprechung erden: Ein einfaches Diagramm, jedes Mal gezeigt, war weit mehr wert, als es zu erstellen gekostet hat.

Das Ziel ist keine künstlerische Perfektion. Manchmal ist es ein detailliertes Diagramm für das Entwicklungsteam, manchmal fünf Kästen und sechs Pfeile für eine Führungskraft. Das Ziel ist Klarheit.

Erklären Sie die Abwägung

Gute Architekt:innen legen es der Reihe nach dar: Das sind die Optionen, die wir erwogen haben, das bringt uns jede, das kostet uns jede, diese Option empfehle ich, und das ist der Grund.

Beachten Sie, dass die Empfehlung nach den Abwägungen kommt. Ich möchte nicht, dass Architektur zu „Ich habe das schon einmal gemacht, vertrauen Sie mir“ wird. Erfahrung ist enorm wichtig; sie hilft Ihnen, Muster schneller zu erkennen und Probleme früher zu sehen. Aber Ihre Erfahrung sollte Ihre Begründung verbessern, nicht ersetzen. Unsere Aufgabe ist es nicht nur, die Architektur zu verstehen. Es ist, der Organisation zu helfen, die Entscheidung zu verstehen, besonders wenn die Menschen, die das letzte Wort haben, nicht aus der Architektur kommen.

Richtig denken. Schnell denken.

Sie werden nicht immer drei Wochen haben, um jede Option zu analysieren. Manchmal haben Sie drei Minuten. Eine Anforderung ändert sich in einer Besprechung, jemand nennt eine Einschränkung, die Sie nicht kannten, oder eine Führungskraft fragt: „Was, wenn wir das nächstes Jahr in Europa brauchen?“

Ich verwende den Satz Think Correct. Think Fast. (Richtig denken. Schnell denken.) Geschwindigkeit entsteht nicht dadurch, das Denken zu überspringen. Sie entsteht dadurch, genug gedacht zu haben, bevor der Moment kommt: Sie haben die Muster gelernt, Sie kennen die Plattform, Sie haben Fehlschläge gesehen, Sie wissen, welche Fragen zu stellen sind und welche Entscheidungen schwer umkehrbar sind. Deshalb arbeiten wir uns im ganzen Kurs durch Szenarien. Je mehr Entscheidungen Sie analysieren, desto schneller erkennen Sie die Form der nächsten.

Ich hatte einen Kunden, der Formulareingaben brauchte. Aber es gab viele Formulare, und die Fragen konnten sich im Lauf der Zeit ändern. Ich erkannte schnell, dass ein Umfrage-Datenmodell nötig war, ein Muster, auf das wir später im Kurs zurückkommen. Weil ich das Muster und die Lösung erkannte, konnte ich ein vollständigeres Datenmodell einbringen, eines, das auch die noch kommenden Anforderungen abdeckte, nicht nur die, die vor uns lagen.

Architektur ist Balance

Je tiefer wir in die Datenarchitektur einsteigen, desto öfter begegnen Ihnen Entscheidungen, bei denen ich mich weigere, Ihnen eine einfache Regel zu geben. Normalisieren oder flach halten? Die Daten kopieren oder föderieren? Synchron oder asynchron? Standardobjekt oder benutzerdefiniert? Archivieren oder online halten?

Es gibt Prinzipien, Muster und Grenzen und manchmal klar falsche Antworten. Aber oft ist es die Aufgabe von Architekt:innen, die richtige Balance für dieses System, dieses Geschäft und diesen Moment zu finden.

Wissen, wie optimal aussieht. Die Einschränkungen verstehen. Die tragfähigen Optionen erkennen. Die Abwägungen sichtbar machen. Dann die Entscheidung treffen.

Das ist keine Unentschlossenheit. Das ist Architektur.

Was Architekt:innen hier entscheiden

• Welche Optionen tragfähig sind und welche jetzt falsch sind oder in einem Jahr kippen.
• Was jede tragfähige Option gewinnt und aufgibt, gemessen an Anforderungen, die Nachfragen standhalten.
• Welche Einschränkungen echt sind und welche nur Vorlieben.
• Welche Option empfohlen wird, nachdem die Abwägungen dargelegt sind, und wie man sie erklärt.