Wie Sie entscheiden, welche Prozessänderungen eine Regel, Konfiguration oder individuelle Entwicklung benötigen

Wenn sich ein digitaler Prozess verändert, wird die Diskussion häufig zu einfach geführt: „Machen wir es schnell über einen Parameter, oder muss es entwickelt werden?“ Diese Frage verdeckt eine wichtigere Designentscheidung. Jede Änderung bringt eine Geschäftsregel, eine operative Erwartung und künftige Wartungskosten mit sich. Alles mit Code zu lösen, verlangsamt die Anpassung; alles über Konfigurationsoptionen zu lösen, kann das Produkt unvorhersehbar, schwer prüfbar und fragil machen.

Die richtige Entscheidung hängt nicht allein vom anfänglichen Aufwand ab. Entscheidend sind die Stabilität der Regel, wer sie ändern muss, das damit verbundene Risiko und ob die Änderung eine neue Fähigkeit einführt. Das Ziel ist, dass sich der Prozess weiterentwickelt, ohne jede Ausnahme in eine dauerhafte Verzweigung zu verwandeln oder kritische Entscheidungen in unklaren Administrationsmasken zu verstecken.

Die drei Alternativen und ihre jeweiligen Grenzen

Dieselbe Anforderung kann als feste Regel, als Konfiguration oder als individuelle Entwicklung formuliert werden. Es handelt sich um unterschiedliche Mechanismen, deren Verantwortlichkeiten klar sein müssen.

Stabile, im Code umgesetzte Regel

Eine Regel im Code ist geeignet, wenn sie ein strukturelles Produktverhalten darstellt: verpflichtende Validierungen, Sicherheitsbeschränkungen, Berechnungen mit geringer Variabilität oder Entscheidungen, die in allen Fällen desselben Kontexts gleich sein müssen. Sie ist auch eine gute Wahl, wenn Änderungen technisches Verständnis erfordern oder ein Fehler schwerwiegende Folgen hätte.

• Vorteil: explizites Verhalten, gemeinsam mit der Software versioniert und durch automatisierte Tests abgedeckt.
• Risiko: Eine kleine operative Anpassung erfordert ein Deployment und kann eine Abhängigkeit vom technischen Team schaffen.
• Diagnosesignal: Die Regel bleibt über Monate nahezu unverändert, und es gibt nur wenige berechtigte Gründe, warum einzelne Einheiten sie ändern sollten.

Administrierbare Konfiguration

Konfiguration dient vorgesehenen Variationen eines Prozesses. Beispiele sind Genehmigungsschwellen, Empfänger von Benachrichtigungen, Betriebskalender, aktivierte Kategorien oder Schrittfolgen innerhalb eines bereits entworfenen Rahmens. Sie ist kein Mittel, um Gestaltung zu vermeiden: Sie ist eine Produktfähigkeit, die ein Datenmodell, Berechtigungen, Validierungen und eine verständliche Oberfläche benötigt.

• Vorteil: Fachbereich oder Betrieb können auf autorisierte Änderungen reagieren, ohne auf einen Entwicklungszyklus zu warten.
• Risiko: Zu viele Parameter erzeugen Kombinationen, die weder verständlich noch testbar sind.
• Diagnosesignal: Die Änderung tritt wiederkehrend und vorhersehbar auf und liegt innerhalb von Grenzen, die das System validieren kann.

Entwicklung einer neuen Fähigkeit

Eine individuelle Entwicklung ist notwendig, wenn die Anforderung das Prozessmodell verändert: Sie führt Beteiligte, Zustände, Entscheidungen, Daten, Integrationen oder Ausnahmen ein, die bislang nicht existierten. Der Versuch, dies in einen Parameter zu pressen, führt meist zu verstreuter bedingter Logik und einer Konfigurationsoberfläche, die niemand mehr steuern kann.

• Vorteil: Sie ermöglicht eine kohärente, beobachtbare und nachhaltige Lösung.
• Risiko: Einen punktuellen Bedarf als generische Plattform zu behandeln und den Umfang zu überdimensionieren.
• Diagnosesignal: Um die Änderung zu unterstützen, müssen neue Felder, Berechtigungen, Routingregeln oder Zustände hinzugefügt werden.

Die sechs Fragen zur Einordnung einer Änderung

Bevor Aufgaben geschätzt werden, sollten Produkt, Fachbereich und Technik die folgenden Fragen schriftlich beantworten. Die Antworten verringern Entscheidungen, die nur auf Dringlichkeit oder den scheinbaren Kosten der ersten Umsetzung beruhen.

1. Wie häufig ändert sich die Regel? Kann sie sich aufgrund berechtigter operativer Entscheidungen mehrmals jährlich ändern, sollte Konfiguration geprüft werden. Ist sie eine Ausnahme und wird sich nicht wiederholen, kann eine explizite Regel oder eine temporäre Lösung mit einem festgelegten Ablösetermin sinnvoll sein.
2. War die Variation im Design vorgesehen? Konfiguration darf nicht bedeuten, jedes beliebige Verhalten zuzulassen. Es muss eine klar abgegrenzte Auswahl an Optionen und Kompatibilitätsregeln geben.
3. Wem gehört die Entscheidung? Wenn der Betrieb sie ändern soll, benötigt er eine sichere Benutzerführung und passende Berechtigungen. Erfordert sie technische Interpretation, sollte sie im Code bleiben.
4. Welche Auswirkungen hat ein Fehler? Je höher die finanziellen, rechtlichen, sicherheitsbezogenen oder betrieblichen Auswirkungen sind, desto stärker müssen die Kontrollen sein: Validierung, Prüfung, Tests und Nachvollziehbarkeit.
5. Beeinflusst sie das Domänenmodell? Wenn eine neue Entität, ein neuer Zustand, eine neue Rolle oder Beziehung entsteht, geht es nicht nur um Konfiguration; wahrscheinlich muss eine Fähigkeit entworfen werden.
6. Wie wird sie geprüft und zurückgesetzt? Wenn sich die Auswirkung nicht vorab anzeigen, die Änderung nicht protokollieren und nicht rückgängig machen lässt, ist die Konfiguration noch nicht bereit für die Administration.

Eine gesunde Konfiguration begrenzt Entscheidungen innerhalb eines Designs; sie überträgt den Nutzenden nicht die Verantwortung, das System zu entwerfen.

Wann Code, Konfiguration oder Entwicklung sinnvoll sind

Eine stabile Regel im Code ist vorzuziehen, wenn eine Anforderung keine Variationen je Einheit zulässt, eine wesentliche Bedingung schützt oder ihre Gültigkeit von komplexer Logik abhängt. Ein Beispiel ist das Verhindern, dass ein Antrag ohne die erforderlichen Mindestdaten in die Genehmigung gelangt. Diese Bedingung in ein editierbares Kontrollkästchen zu verwandeln, kann die Prozessqualität beeinträchtigen.

Konfiguration eignet sich für operative Entscheidungen, die sich innerhalb eines bekannten Rahmens verändern. Ein Genehmigungsworkflow kann beispielsweise erlauben, den Betrag festzulegen, ab dem eine zweite Prüfung erforderlich ist, sofern das System den Wert validiert, die Verantwortlichen identifiziert und verhindert, dass der Workflow ohne Genehmigende bleibt. Das Produkt bietet in diesem Fall keine vollständige Freiheit, sondern kontrollierte Variabilität.

Eine individuelle Entwicklung sollte beginnen, wenn die Änderung die Natur des Ablaufs verändert. Benötigt eine Organisation parallele Genehmigungen, zeitlich begrenzte Vertretungen, Regeln nach Attributen mehrerer Entitäten und eine Eskalation bei Fristablauf, hat sie wahrscheinlich eine einfache Schwellenwertkonfiguration überschritten. Dann ist es sinnvoll, eine Routing- und Entscheidungsfähigkeit zu entwerfen, auch wenn sie schrittweise umgesetzt wird.

Risiken, die auf eine schlechte Entscheidung hinweisen

Übermäßige Parametrisierung ist das häufigste Risiko. Sie ist oft daran zu erkennen, dass die Oberfläche technische Bezeichnungen, widersprüchliche Optionen, implizite Abhängigkeiten und Werte enthält, die niemand anzufassen wagt. Das Team braucht am Ende einen Entwickler, um eine Konfiguration zu interpretieren, die theoretisch vom Fachbereich verwaltet werden sollte.

Das gegenteilige Problem sind unsichtbare Ausnahmen im Code. Sie entstehen, wenn jeder Kunde, Bereich oder Sonderfall eine isolierte Bedingung hinzufügt. Mit der Zeit führen zwei Regeln für scheinbar gleichartige Situationen zu unterschiedlichen Ergebnissen, und niemand kann erklären, welche Regel Vorrang hat. Ein klares Signal ist, dass Vorfälle durch die Frage „Welche Bedingung greift zuerst?“ gelöst werden, statt eine verständliche Richtlinie nachzuschlagen.

Auch doppelte Logik birgt Risiken. Ein Schwellenwert, der in einer Administrationsoberfläche definiert, in einem Integrationsdienst wiederholt und in einem Bericht erneut interpretiert wird, führt zu Abweichungen. Um dies zu vermeiden, sollte jede Entscheidung eine Quelle der Wahrheit, einen Verantwortlichen und einen bekannten Ort für ihre Auswertung haben.

Eine sichere und steuerbare Konfiguration gestalten

Eine administrierbare Konfiguration muss als Teil des Produkts behandelt werden, nicht als editierbare Tabelle. Definieren Sie zuerst, welche Variationen gültig sind und welche nicht. Ergänzen Sie anschließend Kontrollen, die den Auswirkungen angemessen sind.

• Rollenbasierte Berechtigungen: Trennen Sie, wer Änderungen ansehen, vorschlagen, genehmigen und veröffentlichen darf.
• Geschäftsvalidierungen: Verhindern Sie ungültige Kombinationen vor dem Speichern, nicht erst, wenn der Prozess bereits fehlgeschlagen ist.
• Prüfbare Historie: Erfassen Sie, was geändert wurde, wer die Änderung vorgenommen hat, wann sie erfolgte und welcher Wert zuvor galt.
• Expliziter Geltungsbereich: Machen Sie klar, ob die Regel für die gesamte Organisation, eine Einheit, einen Antragstyp oder einen Zeitraum gilt.
• Szenariotests: Ermöglichen Sie, repräsentative Fälle zu prüfen, bevor eine Änderung mit hoher Auswirkung aktiviert wird.
• Rücksetzung: Bieten Sie eine kontrollierte Möglichkeit, zu einer früheren Version zurückzukehren, ohne mehrere Werte manuell bearbeiten zu müssen.

Die OWASP-Empfehlungen zu Autorisierung und Eingabevalidierung sind besonders relevant, wenn nichttechnische Nutzende Regeln verwalten, die Berechtigungen, Beträge oder Entscheidungswege beeinflussen. Die Oberfläche sollte die Auswirkung jeder Änderung erklären, ohne unnötige technische Details offenzulegen.

Beispiel: die Weiterentwicklung eines Genehmigungsworkflows

Stellen Sie sich einen Workflow vor, in dem jeder Antrag oberhalb eines festgelegten Betrags die Genehmigung einer verantwortlichen Person benötigt. Die Pflicht zur Angabe eines Betrags und das Verbot, den eigenen Antrag zu genehmigen, sind stabile Regeln: Sie sollten im Code bleiben und durch Tests abgedeckt sein.

Der Schwellenbetrag und die verantwortliche Person können konfigurierbar sein, wenn sie sich je operativer Einheit ändern und das System validiert, dass stets eine aktive verantwortliche Person vorhanden ist. Die Historie sollte zeigen, welcher Schwellenwert beim Start jedes Antrags galt, damit eine spätere Änderung den Kontext einer bereits getroffenen Entscheidung nicht überschreibt.

Wenn später gefordert wird, dass zwei Bereiche parallel genehmigen, die Verantwortung von Kategorie und Region abhängt und während Abwesenheiten eine Vertretung möglich ist, sollte das Team innehalten. Es ist dann nicht mehr sinnvoll, der bestehenden Konfiguration weitere Kontrollkästchen hinzuzufügen. Jetzt ist der Zeitpunkt, eine Fähigkeit für Routingregeln mit eigenen Prioritäten, Konflikten, Zuständen und Beobachtbarkeit zu definieren.

Eine nachhaltige Entscheidung besteht nicht darin, immer die schnellste Alternative zu wählen. Sie besteht darin, den Mechanismus zu wählen, der die Klarheit des Prozesses heute bewahrt und seine Weiterentwicklung morgen ermöglicht. Verwenden Sie Code für Invarianten, Konfiguration für vorgesehene Variationen und Entwicklung für Modelländerungen.