L02-T4 · Anwendungen und Betrieb

Datenbank, Anwendung und Betrieb gemeinsam betrachten

Wir untersuchen, wie ERP-, CRM-, BDE- und Individualanwendungen Daten erzeugen, verändern und verwenden. Standardfunktion, Konfiguration, Erweiterung und eigene Geschäftslogik grenzen wir voneinander ab.

Berechtigungen, Hintergrundverarbeitung, Monitoring, Datenintegrität, Backup, Restore, Wiederanlauf und betriebliche Verantwortlichkeiten betrachten wir als Teile derselben Anwendungsarchitektur. Fehlende Voraussetzungen und Risiken machen wir sichtbar und bereiten sie gemeinsam mit Entwicklung, Fachseite und Betrieb zur Entscheidung vor.

Übergeordnet
L02 · Datenbankarchitektur, Performance & Anwendungen
Lesetiefe
Technik
Ergebnis unserer Mitwirkung
Eine nachvollziehbare Anwendungs- und Betriebsarchitektur mit geklärten Abhängigkeiten, Risiken und Verantwortlichkeiten
Methodik
Anwendungsanalyse · Fit-Gap · Objektinventar · Betriebsanalyse · Integritätsprüfung · Wiederanlaufplanung
L02-T4

Eine Anwendung ist mehr als ihre Benutzeroberfläche

Geschäftskritische Anwendungen bestehen aus Geschäftsprozessen, Datenmodellen, Programmcode, Konfigurationen, Schnittstellen, Hintergrundverarbeitung und betrieblichen Verfahren. Erst im Zusammenwirken dieser Bestandteile entsteht das Ergebnis, auf das der Anwender und das Unternehmen angewiesen sind.

Wir verfolgen deshalb einen Geschäftsvorgang von der Eingabe über Anwendungslogik und Datenbankverarbeitung bis zum fachlichen Ergebnis. Dabei untersuchen wir auch zeitversetzte Verarbeitung, angebundene Systeme, Berechtigungen, Fehlerwege und notwendige Eingriffe des Betriebs.

01 · Standard und Individualisierung

Standardfunktion und Individualisierung unterscheiden

Bei ERP- und Standardanwendungen klären wir zunächst, welche Anforderungen bereits durch das Produkt erfüllt werden und an welchen Stellen Konfiguration, Erweiterung oder Individualentwicklung eingesetzt wurden.

Wir unterscheiden:

  • unveränderte Standardfunktion
  • fachliche und technische Konfiguration
  • herstellervorgesehene Erweiterungspunkte
  • kundeneigene Datenbankobjekte und Programme
  • veränderte Standardobjekte
  • externe Anwendungen und Schnittstellen
  • manuelle Ergänzungs- und Ersatzverfahren

Diese Trennung ist entscheidend für Wartbarkeit, Releasefähigkeit und Fehleranalyse. Sie zeigt, welche Teile durch den Hersteller getragen werden und für welche Teile der Kunde selbst dauerhaft Verantwortung übernimmt.

02 · Geschäftslogik und Datenwirkung

Geschäftslogik und Datenwirkung nachvollziehen

Geschäftsregeln können in der Benutzeroberfläche, im Anwendungsserver, in SQL und PL/SQL, in Triggern, Packages, Jobs oder angebundenen Systemen umgesetzt sein. Werden diese Regeln isoliert betrachtet, bleiben Aufrufketten und Nebenwirkungen leicht verborgen.

Wir untersuchen:

  • wo eine fachliche Regel implementiert ist
  • welche Tabellen und Geschäftsobjekte verändert werden
  • welche Prüfungen und Statusübergänge stattfinden
  • welche Folgeprozesse ausgelöst werden
  • welche Transaktionsgrenzen gelten
  • welche Fehlerbehandlung vorgesehen ist
  • welche manuellen Eingriffe möglich oder erforderlich sind

Dadurch wird erkennbar, ob eine Änderung nur eine Funktion betrifft oder weitere Prozesse, Datenbestände und Betriebsabläufe beeinflusst.

03 · Kundeneigene Objekte

Kundeneigene Objekte beherrschbar machen

Über Jahre gewachsene Anwendungen enthalten häufig eigene Tabellen, Views, Packages, Trigger, Jobs, Reports, Masken und Schnittstellen. Nicht jedes Objekt ist noch produktiv relevant. Manche Funktionen wurden mehrfach umgesetzt, andere besitzen keine erkennbare Verantwortung mehr.

Wir erstellen einen strukturierten Objektbestand und ordnen die technischen Objekte ihren fachlichen Funktionen, Aufrufpfaden und Verantwortlichkeiten zu.

Dabei unterscheiden wir unter anderem:

  • produktiv verwendete und veraltete Objekte
  • direkt aufgerufene und abhängige Komponenten
  • fachliche Kernlogik und technische Hilfsfunktionen
  • synchrone und zeitversetzte Verarbeitung
  • Standardobjekte und kundeneigene Erweiterungen
  • dokumentierte und nur im Programmcode erkennbare Regeln

Das schafft eine Grundlage für Wartung, Fehleranalyse, Migration, Releasewechsel und kontrollierte Stilllegung.

04 · Hintergrundverarbeitung

Hintergrundverarbeitung in den Geschäftsprozess einordnen

Viele fachliche Ergebnisse entstehen nicht während der unmittelbaren Benutzereingabe. Sie werden durch geplante Jobs, Concurrent Programs, Stapelverarbeitung, Warteschlangen oder periodische Verarbeitung erzeugt.

Wir betrachten diese Abläufe als Teil des Geschäftsprozesses:

  • Auslöser und Eingangsdaten
  • Abhängigkeiten und Reihenfolge
  • Zeitfenster und Prioritäten
  • Parallelität und Ressourcenkonkurrenz
  • fachliche und technische Status
  • Abbruch, Fehlerbehandlung und Wiederholung
  • nachgelagerte Verarbeitung und Ergebnisbereitstellung

Ein technisch beendeter Job ist nicht automatisch fachlich erfolgreich. Deshalb verbinden wir technische Laufzustände mit Kontrollzahlen und fachlich prüfbaren Ergebnissen.

05 · Datenintegrität

Datenintegrität über die Anwendung hinaus bewerten

Datenintegrität entsteht aus dem Zusammenspiel von Datenmodell, Constraints, Programmcode, Geschäftsregeln, Schnittstellen und zulässigen Bedienabläufen.

Wir untersuchen, welche Regeln durch die Datenbank erzwungen werden und welche ausschließlich von der Anwendung abhängen. Direkte Datenkorrekturen, unvollständige Schnittstellen oder voneinander abweichende Prüfregeln können sonst formal gültige, aber fachlich widersprüchliche Zustände erzeugen.

Zur Bewertung gehören beispielsweise:

  • Schlüssel und referenzielle Beziehungen
  • Pflichtangaben und zulässige Werte
  • Status- und Gültigkeitsregeln
  • Summen, Salden und Kontrollwerte
  • zeitliche und fachliche Abhängigkeiten
  • Herkunft und Veränderung kritischer Daten
  • Behandlung von Korrekturen und Stornierungen
  • Protokollierung administrativer Eingriffe

Erkennbare Abweichungen bereiten wir für die verantwortlichen Fachstellen auf. Die fachliche Bewertung und Freigabe verbleibt bei den zuständigen Stellen.

06 · Berechtigungen

Berechtigungen mit Aufgaben und Verantwortung verbinden

Anwendungsrollen, Datenbankrechte und technische Konten müssen zu den tatsächlichen Aufgaben und Verantwortlichkeiten passen. Historisch gewachsene Berechtigungen können Funktionstrennung, Nachvollziehbarkeit und Betriebssicherheit beeinträchtigen.

Wir analysieren:

  • Benutzer- und Anwendungsrollen
  • privilegierte technische Konten
  • direkte Datenbankzugriffe
  • Rechte von Jobs und Schnittstellen
  • Funktionstrennung bei kritischen Vorgängen
  • Vergabe, Änderung und Entzug von Berechtigungen
  • Protokollierung administrativer Aktivitäten

Dabei wird sichtbar, welche Berechtigungen betrieblich erforderlich sind, wo ungewollte Abhängigkeiten bestehen und welche Entscheidungen durch Informationssicherheit, Datenschutz, Fachverantwortung oder Revision getroffen werden müssen.

07 · Monitoring

Betriebsverhalten sichtbar machen

Monitoring muss nicht nur technische Verfügbarkeit zeigen. Es muss erkennen lassen, ob die Anwendung ihre geschäftliche Aufgabe noch erfüllt.

Wir verbinden technische und fachliche Beobachtungspunkte:

  • Erreichbarkeit und Antwortzeiten
  • erfolgreiche und fehlerhafte Geschäftsvorgänge
  • Warteschlangen und Rückstände
  • Laufzeit und Status kritischer Hintergrundprozesse
  • Datenbankfehler, Sperren und Ressourcenengpässe
  • fehlende oder verspätete Datenlieferungen
  • fachliche Kontrollzahlen und Abweichungen
  • erforderliche Reaktionen und Eskalationen

So können technische Ereignisse nach ihrer Wirkung auf Geschäftsprozesse und vereinbarte Services priorisiert werden.

08 · Wiederherstellung

Backup, Restore und Wiederanlauf auf die Anwendung beziehen

Ein erfolgreiches Datenbank-Backup beantwortet noch nicht, ob die gesamte Anwendung nach einem Ausfall wieder einen konsistenten und fachlich verwendbaren Zustand erreicht.

Wir betrachten deshalb gemeinsam:

  • gesicherte Datenbanken, Dateien und Konfigurationen
  • Abhängigkeiten zu Schnittstellen und Fremdsystemen
  • zeitliche Konsistenz zusammengehöriger Datenbestände
  • laufende oder unterbrochene Geschäftsvorgänge
  • erneut anzustoßende Hintergrundverarbeitung
  • Behandlung bereits versendeter Nachrichten und Dateien
  • erforderliche fachliche Kontrollen nach der Wiederherstellung
  • Reihenfolge und Verantwortlichkeiten beim Wiederanlauf

Restore und Wiederanlauf werden damit nicht nur als technische Datenbankverfahren, sondern als Wiederherstellung der geschäftlichen Verarbeitungsfähigkeit beschrieben.

09 · Änderungen

Änderungen mit Fachseite und Betrieb vorbereiten

Änderungen an Datenmodell, Geschäftslogik, Schnittstellen oder Hintergrundverarbeitung können Auswirkungen auf Bedienung, Performance, Sicherheit, Monitoring und Wiederherstellung haben.

Wir analysieren diese Auswirkungen und führen die benötigten Beiträge zusammen:

  • fachliche Beschreibung und erwartetes Ergebnis
  • betroffene Anwendungen, Daten und Schnittstellen
  • notwendige Datenkonvertierungen
  • technische Umsetzung und Rückfallmöglichkeit
  • Test- und Prüfkriterien
  • Anpassung von Rollen und Berechtigungen
  • Monitoring und Betriebsdokumentation
  • Einweisung und erforderliche Mitwirkung
  • Freigaben der zuständigen Stellen

Wir ersetzen dabei weder die Fachverantwortung noch die Betriebsverantwortung. Wir bereiten die Änderung gemeinsam mit den Beteiligten so vor, dass ihre Auswirkungen beurteilt und die erforderlichen Entscheidungen getroffen werden können.