Policy-Architektur: Technische Implementierung und Konfiguration

Die Policy-Architektur fungiert als das Betriebssystem der Digitalisierung. Sie löst das Problem verstreuter Geschäftslogik, die in klassischen Systemen oft in Codezeilen, Triggern oder starren Workflow-Diagrammen (BPMN) verborgen ist. Die gesamte Steuerungs-, Prüf- und Dokumentationslogik wird zentral als Policies definiert.

Das System reagiert über alle Kanäle (UI, API, Import) hinweg konsistent — eine Regel wird einmal definiert und an jedem Enforcement-Gate identisch durchgesetzt.

Klassische Workflows führen bei zunehmender Komplexität zur Pfadexplosion, da jeder Sonderfall einen neuen gezeichneten Weg benötigt. omniSuite setzt auf mehrdimensionale Prozesslogik. Entscheidungen werden zur Laufzeit situativ aus dem konkreten Datenkontext, dem Zustand von Objekten und dem Zeitpunkt abgeleitet.

Ein Schritt ist nicht erlaubt, weil ein Pfad dorthin führt, sondern weil die zuständige Policy den aktuellen Zustand als gültig bewertet. Für Entwickler bedeutet das: Keine Pfadmodellierung, keine Sonderfall-Verzweigungen — stattdessen deklarative Regeln, die das System selbst evaluiert.

Systemische Grundfunktionen wie Statusabsicherungen, Historisierungen oder Pflichtfeldprüfungen werden über Policies bereitgestellt und müssen nicht mehr individuell als Boilerplate-Code programmiert werden. Entwickler arbeiten direkt in der Grammatik der Fachlogik und sehen die Auswirkungen ihrer Regeländerungen sofort im Systemverhalten. Das verkürzt Feedbackzyklen drastisch und reduziert technische Schulden, weil die Infrastruktur-Logik nicht mehr in Fachcode vermischt wird.

Jede Policy folgt der formalen Grammatik Event — Condition — Action (E-C-A):

Event: Ein messbarer technischer Auslöser — Speicherversuch, Statuswechsel, Zeitablauf, API-Call oder CRUD-Operation.

Condition: Eine fachliche Prüfung, die das Ereignis bewertet. Conditions arbeiten auf realen Systemwerten (persistierte Daten), nicht auf flüchtigen UI-Eingaben. Das ist ein wesentlicher Unterschied zu klassischen Formularvalidierungen.

Action: Die durchzusetzende Systemreaktion — Blockieren, Erlauben, Status setzen, Benachrichtigen, Folgeprozess anstoßen. Actions können kaskadierend wirken und weitere Events auslösen.

Diese Struktur ist maschinenlesbar und bildet die Grundlage für automatisierte Tests, Abhängigkeitsanalysen und künftige KI-Integration.

Policies werden nicht isoliert betrachtet, sondern innerhalb des Koordinatensystems aus Context, State und Time (CST):

Context: Wo und für wen gilt die Regel? Rolle, Mandant, Organisationseinheit, Kanal (UI/API/Import).

State: In welchem Zustand befindet sich das Objekt? Z. B. „In Betrieb", „Gesperrt", „Zur Freigabe bereit".

Time: Wann ist die Regel gültig? Fristen, Gültigkeitszeiträume, zeitpunktabhängige Bedingungen.

Jede Steuerungsentscheidung ist ein stetig aktualisiertes Urteil basierend auf diesen drei Achsen. Für die Implementierung bedeutet das: Regeln müssen nicht für jede Kontext-Zustand-Zeit-Kombination einzeln definiert werden — das CST-Framework evaluiert die Dimensionen automatisch bei jeder Transaktion.

Die Architektur ist in sechs gleichwertige Policy-Familien unterteilt, die bei jeder Transaktion zusammenarbeiten:

State Management Policies: Steuern fachlich und technisch korrekte Zustandsänderungen über Guard Conditions und definierte Zustandsübergänge.

Historisierung Policies: Sichern die revisionssichere Nachvollziehbarkeit aller Änderungen, einschließlich Änderungen ohne Zustandswechsel.

Correlation & Derivation Policies (ACE): Steuern Ableitung und Kaskadierung über Objektgrenzen hinweg — automatische Folgeaktionen bei Zustandsänderungen.

Data & Relationship Policies: Regeln Pflichtfelder, Formate, Integrität und Beziehungslogiken über blockierende Pre-Gates.

Data Reconciliation Policies: Überwachen die Konsistenz zwischen Systemen und Quellen, klassifizieren Abweichungen als fachliche Steuergrößen.

Authorization & Access Policies: Steuern kontextabhängig, wer was sehen oder tun darf — über vier Berechtigungsebenen und regelbasierte Vergabe.

Diese Policies definieren zulässige Zustände und die Bedingungen für Übergänge (Guard Conditions). Pro Informationsobjekt können mehrere Zustandstabellen angelegt werden, die spezifische Zustandskategorien abdecken — etwa Lebenszyklus, Ausfallstatus oder Bearbeitungsstatus.

Die Zustandstabellen werden zentral oder dezentral verwaltet und das System generiert automatisch die zugehörigen Trigger für CRUD-Operationen. Jeder Zustandswechsel wird als Ereignis in der jeweiligen Zustandstabelle erfasst. Eine Vorschau zeigt die Tabellenstruktur vor der finalen Erstellung an. Auch unveränderte Zustände können protokolliert werden, sodass Bearbeitungsvorgänge ohne Statusänderung im Life-Cycle abgebildet werden.

Sie ermöglichen die automatische Ableitung von Informationen über Objektgrenzen hinweg. Wenn sich ein Objekt ändert, berechnet die ACE automatisch die Auswirkungen auf verknüpfte Objekte (Kaskadierung). Beispiel: Wird eine Maschine auf „defekt" gesetzt, kann die Policy automatisch den zugehörigen Wartungsauftrag auf „offen" setzen und den Technikereinsatz triggern. Kaskadierungen folgen dabei der E-C-A-Struktur und sind vollständig nachvollziehbar.

Diese Policies wirken als blockierende Pre-Gates. Sie prüfen Daten unmittelbar vor der Persistenz oder einem Statuswechsel. Die regelbasierte Steuerung auf Datenebene arbeitet mit drei konkreten Kriterientypen:

Festvorgegebene Werte: Regeln auf spezifische, festgelegte Feldinhalte. Ein Feld ist nur bearbeitbar, wenn ein anderes Feld einen bestimmten Wert enthält (z. B. „Bestellstatus" nur editierbar, wenn „Genehmigungsstatus" den Wert „Genehmigt" trägt).

Werte von Auswahlfeldern: Die Bearbeitbarkeit oder Speicherbarkeit von Feldern wird durch die vom Benutzer getroffene Auswahl gesteuert (z. B. „Verkaufschance" wird deaktiviert, wenn „Kundenstatus" auf „Inaktiv" steht).

1:N-Ausprägungen: Regeln können an konkrete Datensätze in verknüpften Tabellen geknüpft werden (z. B. „Dienstwagenmodell" nur editierbar, wenn der Mitarbeiter die Rolle „Außendienst" hat).

Diese Regeln werden automatisch aktiviert, sobald eine Maske geladen wird, die mit der betroffenen Datentabelle verknüpft ist — unabhängig von der verwendeten Benutzeroberfläche.

Sie überwachen die Konsistenz über Systemgrenzen hinweg. Wenn Vertragsdaten im ERP von denen in der omniSuite abweichen, wird dies nicht nur erkannt, sondern klassifiziert und kann als fachliche Steuergröße genutzt werden, um fehlerhafte Folgeschritte im Prozess automatisch zu blockieren. Das unterscheidet Reconciliation-Policies von klassischen Datenabgleichen: Die erkannte Abweichung ist selbst ein steuerndes Element im Prozess.

Die Authorization & Access Policies arbeiten auf vier Ebenen:

Rollenbasierte Berechtigungen (RBAC): Rollen bündeln Zugriffsrechte und werden Benutzern zugewiesen. Änderungen an einer Rolle wirken automatisch auf alle zugeordneten Benutzer. Der Geltungsbereich umfasst Operationen wie SELECT, INSERT, UPDATE und DELETE pro Informationsobjekt.

Organisationseinheiten: Berechtigungen nach Abteilungen oder Teams. Benutzer einer Organisationseinheit erhalten gemeinsame Zugriffsrechte.

Partnerfirmen: Externe Partner erhalten eigene Berechtigungsprofile für ausgewählte Systemobjekte (Tabellen, Masken, Menüs, Berichte).

Individuelle Benutzer: Feingranulare Steuerung auf Einzelbenutzerebene, ergänzend zu den gruppenbasierten Berechtigungen.

Berechtigungen werden innerhalb von Rollen und Organisationseinheiten automatisch vererbt. Benutzer erhalten die Rechte ihrer zugeordneten Gruppen. Vererbte Rechte können individuell überschrieben werden — sowohl erweiternd als auch einschränkend. Die Vergabe erfolgt über zwei Wege: direkt über die Verwaltungsoberflächen für Benutzer, Rollen oder Organisationseinheiten, oder direkt an den jeweiligen Systemobjekten selbst.

Zusätzlich steht das Feature „Fehlende Beziehungen finden" zur Verfügung, das automatisiert prüft, ob alle Nutzer über ausreichende Berechtigungen für Masken und deren Datenstrukturen verfügen.

Das regelbasierte Berechtigungsmodul erweitert die klassischen Zugriffsmodelle und unterstützt RBAC, PBAC und ABAC. Berechtigungen können auf Basis von Datenebene (spezifische Attribute), bestimmten Ausprägungen des Objekts, Zustand des Objekts, Benutzerrollen, Partnerfirmen und beliebigen Kombinationen dieser Faktoren vergeben werden.

Die technische Umsetzung erfolgt über T-SQL, C# und die direkte Zuordnung in der Tabelle RIGHTOBJ. Beispiel: Der Zugriff auf einen Kunden mit Kundennummer 4711 kann spezifisch nach Rolle, Organisationseinheit und aktuellem Objektzustand gesteuert werden.

Für einmalige, temporäre Berechtigungen steht die Prozedur sp_cmdb_CreateOneShotGrantedRightsForUserform zur Verfügung. Sie wird in beliebigen SQL-Skripten aufgerufen und erwartet als Parameter: Nutzer, Art der Berechtigung (Select, Insert, Update, Delete), UserformID und Primärschlüssel der zugeordneten Maske. Die Berechtigung wird gezielt für die definierten Aktionen gesetzt und erlischt nach Verwendung — ohne dauerhafte Anpassung der Berechtigungsstruktur.

Das State Tracking Engine Modul ermöglicht es, für jedes Informationsobjekt mehrere Zustandstabellen anzulegen, die unterschiedliche Aspekte abbilden. Jede Zustandstabelle erhält eine eindeutige Bezeichnung und Beschreibung. Entwickler wählen ein Informationsobjekt und definieren das relevante Attribut (Auswahlfeld) oder den Fremdschlüssel, der auf eine Tabelle mit möglichen Zuständen verweist.

Es kann festgelegt werden, ob alter und neuer Zustand (Zustandsübergang) gespeichert werden sollen. Nach der Konfiguration generiert das System automatisch die Zustandstabelle und die zugehörigen Trigger für CRUD-Operationen. Zustandstabellen können optional Systemobjekt-Gruppen zugeordnet werden.

Ereignisse können für spezifische Zustände oder Zustandsübergänge definiert werden. Auslösebedingungen umfassen: nur bei bestimmten Zustandsübergangskombinationen (alter und neuer Zustand), nur bei bestimmten neuen Zuständen (unabhängig vom Übergang) oder nur bei bestimmten alten Zuständen (unabhängig vom Übergang).

Das Modul bietet zwei Ereignisarten: Löschen von Beziehungen zum Informationsobjekt (mit optionalem Ausschluss bestimmter Beziehungen über eine Auswahlliste) und Ausführung von SQL-Prozeduren (neu erstellt oder aus dem System ausgewählt, mit Parameterübergabe). Assistenten und Code-Vorlagen unterstützen die Erstellung. Alle Ereignisse können erstellt, bearbeitet und gelöscht werden.

Das Modul ermöglicht die Erfassung von Änderungen an Informationsobjekten, auch wenn keine Zustandsänderung vorliegt. Über den Reiter „Weitere Einstellungen" oder über tabellenabhängige Masken kann festgelegt werden, dass auch bei unverändertem Status ein Eintrag in die Life-Cycle-Tabelle vorgenommen wird.

Alternativ wird dies über SQL-Skripte (Trigger oder gespeicherte Prozeduren) gesteuert. Diese Funktionalität ermöglicht detaillierte Analysen darüber, welche Modifikationen keine Zustandsänderung bewirken, und erhöht die Transparenz der Objekthistorie.

Die Plattform folgt dem Prinzip Konfigurieren, wo möglich — Pro-Code, wo nötig. Regeln und Bedingungen werden primär deklarativ festgelegt. Wo komplexe Speziallogik nötig ist, wird diese an klar definierten Hooks (Erweiterungspunkten) mittels JavaScript, C# oder SQL ergänzt. Diese Erweiterungen bleiben isoliert, testbar und rollback-fähig, ohne das Kernsystem zu destabilisieren.

omniSuite bietet eine lückenlose Datenverwendungs-Transparenz. Für jedes Attribut oder jede Policy lässt sich auf Knopfdruck sehen, in welchen Masken, APIs oder Triggern sie verwendet wird — inklusive direktem Einblick in den zugehörigen Code. Das verhindert blinde Abhängigkeiten und gibt Entwicklern Sicherheit bei Refactoring und Policy-Änderungen.

Der DIDC macht das Deployment von Regeländerungen zu einem validierten Übergabeprozess. Vor der Bereitstellung erfolgt eine systemweite Validierung aller Abhängigkeiten. Das System erkennt vorab, ob das Ändern einer Policy zu Fehlern in anderen Prozeduren oder Masken führen würde, und verhindert riskante Deployments.

Alle Anpassungen an Zustandstabellen und Policies werden in einer Änderungsdokumentation festgehalten — jede Änderung ist nachvollziehbar und dauerhaft dokumentiert.

Die formale, maschinenlesbare Beschreibung aller Fachregeln (E-C-A-Struktur) bildet das notwendige Fundament für den Einsatz von KI-Agenten. KI-Agenten benötigen klare Strukturen, um Prozesse autonom optimieren oder validieren zu können. Eine Prognose ist in der omniSuite keine Black Box, sondern ein transparenter Eingangswert für eine bestehende Policy. Die vollständige Nachvollziehbarkeit bleibt erhalten, da jeder KI-Vorschlag durch die bestehenden Policies gefiltert und dokumentiert wird.

Durch das Zusammenspiel von State-Tracking und Historisierungs-Policies wird gespeichert, was geändert wurde und warum das System eine Entscheidung getroffen hat. Traces halten fest, welche Regel zum Zeitpunkt T unter welchen Bedingungen (CST) gegriffen hat.

Die Änderungsdokumentation aller Zustandstabellen ist dauerhaft nachvollziehbar und bietet eine transparente Übersicht über alle Versionen und Modifikationen. Das erfüllt höchste regulatorische Anforderungen und erleichtert Audits.