Anwendungen scheitern selten am ersten Tag. Sie scheitern in Jahr vier, wenn die Fachabteilung eine Kleinigkeit geändert haben will und niemand mehr sagen kann, was das kostet. Der Grund ist fast nie die Technik, sondern dass Entscheidungen im Quelltext verschwunden sind.
Eine Entscheidung gehört an eine Stelle
Nehmen Sie eine Aufbewahrungsfrist. Vorgänge einer bestimmten Art sollen nach drei Jahren aus dem aktiven Bestand verschwinden und nach zehn Jahren gelöscht werden. Eine fachliche Entscheidung, die sich ändern kann, weil ein Prüfer, ein Betriebsrat oder ein Gesetz es verlangt.
Programmiert man sie, steht sie als Zahl irgendwo im Quelltext, oft an mehreren Stellen, weil das Löschen woanders passiert als das Archivieren. Eine Änderung heißt dann: suchen, ändern, prüfen, ausliefern, und niemand sagt Ihnen vorher, wie lange das dauert. Konfiguriert man sie, ist sie eine Bedingung an einem Datensatz: eingetragen, beim nächsten Lauf wirksam, mit sichtbarem Autor und Datum.
Das klingt nach Bequemlichkeit für den Anfang. Der Anfang ist aber der billige Teil, und der Unterschied wirkt kumulativ: Jede Entscheidung, die im Code verschwindet, verteuert die nächste Änderung.
Dieselbe Anwendung, einmal geschrieben und einmal konfiguriert
Unterschiede, die im ersten Jahr niemand bemerkt und die danach jedes Jahr kosten.
Handgeschrieben
Konfiguriert
8-fach
mehr duplizierte Codeblöcke
GitClear 2025 · 211 Millionen Codezeilen
25 % → <10 %
Anteil überarbeiteten statt neu geschriebenen Codes
GitClear 2025 · derselbe Datensatz
Warum handgeschriebener Code anders altert
Dass handgeschriebener Code einzeln altert, wird beim Einkauf regelmäßig unterschätzt. Anmeldung, Rechteprüfung, Datenzugriff und Validierung kommen aus dem gemeinsamen Unterbau; ein Sicherheitsupdate dort erreicht jede Anwendung, die darauf beruht. Was von Hand geschrieben wurde, muss jemand von Hand nachziehen, solange das Projekt jemanden hat.
Die Handschrift ist der unauffälligste Unterschied und der teuerste. Zwei Entwickler lösen dieselbe Aufgabe auf zwei Arten, beide richtig, aber anders benannt, anders aufgebaut, anders in der Fehlerbehandlung. Wartbarkeit entsteht jedoch aus Wiedererkennbarkeit: Die zweite Maske pflegt nur, wer die erste kennt, und dafür müssen beide gleich gebaut sein.
Das misst GitClear. Mit Assistenzsystemen beschleunigt sich der Effekt, weil ein Sprachmodell bei derselben Anforderung zweimal etwas anderes liefert. Ausführlich steht das unter Kann KI eine App programmieren?
Was in unseren Anwendungen konfiguriert wird
Das Prinzip ist so viel wert wie die Liste dessen, was tatsächlich darunter fällt. Bei uns ist das der Großteil einer Fachanwendung: Datenmodell und Prüfregeln, Formulare, Listen, Menüs, Rechte, Protokollierung, Aufbewahrung, Sprachen, Erscheinungsbild, Datenflüsse.
Zwei Ebenen sind zu unterscheiden. Die Einrichtung, die beim Start feststeht, also Datenbank, Verzeichnisdienst und Nachbaranwendungen, wird zentral verwaltet und beim Hochfahren gegen eine Beschreibung geprüft; sie fällt beim Start auf, nicht im Betrieb. Daneben stehen Werte, die sich im laufenden Betrieb ändern dürfen: Grenzwerte, Fristen, ein Wartungsmodus, der Anmeldungen vorübergehend auf Administratoren beschränkt.
Entität, Feld, Typ, Pflichtangabe, Wertebereich, Einheit: Oberfläche und Server lesen dieselbe Beschreibung. So wird modelliert.
Wer welchen Vorgang auf welchen Daten ausführen darf, ist eine Regel mit Ebene und Bedingung. Rollen und Rechte.
Je Datenart einstellbar, welche Vorgänge und Felder mitgeschrieben werden, bis hin zum Datensatz im Stand vor der Änderung.
Archivieren und Löschen sind Bedingungen, keine Skripte. Personenbezogene Felder lassen sich nach Regel unkenntlich machen.
Beschriftungen liegen je Sprache als Einträge vor und werden auf fehlende Werte geprüft. Farben und Logos sind eine Vorlage.
Beim Abgleich mit Nachbarsystemen ist jede Feldzuordnung eine sichtbare Verbindung. Datenmigration und Schnittstellen.
Ein Unterschied, den man sehen kann
Der Modellstand liegt als Datei im selben Git-Repository wie der Quelltext. Für eine Modelländerung gilt damit dasselbe wie für eine Codeänderung: Autor, Datum, Kommentar, Vorgänger. Zwei Stände lassen sich nebeneinanderlegen.
Ebenso Rollen, Rechte und Datenflüsse: nicht in der Oberfläche zusammengeklickt, sondern als abgelegte Stände, die beim Start abgeglichen werden.
Wo Konfiguration aufhört
Eine Seite, die hier endete, wäre eine Werbeseite. Es gibt Fachlogik, die sich nicht konfigurieren lässt, und sie ist oft der Teil, für den das Unternehmen die Anwendung überhaupt will: eine Preisformel mit dreißig Sonderfällen, ein Abgleich mit einem Fremdsystem, das sich an keinen Standard hält, eine Reihenfolgeoptimierung, die ein Disponent im Kopf hat.
Dafür gibt es zwei verschiedene Wege, und sie werden gern verwechselt. Der größere ist die Entwicklungsaufgabe: eine eigene Oberfläche, eine Schnittstelle, ein Rechenverfahren. Sie wird benannt, geschätzt und programmiert wie in jedem anderen Projekt auch.
Der kleinere sind die Skriptfelder in der Konfiguration. An bestimmten Stellen lässt sich ein paar Zeilen hinterlegen, ohne das Projekt anzufassen: dort, wo eine Einstellung fast reicht, aber eben nur fast. Um diese Stellen geht es im Folgenden.
Die Stellen im Einzelnen
Ein paar Stellen, an denen das regelmäßig vorkommt. Sie sind kein abschließender Katalog, sondern zeigen, wie so ein Übergang aussieht.
Vor und nach Anlegen, Ändern, Löschen hängen Auslöser: eine Nachricht aus SOLUTIONS.email, ein Dokument aus SOLUTIONS.file, eine Rechteprüfung. Konfiguration, kein Skript.
In SOLUTIONS.transformer ist jede Feldzuordnung eine gezogene Leitung. Ein Skript nur dort, wo keine Leitung reicht: einen Namen zerlegen, einen Ausweichwert setzen.
Meist eine feste Liste oder eine Gruppe. Steht der Empfänger erst zur Sendezeit fest, liefert ihn in SOLUTIONS.email ein kurzes Skript.
Was auf dem Papier steht, aber nicht im Datensatz, wird in SOLUTIONS.file ein benannter Wert: eine Summe, eine Frist, ein formatiertes Datum.
Zählen, summieren, mitteln kann SOLUTIONS.dashboard selbst. Setzt eine Kennzahl zwei Werte ins Verhältnis, bekommt sie eine eigene Anzeige.
„Nur die eigenen Vorgänge“ ist in SOLUTIONS.user keine feste Liste. Die Regel trägt dafür einen kurzen Ausdruck und bleibt ein Eintrag, den man liest.
Wer später was pflegt
Für die Arbeit selbst gilt eine einzige Regel: Ein Skript entsteht nur dort, wo keine Einstellung dasselbe ausdrückt.
Die Zuständigkeit danach ist geteilt. Unterbau, Generator und Dienste pflegen wir; was dort besser wird, wirkt in allen Anwendungen zugleich. Konfiguration und Erweiterungen liegen in Ihrem Projekt-Repository und werden von Ihrem Team gepflegt oder von uns, wie Sie es wollen.
Was dieses Vorgehen kostet
Der erste Preis ist die Grenze des Generators. Wer von Hand im erzeugten Teil schreibt, verliert diese Änderung beim nächsten Lauf. Deshalb hat Konfiguration Vorrang, und deshalb gibt es die benannten Stellen: Was dort liegt, übersteht jeden Lauf.
Ist eine Anwendung tief von Hand ausgebaut, wird sie nicht mehr überschrieben. Der Anschluss ans Modell bleibt trotzdem: Jedes erzeugte Projekt trägt den Modellstand mit, aus dem es entstanden ist, und SOLUTIONS.designer vergleicht ihn mit dem neuen. Heraus kommt eine lesbare Liste dessen, was sich geändert hat und wo es einzubauen wäre, statt einer Fassung, die alles überschreibt.
Der zweite Preis ist das Raster. Formulare und Listen folgen einem festen Aufbau, kein freies Zeichenbrett. Eine ungewöhnliche Bedienidee ist dadurch nicht teurer als anderswo, sie wird als eigene Komponente gebaut wie in jedem Projekt; nur wird sie eben gebaut und nicht eingestellt. Was sie kostet, steht vorher im Angebot.
Der dritte Preis sind die Dienste. Einen Dienst zuzuschalten kostet nichts extra; bezahlt wird, ihn einzurichten, und seine Lizenz, solange die Anwendung ihn nutzt. Welche das sind, hängt davon ab, was Sie zuschalten; welche Bausteine mit Quellcode übergehen und welche nicht, steht unter Lizenzmodell und Quellcode.
Weiterlesen
Dass eine Anwendung beschrieben wird, statt geschrieben zu werden. Welche Dinge sie verwaltet, welche Felder die haben, wer was sehen darf, welche Nachricht wann herausgeht: All das steht als Datensatz im SOLUTIONS.designer und in den Diensten, nicht als Quelltext in einer Datei. Ein Generator macht daraus die lauffähige Anwendung; dieselbe Beschreibung ergibt dabei immer dasselbe Ergebnis.
Der Unterschied zeigt sich nicht am ersten Tag, sondern beim Ändern. Eine Aufbewahrungsfrist, die als Einstellung hinterlegt ist, ändert jemand in einer Minute und kann nachlesen, was gilt. Steht sie im Quelltext, ist sie ein Entwicklungsauftrag, und niemand weiß ohne Suche, ob sie noch an drei anderen Stellen steht.
Nein, sie verschiebt nur, wo die Arbeit anfällt. Was sich einstellen lässt, ist in Minuten geändert und von jedem nachlesbar. Was sich nicht einstellen lässt, wird programmiert wie überall sonst, nur an vorher benannten Stellen und in eigenen Dateien. Unterm Strich landen Sie bei weniger eigenem Code, nicht bei weniger Möglichkeiten.
Sie werden als eigene, benannte und geschätzte Aufgabe erfasst, beim Entwurf vermerkt und als eigene Position im Angebot ausgewiesen. Stillschweigend übergangen wird keine.
Ja, es ist ein gewöhnliches Angular-/NestJS-Projekt mit MongoDB in Ihrem Git-Repository. Eine Änderung mitten im erzeugten Teil überlebt allerdings den nächsten Generatorlauf nicht; sie gehört deshalb in die eigenen Dateien, die an den benannten Stellen einhängen. Ist eine Anwendung tief von Hand ausgebaut, wird sie nicht mehr überschrieben: Der mitgelieferte Modellstand dient dann als Vergleich, und SOLUTIONS.designer schreibt auf, was sich geändert hat und wo es einzubauen wäre.
Fließend, und die Grenze verläuft nicht an einer festen Zahl von Stellen. Die Regel dahinter ist einfach: Solange sich etwas als Einstellung, Bedingung oder Zuordnung ausdrücken lässt, wird es so gemacht. Reicht das nicht ganz, tragen viele Stellen in der Konfiguration ein Feld für ein paar Zeilen Skript, etwa ein berechneter Wert in einem Dokument oder der Empfänger einer Nachricht. Erst was auch das nicht mehr abdeckt, wird programmiert, und dann als benannte Aufgabe mit Schätzung im Angebot. Welcher Weg im Einzelfall greift, steht nach dem Entwurf fest, nicht vorher.
Weil sie einheitlich ist. Zweihundert Anwendungen prüfen Pflichtfelder auf zweihundert Arten, wenn jede es selbst tut; steht die Regel am Feld, ist es überall dieselbe. Dass geschriebener Code in die andere Richtung läuft, ist messbar: GitClear hat 2025 rund 211 Millionen Codezeilen untersucht und achtmal so viele duplizierte Blöcke gefunden wie zuvor, während der Anteil überarbeiteten Codes von 25 auf unter 10 Prozent fiel.
Sprechen Sie mit uns.