Data Integrity Deployment Cycle (DIDC)

Das Problem liegt selten in der Änderung selbst. Es liegt darin, dass niemand vor der Änderung weiß, was sie tatsächlich betrifft. Abhängigkeiten zwischen Masken, Skripten, Triggern und Prozeduren sind in den meisten Systemen unsichtbar – bis etwas bricht. Der DIDC macht diese Abhängigkeiten sichtbar, bevor Sie die Änderung durchführen. Sie sehen, welche Systemelemente betroffen sind, wo Konflikte entstehen könnten und was Sie prüfen müssen. Damit verschiebt sich der Aufwand dorthin, wo er sinnvoll ist: vor das Deployment, nicht danach.

Impact-Analyse ist kein optionales Feature – sie ist im DIDC fest verankert. Jede geplante Änderung durchläuft eine automatische Prüfung der betroffenen Masken, Skripte und Prozeduren. Konflikte und Inkonsistenzen werden erkannt, bevor sie in die Produktivumgebung gelangen. Das reduziert den Anteil unerwarteter Fehler nach dem Deployment auf ein strukturell begrenzbares Maß. Gleichzeitig schützt das dreistufige Testkonzept – isolierte Tests, Integrationstests und Daten-Sandboxen – die Produktivdaten zu jedem Zeitpunkt.

In klassischen Systemen bauen Teams nachträglich Qualitätsprüfungen ein – als separate Schritte, separate Werkzeuge, separate Verantwortlichkeiten. Der DIDC folgt einem anderen Ansatz: Qualitätssicherung ist kein Aufsatz auf die Plattform, sondern Teil ihrer Logik. Syntax- und Logikprüfungen, Rückverfolgbarkeit, Änderungsdokumentation und Freigabeprozesse greifen direkt auf die Systemobjekte zu, ohne externe Werkzeuge oder manuelle Übertragungsschritte. Das bedeutet: weniger Koordinationsaufwand, weniger Fehlerquellen durch Medienbrüche und eine kürzere Kette vom Fehler bis zur Diagnose.

Auditierbarkeit entsteht im DIDC nicht als Zusatzaufwand. Jede Änderung an Tabellen, Masken, Attributen oder Skripten wird strukturiert protokolliert – mit Zeitpunkt, Person, Begründung und Beschreibung. Diese Informationen liegen im System, nicht in separaten Dokumenten oder Kommunikationsverläufen. Wer nachweisen muss, wer wann was geändert hat und aus welchem Grund, findet diese Informationen direkt am Systemobjekt. Compliance wird damit zu einem Nebenprodukt der normalen Arbeit, nicht zu einem eigenen Projekt.

Der größte Kostentreiber bei Releases ist die Unsicherheit darüber, was sich ändert und was davon abhängt. Der kontrollierte Paketexport im DIDC überträgt Systemobjekte strukturiert zwischen Entwicklungs-, Test- und Produktivumgebungen. Ein automatischer Abgleich prüft Konsistenz zwischen Quell- und Zielumgebung und stellt eine sinnvolle Übernahmereihenfolge sicher. Manuelle Freigaben erfolgen gezielt an definierten Punkten. Das Resultat ist ein Deployment-Prozess, der reproduzierbar ist – nicht abhängig von implizitem Wissen einzelner Personen.

Der Einstiegspunkt ist die Headerleiste: Systeme → System-Integrität. Von dort aus wählen Sie gezielt, welche SQL-Skripte, APIs, Trigger oder gespeicherten Prozeduren geprüft werden sollen – einzeln oder als Gesamtprüfung. Das System führt Syntax- und Logikprüfungen durch, identifiziert veraltete oder nicht mehr vorhandene Attribute und bietet eine direkte Navigation zum jeweiligen Fehler. Parallel dazu steht die dezentrale Fehlerprüfung zur Verfügung: Einzelne Elemente lassen sich gezielt validieren, ohne den Gesamtprüflauf anzustoßen.

Rückverfolgbarkeit beantwortet die Frage: Wo wird dieses Element verwendet? Die Analyse der Verwendung von Attributen, Tabellen, Masken und Beziehungen zeigt, in welchen Skripten, Triggern und Prozeduren ein bestimmtes Element referenziert wird. Impact-Analyse baut darauf auf und beantwortet die Folgefrage: Was ändert sich, wenn ich dieses Element anpasse? Beide Mechanismen greifen direkt auf die Systemmetadaten zu. Das Ergebnis ist keine statische Dokumentation, sondern eine immer aktuelle Sicht auf die tatsächlichen Abhängigkeiten im System.

Isolierte Tests ermöglichen es, Code unabhängig von laufenden Produktivprozessen zu testen – ohne Interferenzen, ohne Risiko für den Betrieb. Integrationstests bilden reale Bedingungen in einer simulierten Umgebung ab und prüfen, ob Komponenten unter realistischen Voraussetzungen korrekt zusammenwirken. Daten-Sandboxen erzeugen isolierte Testdatensätze, die keinen Einfluss auf Produktivdaten haben. Dynamische Abhängigkeiten werden dabei automatisch erkannt und in die Prüfung einbezogen. Die drei Stufen sind nicht alternativ, sondern greifen konzeptionell ineinander.

Systemobjektgruppen bündeln zusammengehörige Design-Ergebnisse – Tabellen, Masken, Skripte, Trigger – zu einem transportierbaren Paket. Der Export überträgt dieses Paket strukturiert von der Entwicklungs- in die Testumgebung, von dort in die Produktivumgebung. Vor der Übernahme gleicht das System Quell- und Zielumgebung ab: Es prüft, ob Objekte bereits vorhanden sind, ob Versionen übereinstimmen und in welcher Reihenfolge Abhängigkeiten aufgelöst werden müssen. Inkonsistenzen werden vor der Übernahme angezeigt, nicht danach.

Die Änderungsdokumentation im DIDC ist strukturiert, nicht frei. Für jede Änderung an einem Systemelement – Tabelle, Maske, Attribut, Skript – erfasst das System Zeitpunkt, verantwortliche Person, Begründung und Beschreibung der Änderung. Diese Informationen sind direkt am Objekt zugänglich und nicht von externen Dokumentationswerkzeugen abhängig. Das schafft eine lückenlose Nachvollziehbarkeit, die ohne zusätzlichen Aufwand entsteht – weil sie Teil des normalen Änderungsprozesses ist.

Systemobjektgruppen sind das organisatorische Bindeglied zwischen Entwicklung und Bereitstellung. Sie bündeln alle Elemente, die zu einem fachlichen Design-Ergebnis gehören, und machen sie als Einheit transportierbar. Das verhindert, dass einzelne Objekte vergessen werden oder in einer falschen Version deployed werden. Die Gruppe definiert außerdem implizit die logische Abhängigkeitsstruktur, die der automatische Abgleich bei der Zielübernahme berücksichtigt. Damit ist die Gruppe nicht nur ein Strukturierungsmittel, sondern ein aktiver Teil der Qualitätssicherung.