Für heute bauen. Für morgen planen. Für das Scheitern planen.

🌐 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)

Mit KI erstelltes Bild

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

Modul 5 von 7 im Kapitel Denken wie Datenarchitekt:innen, dem ersten Kapitel des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Architektur ist die Kunst der Abwägung · Weiter: Kennen Sie Ihre Werkzeuge: die neun Fragen

Die Frage, die dieses Modul beantwortet: Wie entwirft man für die Anforderungen von heute und plant zugleich für Wachstum und für das Scheitern?

Einer der leichtesten Fehler in der Architektur ist, nur für die Anforderungen zu entwerfen, die gerade vor einem liegen. Wir haben ein Projekt, ein Backlog und Anforderungen. Wir bauen etwas, das sie erfüllt. Es funktioniert, und wir erklären den Sieg. Sechs Monate später ändert sich das Geschäft, oder die Daten wachsen, oder ein anderer Geschäftsbereich will es nutzen, oder wir kaufen ein Unternehmen, oder ein neues System muss integriert werden, oder etwas fällt aus, mit dem niemand gerechnet hat.

Nichts davon sollte Architekt:innen überraschen. Wir können nicht alles vorhersagen, was passieren wird, aber wir können in dem Wissen entwerfen, dass etwas passieren wird. Deshalb betrachte ich Architektur durch drei Blickwinkel:

Für heute bauen. Für morgen planen. Für das Scheitern planen.

Sie brauchen alle drei.

Click to enlarge

Für heute bauen

Architektur beginnt mit dem Problem, das wir tatsächlich haben. Das klingt selbstverständlich, aber in der Architektur kann man den umgekehrten Fehler zum kurzfristigen Denken machen: Wir können überarchitektieren. Was, wenn wir zwölf Unternehmen kaufen, eine Milliarde Kunden haben, in 40 Länder expandieren und jedes System eine Echtzeitintegration braucht? Vielleicht. Aber sind das echte Möglichkeiten, oder erfinden wir Probleme? In der Architektur geht es nicht darum, das raffinierteste System zu bauen, das wir uns vorstellen können. Es geht darum, das angemessene zu bauen.

Beginnen Sie also mit heute: was das Geschäft braucht, die tatsächlichen Volumen, Benutzer und Transaktionen, wie oft sich die Daten ändern und wie schnell sie sich bewegen müssen, wer Zugriff braucht und woher die Daten kommen und wohin sie gehen. Und vor allem: Warum? Diese Antworten geben uns etwas Konkretes zum Entwerfen.

Suchen Sie die stillschweigenden Anforderungen

Die Anforderungen, die man Ihnen nennt, sind nicht unbedingt alle Anforderungen, die Sie haben. Es gibt fast immer stillschweigende Anforderungen.

Das Geschäft sagt: «Wir brauchen Kundendaten in Salesforce.» Gut. Dann muss jemand diese Daten verantworten und entscheiden, wie aktuell sie sein müssen. Wir müssen wissen, was passiert, wenn das Quellsystem nicht verfügbar ist, wie wir bemerken, dass eine Synchronisation fehlschlägt, und welche Seite gewinnt, wenn Salesforce und die Quelle nicht übereinstimmen. Wir brauchen eine Aufbewahrungsfrist, ein Zugriffsmodell, eine Entscheidung zu sensiblen Feldern und einen Weg, fehlerhafte Daten zu korrigieren.

Nichts davon stand in der User Story. Es ist trotzdem alles Architektur. Ein grosser Teil des Wegs in die Architektur besteht darin, die Fragen zu erkennen, die noch niemand gestellt hat.

Kennen Sie Ihre Zahlen

Ich dränge Architekt:innen ständig zum Quantifizieren. Sagen Sie mir nicht, dass es viele Daten gibt; sagen Sie mir, wie viele. Zehntausend, zehn Millionen, hundert Millionen, eine Milliarde? Das sind sehr unterschiedliche Architekturen. Sagen Sie mir nicht, dass die Integration häufig läuft: jede Stunde, jede Minute, tausendmal pro Sekunde? Sagen Sie mir nicht, dass wir schnell wachsen. Wie schnell?

Wenn ich keine bessere Zahl habe, ist mein Ausgangswert 30 Prozent jährliches Wachstum. Das ist keine Vorhersage; es ist ein Zwangsmittel. Wenn mir jemand sagt, wir haben heute 10 Millionen Datensätze, soll die Diskussion nicht bei 10 Millionen stehen bleiben. Bei 30 Prozent pro Jahr sind wir nächstes Jahr bei rund 13 Millionen, im Jahr darauf bei 17 Millionen und ein Jahr später bei etwa 22 Millionen. Jetzt reden wir über den Entwurf. Wenn mir das Geschäft sagt, 30 Prozent sind lächerlich, wunderbar: Nennen Sie mir die echte Zahl. Es geht darum, Wachstum zum Teil der Architekturdiskussion zu machen.

Ich nenne das Steves Anzahl der Nullen (Steve’s Number of Zeros). Eine zusätzliche Null kann Ihre Architektur völlig verändern. Zehntausend, hunderttausend, eine Million, zehn Millionen, hundert Millionen: Die Funktion hat sich nicht geändert, die Anforderung vielleicht auch nicht, aber die Architektur möglicherweise schon.

Erinnern Sie sich an die Termine aus Modul 1? Legen wir die echten Zahlen darauf. Über 1’200 Standorte, 100 Termine pro Standort und Tag, sechs Tage die Woche, etwa 305 Tage im Jahr. Das sind im ersten Jahr über 36 Millionen Termine. Jeder Besuch erzeugt zwei Datensätze, also über 73 Millionen Datensätze. Bewahren Sie jetzt fünf Jahre Historie auf, bei 30 Prozent Wachstum pro Jahr, und es sind über 650 Millionen Datensätze. Dieselbe Funktion, dieselbe Anforderung. Ein paar Nullen mehr, und eine ganz andere Architektur.

Für morgen planen

Wenn ich das Heute verstanden habe, schaue ich nach vorn: Was wird sich vernünftigerweise wahrscheinlich ändern? Das Volumen gehört dazu, aber morgen heisst nicht nur mehr. Es kann auch anders heissen: mehr Produkte, Geschäftsbereiche und Länder; andere Datenschutzanforderungen; neue Kanäle und Integrationen; eine Fusion oder Übernahme; eine neue Stammdatenstrategie oder Analyseplattform; ein KI-Agent, der Informationen nutzt, die nur für Menschen gedacht waren.

Deshalb ist mir so wichtig, ob die Architektur durch Hinzufügen statt durch ständiges Verändern wachsen kann. Wenn das Geschäft ein Produkt hinzufügt, kann das Modell es aufnehmen? Wenn ein anderes System die Daten braucht, können wir sie sauber bereitstellen? Wenn das Volumen sprunghaft steigt, haben wir Spielraum? Wenn sich die Geschäftsstruktur ändert, müssen wir das Datenmodell auseinandernehmen? Wir versuchen nicht, die Zukunft perfekt vorherzusagen. Wir versuchen, uns nicht selbst in eine Ecke zu manövrieren.

Bauen Sie das Morgen nicht heute

Hier braucht es Balance. Für morgen zu planen heisst nicht, das System von morgen heute zu bauen. Wenn wir 100’000 Datensätze haben und in fünf Jahren vielleicht 100 Millionen, heisst das nicht, dass wir jetzt die Architektur für 100 Millionen Datensätze bauen. Sie bringt vielleicht Kosten und Komplexität mit sich, die wir noch nicht brauchen.

Die Frage, die ich beantwortet haben möchte, lautet: Kann sich die Architektur von heute zur Architektur von morgen weiterentwickeln? Wenn wir einfach beginnen können und einen klaren Weg nach vorn haben, ist das oft besser, als die Kosten der Komplexität Jahre zu früh zu zahlen. Die Gefahr ist nicht, klein anzufangen. Die Gefahr ist, an einem Punkt anzufangen, von dem aus es nicht weitergeht.

Für das Scheitern planen

Jetzt der Teil, über den niemand gern spricht: Dinge fallen aus. Ich habe noch nie ein System entworfen, in dem jede Komponente für immer verfügbar blieb, jede Integration erfolgreich war, jeder Benutzer perfekte Daten eingab und jedes externe System sich genau wie dokumentiert verhielt. Entwerfen Sie also nicht dieses System.

Fragen Sie, was ausfallen kann, und dann, was passiert, wenn es ausfällt. Eine Integration läuft in eine Zeitüberschreitung. Eine API lehnt eine Anfrage ab. Ein nächtlicher Ladelauf verarbeitet 800’000 Datensätze und scheitert bei 200’000. Ein Quellsystem fällt aus. Ein Benutzer gibt ungültige Daten ein. Eine externe Kennung taucht doppelt auf. Ein vorgelagertes System ändert das Format eines Werts, ohne den Feldnamen zu ändern. Ein Prozess gelingt in einem System und scheitert in einem anderen. Das sind keine ungewöhnlichen Randfälle. So sieht Produktion aus.

Teilerfolg ist immer noch ein Scheitern, das Sie verstehen müssen

Teilweise Fehlschläge sind in der Datenarchitektur besonders gefährlich. Stellen Sie sich vor, Sie verschieben eine Million Datensätze, und der Prozess meldet, dass er abgeschlossen ist. Wunderbar. Aber sind eine Million angekommen oder 999’997, und welche drei fehlen? Vielleicht sind 200’000 gescheitert, einige wurden doppelt angelegt, oder alles ist angekommen und bei einigen Feldern ist die Transformation fehlgeschlagen.

«Job abgeschlossen» ist nicht dasselbe wie die Daten sind korrekt. Datenarchitekt:innen denken an den Abgleich: Woher wissen wir, was hätte passieren sollen, was tatsächlich passiert ist und worin der Unterschied besteht? Und was tun wir dagegen?

So gehe ich vor, wenn die Systeme komplex werden. Datensätze gehen von A nach B, von links nach rechts. Dann schickt B etwas zurück: eine Bestätigung für jeden Datensatz, den es empfangen und gespeichert hat. Jetzt kann A vergleichen, was es gesendet hat, mit dem, was bestätigt wurde. Hat jeder Datensatz seine Bestätigung, war der Lauf erfolgreich. Fehlen Bestätigungen, war er es nicht, ganz gleich, was der Jobstatus sagt, und wir wissen genau, um welche Datensätze wir uns kümmern müssen: erneut versuchen, an eine Person weiterleiten oder einen Alarm auslösen.

Click to enlarge

Kontrolliert scheitern

Wenn etwas ausfällt, möchte ich wissen, was das System als Nächstes tut: ob es einen neuen Versuch macht, automatisch oder nicht; was passiert, wenn dieselbe Transaktion zweimal verarbeitet wird; wohin fehlgeschlagene Datensätze gehen und ob gute Datensätze an einem schlechten vorbei weiterfliessen; wer alarmiert wird, mit welchen Informationen, und wie diese Person den Fehler erneut abspielt; und wie ein Benutzer erfährt, dass etwas schiefgegangen ist.

Und vor allem: Können wir uns erholen, ohne das Problem zu verschlimmern? Eine Wiederholungsstrategie, die doppelte Daten erzeugt, ist keine gute Wiederherstellungsstrategie. Gute Architektur rechnet mit dem Scheitern und gibt uns einen Weg zurück.

Überwachen Sie, was zählt

Für das Scheitern zu planen, ohne zu überwachen, ist keine echte Planung. Wenn eine Integration um 2 Uhr nachts ausfällt und es niemand bemerkt, bis drei Tage später ein Kunde anruft, hatten wir keine Betriebsarchitektur. Wir hatten Hoffnung.

Entscheiden Sie, was beobachtbar sein muss: Ist der Prozess gelaufen, wie lange hat er gedauert, wie viele Datensätze wurden verarbeitet, wie viele waren erfolgreich und wie viele sind gescheitert? Weichen die Volumen plötzlich vom Normalen ab? Wächst der Rückstau, nehmen die Fehler zu? Architektur endet nicht, wenn das Deployment gelingt. Jemand muss dieses System morgen betreiben, und das gehört zum Entwurf.

Denken Sie in alle drei Richtungen

Wenden Sie die drei Blickwinkel im Rest dieses Kurses immer wieder an. Wenn wir ein Datenmodell entwerfen: Funktioniert es heute, kann es morgen wachsen, und was passiert, wenn die Daten falsch oder unvollständig sind? Eine Integration: Bewegt sie die Daten von heute, kann sie das Volumen und die Systeme von morgen bewältigen, und was passiert, wenn eine Seite ausfällt? Grosse Datenvolumen: Was haben wir heute, wohin entwickeln sich die Zahlen, und wie erholen wir uns, wenn ein grosser Vorgang nur teilweise gelingt?

Die Technologie ändert sich von Kapitel zu Kapitel. Die Fragen nicht.

Architektur existiert über die Zeit

In der Entwicklung kann man manchmal eine Anforderung betrachten und fragen: «Funktioniert das?» In der Architektur müssen wir mehr fragen: Funktioniert es heute, wird es morgen noch funktionieren, und was passiert, wenn es gar nicht funktioniert? Diese drei Fragen führen uns über die Umsetzung hinaus in das Leben des Systems.

Sie werden nicht jede künftige Anforderung vorhersagen oder jeden Ausfall verhindern. Das ist nicht das Ziel. Das Ziel ist, etwas zu bauen, das zu dem passt, was wir heute wissen, uns Spielraum für morgen zu lassen und einen Plan zu haben, wenn die Wirklichkeit nicht mitspielt.

Für heute bauen. Für morgen planen. Für das Scheitern planen. Diese drei Blickwinkel werden wir immer wieder verwenden.

Was Architekt:innen hier entscheiden

• Wie die echten Volumen und das Wachstum aussehen und welche Zahlen den Entwurf verändern würden.
• Welche stillschweigenden Anforderungen das Geschäft noch nicht genannt hat.
• Wie sich der Entwurf von heute zu dem von morgen entwickeln kann, ohne das System von morgen heute zu bauen.
• Was passiert, wenn etwas ausfällt: Wiederherstellung, Abgleich und Überwachung.