Am Anfang steht ein Entwurf der Oberfläche, weil man den zeigen kann. Er sieht gut aus, alle nicken, und die Datenstruktur ergibt sich dann eben aus den Feldern, die darauf zu sehen sind. Genau an dieser Stelle entsteht der Fehler, der später am teuersten ist.
Die Datenstruktur ist die einzige Entscheidung in einem Projekt, die sich später nur mit Migration korrigieren lässt. Eine Oberfläche baut man in Tagen um. Eine falsch gedachte Datenstruktur zieht Migration, Anpassung aller Auswertungen und Nacharbeit an jeder Schnittstelle nach sich, und zwar rückwirkend für alle bereits erfassten Vorgänge.
Ein Beispiel, das häufig vorkommt
Ein Betrieb erfasst Aufträge. Zu jedem Auftrag gehört ein Ansprechpartner, also bekommt der Auftrag ein Feld „Ansprechpartner“ mit Name und Telefonnummer. Das ist naheliegend, es passt zum Formular, und es funktioniert zwei Jahre lang.
Dann kommen die Anforderungen, die niemand vorhergesehen hat:
- Ein Kunde hat zwei Ansprechpartner, einen für Technik und einen für Rechnungen.
- Ein Ansprechpartner wechselt die Nummer. In dreihundert alten Aufträgen steht die alte.
- Jemand fragt, welche Aufträge Herr Meier betreut hat. Das lässt sich nur über Textsuche beantworten, und die findet „Meier“, „meier“ und „Hr. Meier“ nicht gemeinsam.
- Ein Ansprechpartner verlässt den Betrieb und darf laut Löschkonzept entfernt werden. Sein Name steht in dreihundert Auftragsdatensätzen.
Der Fehler war nicht das Formular. Der Fehler war die Annahme, dass ein Ansprechpartner eine Eigenschaft des Auftrags ist. Er ist ein eigenständiger Gegenstand, auf den ein Auftrag verweist.
Die vier Fragen vor jedem Datenfeld
Man muss dafür kein Fachmann sein. Vier Fragen fangen den größten Teil der späteren Probleme ab:
- Kann es davon mehr als eines geben? Wenn ja, ist es keine Eigenschaft, sondern eine eigene Liste. Ein Auftrag mit „dem“ Ansprechpartner, „der“ Adresse oder „dem“ Termin ist fast immer zu eng gedacht.
- Existiert es auch ohne diesen Vorgang? Ein Kunde existiert unabhängig vom Auftrag. Eine Positionsnummer nicht. Was eigenständig existiert, gehört in eine eigene Struktur.
- Ändert es sich mit der Zeit, und ist die Änderung rückwirkend? Eine Telefonnummer ändert sich und soll überall aktuell sein. Ein Preis ändert sich und darf gerade nicht rückwirkend gelten, sonst ändern sich alte Rechnungen. Diese beiden Fälle brauchen unterschiedliche Behandlung.
- Wird jemand danach auswerten wollen? Alles, wonach jemals gefiltert, gruppiert oder gezählt wird, gehört in ein eigenes Feld mit festen Werten. Freitext ist bequem und in der Auswertung wertlos.
Freitext ist der häufigste Fehler
Ein Bemerkungsfeld ist sinnvoll und sollte es geben. Gefährlich wird es, wenn Informationen darin landen, die eigentlich Struktur brauchen: „dringend“, „Termin verschoben auf KW 12″, „Zahlung vereinbart“.
Diese Angaben sind wichtig, sonst würde sie niemand hineinschreiben. Sie sind aber unauswertbar, uneinheitlich und nicht prüfbar. Wenn dasselbe Wort dreimal im Bemerkungsfeld auftaucht, ist das der Hinweis auf ein fehlendes Feld.
Wann die Reihenfolge doch andersherum sinnvoll ist
Damit es nicht zu streng klingt: Es gibt einen Fall, in dem die Oberfläche zuerst entsteht, und der ist völlig legitim. Wenn noch niemand weiß, wie der Ablauf am Ende aussehen soll, ist ein wegwerfbarer Entwurf der schnellste Weg zur Klarheit. Man zeigt ihn den Leuten, die damit arbeiten sollen, und lernt in einer Stunde mehr als in drei Besprechungen.
Entscheidend ist nur das Wort wegwerfbar. Der Entwurf dient dazu, die Felder zu finden. Danach wird die Datenstruktur bewusst entworfen, und dann erst wird gebaut.
Was das für dich als Auftraggeber bedeutet
Du musst kein Datenmodell entwerfen können. Du solltest aber merken, wenn keines existiert. Ein einfacher Test: Bitte um eine Skizze, welche Gegenstände es im System gibt und wie sie zusammenhängen. Kunden, Aufträge, Positionen, Termine, Dokumente. Wer diese Skizze in zehn Minuten an ein Whiteboard bringt, hat darüber nachgedacht. Wer sofort wieder Bildschirme zeigt, hat es übersprungen.
Wie wir das angehen
Wir zeichnen die Gegenstände und ihre Beziehungen auf, bevor eine Zeile Oberfläche entsteht, und wir gehen sie mit den Leuten durch, die später damit arbeiten. Das dauert einen halben Tag und ist die Investition mit dem besten Verhältnis im ganzen Projekt. Mehr dazu unter Individualsoftware für interne Abläufe.
Was ist ein Datenmodell?
Die Festlegung, welche Gegenstände ein System kennt, welche Eigenschaften sie haben und wie sie zusammenhängen. Es entscheidet, was sich später auswerten, ändern und erweitern lässt.
Warum ist die Datenstruktur später schwer zu ändern?
Weil bereits erfasste Daten mitwandern müssen. Eine Änderung zieht Migration, Anpassung aller Auswertungen und Nacharbeit an jeder Schnittstelle nach sich, rückwirkend für alle Vorgänge.
Wann sind Freitextfelder problematisch?
Sobald darin Informationen landen, nach denen später gefiltert oder ausgewertet werden soll. Wenn dasselbe Wort wiederholt im Bemerkungsfeld auftaucht, fehlt an dieser Stelle ein eigenes Feld.
Muss der Kunde das Datenmodell verstehen?
Nicht im Detail, aber er sollte es sehen. Eine Skizze der Gegenstände und ihrer Beziehungen zeigt, ob darüber nachgedacht wurde. Wer sofort Bildschirmentwürfe zeigt, hat diesen Schritt übersprungen.
Passend dazu
