Für jede Datenart genau ein Ort
Der Satz, aus dem der halbe Kurs folgt — und der Grund, warum in den meisten Häusern niemand sagen kann, welcher Stand eigentlich gilt.
Das klingt selbstverständlich und ist es im Alltag fast nie. Eine gewachsene Anwendung hat die Kundenadresse in der Datenbank, eine ältere Fassung davon in der Tabelle, mit der die Rechnungen geschrieben werden, und eine dritte im Postfach der Kollegin, die den Änderungswunsch bekommen hat. Drei Stände, keiner falsch, keiner vollständig — und niemand kann sagen, welcher gilt.
Der Kurs beginnt deshalb nicht mit einer Technik, sondern mit einer Liste. Sie ist in einer halben Stunde geschrieben und wird bis Station 10 vier Spalten breiter.
| Datenart | Wo liegt sie | Welcher Stand gilt |
|---|---|---|
| Kundenstamm | Postgres, Tabelle kunde | die Datenbank |
| Rechnungsanhänge | Objektspeicher | die Datei dort — die Datenbank hält nur den Verweis |
| Angemeldete Sitzungen | Redis | flüchtig, darf jederzeit verloren gehen |
| Zuletzt gewählter Filter | Browser des Nutzers | gehört ihm, nicht uns |
| Der Suchindex | abgeleitet aus der Datenbank | nie eigenständig — er wird neu gebaut |
WarumWas passiert, wenn zwei Orte gleichzeitig recht behalten wollen
Die Regel „ein Ort je Datenart" klingt nach einer technischen Vorgabe. Sie ist in Wahrheit eine fachliche — und deshalb lässt sie sich nicht mit Technik lösen, wenn sie einmal verletzt ist.
Der typische Verlauf. Die Kundenadresse steht im ERP. Die neue Anwendung braucht sie und holt sie sich nachts. Irgendwann fragt jemand: „Kann ich die Adresse nicht gleich hier ändern? Ich sitze doch schon drin." Die Änderung ist eine Zeile Code, und ab diesem Tag gibt es zwei Orte, an denen geschrieben wird.
Warum das nicht durch Abgleich zu heilen ist. Ein Abgleich braucht eine Regel, welcher Stand gewinnt. „Der neuere" scheitert daran, dass beide Systeme unterschiedliche Zeitstempel führen und eine nächtliche Übernahme immer neuer aussieht als die Handänderung vom Vormittag. „Das ERP gewinnt" macht die Änderung in der Anwendung wirkungslos — der Nutzer sieht sie einen Tag lang und dann nicht mehr, was schlimmer ist als eine Fehlermeldung. „Feldweise das Neuere" führt zu Datensätzen, die es so nie gegeben hat: die alte Straße mit der neuen Hausnummer.
Die einzige haltbare Auflösung ist eine fachliche Entscheidung: Für jedes Feld — nicht für jeden Datensatz — wird festgelegt, wo es entsteht. Die Rechnungsadresse gehört dem ERP; der Ansprechpartner für dieses eine Vorhaben gehört der Anwendung. Beides steht nebeneinander im selben Bildschirm, und der Nutzer sieht, welches Feld er hier ändern kann und welches nicht.
Woran man merkt, dass es schiefgegangen ist: Niemand traut mehr einer der beiden Listen, und es entsteht eine dritte — meist eine Tabelle bei der Person, die am häufigsten gefragt wird. Diese dritte Liste ist das eigentliche Symptom, und sie taucht in keiner Systemlandschaft auf.