Mehrere Systeme auf einem gemeinsamen Backend

Es beginnt selten mit einer Entscheidung. Zuerst kommt der Shop, später eine Tabelle für die Einsatzplanung. Irgendwann steht dieselbe Kundenadresse an drei Stellen in drei Schreibweisen, und wer sie ändert, ändert sie an einer davon.

Bei Glanz K standen vier Anwendungen an, die von verschiedenen Leuten benutzt werden: eine Verwaltungs-App für die Disposition, ein Admin-Portal für die Steuerung im Hintergrund, ein Onlineshop und die Website. Vier Oberflächen für vier Nutzergruppen, im Kern auf einem Datenbestand, der in allen vieren derselbe sein muss.

Was getrennte Datenbestände im Betrieb kosten

• Stammdaten werden mehrfach gepflegt. Jede Adressänderung und jede Preisanpassung fällt in jedem System erneut an.
• Fachlogik wird kopiert. Rechnet der Shop einen Rabatt anders als das Portal, fällt das erst auf, wenn eine Rechnung nicht stimmt.
• Rechte und Rollen existieren viermal. Wer den Betrieb verlässt, muss in vier Systemen abgemeldet werden, und in der Praxis wird eines vergessen.
• Fehlersuche beginnt mit der Frage, welches System recht hat. Diese Frage kostet Zeit, bevor überhaupt jemand am Fehler arbeitet.
• Jede Erweiterung fällt mehrfach an. Ein neues Feld am Kunden bedeutet vier Änderungen und vier Auslieferungen.

Diese Kosten fallen nicht beim Bau an, sondern im laufenden Betrieb, verteilt über Jahre und über Leute, die nie eine Rechnung dafür schreiben. Genau deshalb werden sie beim Vergleich von Angeboten übersehen. Vier einzelne Anwendungen sehen im ersten Angebot günstiger aus.

Gebaut wurde ein Backend, das alle vier Anwendungen bedient. Datenmodell und Rechteverwaltung liegen einmal vor, die Fachregeln ebenfalls. Die Oberflächen unterscheiden sich darin, was sie zeigen und wer sie bedienen darf.

Wer welchen Zugang benutzt

• Verwaltungs-App für die Disposition: Einsätze planen und den aktuellen Stand unterwegs sehen, ohne Rückfrage im Büro.
• Admin-Portal: Stammdaten, Preise, Rollen und Auswertungen an einer Stelle.
• Onlineshop nach WCAG 2.1 AA: derselbe Artikelstamm und dieselben Preise wie im Portal.
• Website: öffentliche Seite auf denselben Inhalten, ohne zweite Pflegeoberfläche.

WCAG 2.1 AA ist im Shop eine Liste prüfbarer Punkte. Der Kaufweg lässt sich vollständig mit der Tastatur bedienen. Formularfelder haben Beschriftungen, die ein Screenreader vorliest. Fehlermeldungen benennen Feld und Fehler im Text und markieren ihn nicht nur farbig. Die Kontraste erreichen die Mindestwerte. Seit Juni 2025 verlangt das Barrierefreiheitsstärkungsgesetz Vergleichbares von Onlineshops im Verbrauchergeschäft.

Weil die Regeln im Backend liegen, gelten sie in jedem Zugang gleich. Ein Preis, der im Portal gepflegt wird, ist derselbe Preis, den die App bei der Einsatzplanung sieht und den der Shop im Warenkorb rechnet. Eine zweite Implementierung, die man nachziehen müsste, gibt es nicht.

Ein gemeinsames Backend koppelt auch die Risiken. Fällt es aus, stehen alle vier Zugänge. Ein Fehler im Datenmodell wirkt überall gleichzeitig. Das gehört zu dieser Bauweise. Mit Betriebsüberwachung und gestuftem Ausrollen lässt es sich beherrschen, verschwinden tut es nicht.

Am deutlichsten wirkt das Einfachste: Der Abgleich entfällt. Eine Adresse wird an einer Stelle geändert und ist in App, Portal, Shop und Website im selben Moment dieselbe. Ein Artikelpreis ebenso. Ein Zugang wird an einer Stelle vergeben und an derselben Stelle entzogen.

Auswertungen laufen über einen Bestand, ohne dass vorher Datensätze aus mehreren Systemen zusammengeführt werden. Und eine fünfte Oberfläche wäre Frontend-Arbeit auf vorhandener Logik, kein fünftes System mit eigener Datenhaltung.

Der Vorlauf war dafür größer. Ein Datenmodell, das vier Zugänge tragen muss, wird gründlicher entworfen als eines für einen einzigen, und dieser Aufwand fällt vor der ersten Auslieferung an. Er zahlt sich ab der zweiten Oberfläche aus, weil sie auf vorhandener Logik aufsetzt, und im Betrieb, weil Pflege und Rechtevergabe nur einmal anfallen.

Wie viel Zeit das im Tagesgeschäft spart, hängt an Dingen außerhalb der Software: daran, ob die Abläufe tatsächlich so laufen, wie sie im System abgebildet sind, und ob die Zugänge im Alltag benutzt werden. Belastbar sagen kann das nur, wer vorher gemessen hat, wie lange dieselben Schritte ohne die Systeme gedauert haben.

Der gemeinsame Kern trägt sich über die Doppelarbeit, die er abschafft. Technische Sauberkeit allein trägt ihn nicht. Diese Punkte sollten zutreffen.

• Mehrere Nutzergruppen arbeiten mit denselben Stammdaten in unterschiedlichen Ansichten.
• Zwischen den Zugängen fließen Vorgänge, die auf dieselben Kunden und Artikel zeigen.
• Die Anwendungen sollen gemeinsam weiterentwickelt und gemeinsam betrieben werden.
• Der Betrieb will seine Daten selbst halten, statt über Exporte an sie heranzukommen.

Wann diese Entscheidung falsch wäre

• Die Bereiche haben fachlich nichts miteinander zu tun. Zwei Geschäftsfelder ohne gemeinsame Kunden brauchen keinen gemeinsamen Kern.
• Ein Teil soll verkauft oder in eine eigene Gesellschaft überführt werden. Dann ist die spätere Trennung teurer als die doppelte Pflege heute.
• Ein Standardprodukt deckt einen der Bereiche weitgehend ab. Dann wird es gekauft und über eine Schnittstelle angebunden.
• Vertragliche oder rechtliche Vorgaben verlangen getrennte Datenhaltung. Das ist eine Vorgabe und keine Architekturfrage.
• Es bleibt bei einer Oberfläche. Für ein einzelnes Frontend ist ein gemeinsames Backend schlicht das Backend.

Ein Vorhaben in diesem Zuschnitt, also mehrere Oberflächen auf einem Kern mit Anbindungen nach außen, liegt in diesem Band. Wo genau, entscheiden die Zahl der Zugänge und die Tiefe der Anbindungen.

Müssen alle Anwendungen gleichzeitig gebaut werden?

Nein. Sinnvoll ist eine Reihenfolge, bei der das Backend von Anfang an mit Blick auf die späteren Zugänge entworfen wird. Gebaut und in Betrieb genommen wird nacheinander, damit der erste Zugang produktiv läuft, während der zweite entsteht.

Was passiert, wenn später ein Standardsystem dazukommt, etwa eine Buchhaltung?

Es wird angebunden. Der gemeinsame Kern macht das einfacher, weil die Schnittstelle einmal gebaut wird und alle Zugänge davon profitieren. Mehr dazu unter /individualsoftware/schnittstellen/.

Wem gehört der Code?

Dem Kunden, ab Tag eins. Quellcode und Datenmodell liegen beim Auftraggeber, der Betrieb läuft in Deutschland oder der EU.

Was kostet der Betrieb nach dem Go-live?

Betrieb und Weiterentwicklung werden getrennt vom Bau vereinbart. Der Umfang hängt daran, wie viel Änderung pro Jahr erwartet wird. Der Ablauf ist unter /ablauf-und-kosten/ beschrieben.

• App-Entwicklung für iOS und Android
• Onlineshop mit Warenwirtschaftsanbindung
• Alle Projekte