Jede Information an einem festen Ort: So wird deine App verlässlich

Wer eine neue App abnimmt, prüft meist, ob sie das Richtige anzeigt. Seltener prüft jemand, ob die Änderung auch dort ankommt, wo danach gearbeitet wird. Ein Beispiel aus dem Baustoffhandel: Ein Polier ändert in der Bestell-App die Lieferadresse für zwölf Paletten Pflastersteine, und die App meldet „Gespeichert“. Die Tour für den Fahrer plant aber die Warenwirtschaft, und dort steht noch die alte Baustelle. Der LKW fährt hin und kommt voll beladen zurück.

Die App funktioniert. Sie sieht gut aus, die Kunden bestellen gern darüber. Was ihr fehlt, zeigt kein Bildschirm: eine Architektur, die festlegt, wo eine Lieferadresse gilt. Um genau diesen Unterschied geht es hier.

Mit Enterprise-Architektur meinen wir dabei nicht die Abteilung, die im Konzern die gesamte IT-Landschaft plant. Gemeint ist Software, die nach Konzern-Standards gebaut ist: Jede Information hat einen festen Ort, Systeme reden über klare Schnittstellen, und automatische Tests sichern jede Änderung ab.

Was die Demo zeigt und was sie verschweigt

Softwarearchitektur legt die Grundstruktur eines Systems fest: wie es sicher und schnell bleibt und wie es mit neuen Anforderungen mitwächst. Das Design regelt, wie die einzelnen Teile darin funktionieren. Imaginary Cloud fasst es so zusammen: Architektur ist das Fundament, Design verfeinert die Funktionsweise im Inneren.

In einer Demo siehst du weder das eine noch das andere, sondern nur die Oberfläche: Masken, Listen, einen Button „Lieferadresse ändern“. Ob die Adresse danach in der App liegt, in der Warenwirtschaft oder in beiden, sieht man dem Button nicht an. Auf dem Bildschirm sieht eine Kopie genauso aus wie das Original.

Die eigentlichen Fragen beantwortet deshalb keine Folie:

• Wo gilt die Lieferadresse, welches System hat also das letzte Wort?
• Wer darf sie ändern?
• Wie kommen Tourenplanung, Buchhaltung und Außendienst an dieselbe Adresse?
• Woran merkt jemand, dass ein Update den Abgleich kaputt gemacht hat?

Eine Adresse, zwei Wahrheiten

So eine Lage entsteht selten aus Schlamperei. Die Bestell-App sollte schnell live gehen. Die Anbindung an die Warenwirtschaft war aufwendig, also bekam die App eigene Kundendaten. Nachts schiebt ein Export die Aufträge rüber. An Adressänderungen hat beim ersten Bildschirm niemand gedacht.

Ein Jahr später kommen neue Wünsche: Liefertermine verschieben, Rechnungen in der App anzeigen, Preise je Kunde. Jeder Wunsch bringt eine weitere Kopie und einen weiteren Abgleich. Abweichungen telefoniert der Innendienst hinterher.

Eine Architektur dreht die Reihenfolge um. Erst wird für jede Information geklärt, wo sie gilt. Dann kommt die Oberfläche, als eine von mehreren Sichten auf dieselben Daten:

flowchart LR
  subgraph vorher ["Vorher: zwei Wahrheiten"]
    direction TB
    A1["Bestell-App<br/>Lieferadresse: Baustelle B (neu)"]
    W1["Warenwirtschaft<br/>Lieferadresse: Baustelle A (alt)"]
    T1["Tourenplanung"]
    A1 -- "nachts nur Aufträge" --> W1
    W1 -- "Adresse für die Tour" --> T1
  end
  subgraph nachher ["Nachher: eine Wahrheit"]
    direction TB
    A2["Bestell-App<br/>speichert keine eigene Adresse"]
    W2["Warenwirtschaft<br/>Lieferadresse: Baustelle B"]
    T2["Tourenplanung"]
    A2 -- "liest und ändert über Schnittstelle" --> W2
    W2 -- "Adresse für die Tour" --> T2
  end

Jede Information braucht genau einen Ort, an dem sie gilt. Alle anderen Systeme fragen dort nach, statt sie zu kopieren.

Die Oberfläche lässt sich später austauschen. Eine wackelige Datenbasis zieht sich durch jede Funktion, die darauf aufbaut.

Wie aus der schnellen App eine teure wird

Ein Artikel auf martinfowler.com beschreibt ein Muster, das bei wachsenden Firmen oft auftaucht: Eine erste Version wird nicht durch eine saubere Architektur ersetzt, sondern einfach weiter ausgebaut. So lange, bis die Qualität die Entwicklung lähmt. Die Folgen sind brüchiger Code, fehlende Tests, veraltete Frameworks und fehlende Dokumentation.

Abkürzungen am Anfang sind normal, schreibt Workfall. Bleiben sie ungesteuert, wird ein System instabil, sobald es wächst, und das Team verbringt mehr Zeit mit Brandbekämpfung als mit neuen Funktionen. Dafür gibt es einen Namen, technische Schulden, und es gibt Zahlen dazu:

• Entwickler verbringen etwa 23 bis 25 Prozent ihrer Arbeitswoche mit technischen Schulden, grob einen Tag pro Woche (Agility at Scale).
• Schätzungen zufolge gehen 21 bis 40 Prozent der IT-Ausgaben eines Unternehmens auf technische Schulden zurück (Software Improvement Group).

Für dich heißt das: Auf jede neue Funktion kommt ein Aufschlag, der in keinem Angebot steht. Bei der Bestell-App steckt er in jedem neuen Abgleich und in jedem Anruf des Innendiensts.

Konzern-Standards im Mittelstandsmaß

Die Komplexität eines Konzerns brauchst du nicht. Weabers beschreibt den Unterschied so: Kleinere Unternehmen fassen Abläufe zusammen, um schnell zu sein. Konzerne zerlegen sie in Module, um Kontrolle und Compliance zu sichern. Die Architektur spiegelt dabei jeweils die Organisation wider. Arvato Systems schreibt über die Steuerung der gesamten IT-Landschaft: Der entscheidende Unterschied zwischen Mittelstand und Konzern liegt im pragmatischen Ansatz.

Pragmatisch heißt aber nicht ohne Plan. Auch kleinere Projekte brauchen eine Architekturplanung, damit keine technischen Schulden entstehen und die Software wartbar bleibt (Imaginary Cloud). Diese Standards aus Konzernprojekten lohnen sich auch bei 150 Leuten:

• Datenhoheit: Für jede Information ist festgelegt, welches System das letzte Wort hat.
• Schnittstellen statt Exporte: Die App liest und ändert Daten dort, wo sie gelten.
• Automatische Tests, die bei jeder Änderung mitlaufen, auch für die Schnittstelle zur Warenwirtschaft.
• Dokumentation, die mit dem Code mitwächst.
• Feste Zeit zum Aufräumen. Zühlke etwa nutzt rund 10 Prozent seiner Entwicklungszyklen gezielt, um technische Schulden abzubauen (IBM).

Gremien und Freigabeschleifen gehören für uns nicht dazu. Ob die Lieferadresse in der Warenwirtschaft gilt, klärt ein Gespräch mit dem Innendienst, dafür braucht es kein monatelanges Konzept.

Wie wir das bei Mavaris angehen

Bei einer Bestell-App wie der oben fangen wir nicht mit dem ersten Bildschirm an. Zuerst setzen wir uns mit Innendienst und Disposition zusammen und klären, welches System bei Kundendaten, Preisen und Lieferadressen das letzte Wort hat. Daraus folgt, was die App selbst speichern darf und was sie nur über die Schnittstelle liest und ändert.

Für diese Schnittstelle schreiben wir automatische Tests, die bei jeder Änderung mitlaufen. Bricht ein Update später den Abgleich, fällt das in der Pipeline auf und nicht erst beim Fahrer an der falschen Baustelle.

In unseren eigenen Produkten machen wir es genauso. Wenn dort zwei Wahrheiten entstehen, landen die Rückfragen bei uns selbst.

Selbst nachsehen: Wo landet eine geänderte Adresse?

Ob deine App eine Wahrheit hat oder mehrere, findest du ohne Gutachten heraus. Nimm einen Testkunden und änder in der App seine Lieferadresse. Dann schau nach, wo die neue Adresse ankommt: im Tourenplan, auf dem Lieferschein, auf der Rechnung. Und wann: sofort oder erst nach dem nächtlichen Export.

Jede Stelle, an der danach noch die alte Adresse steht, ist eine Kopie, die jemand von Hand abgleichen muss. Schreib diese Stellen auf. Wie lang die Liste wird, zeigt dir, wie viel heute am Telefon und am Gedächtnis deines Innendiensts hängt.