Analyse & Bewertung

Ein mittelständisches Unternehmen beauftragte den IT-Sachverständigen mit der tiefgehenden technischen Analyse einer unternehmensweiten ERP- und Datenintegrationsplattform. Ziel war die objektive Bewertung von Softwarearchitektur, Performance, Datenqualität und Wartbarkeit auf Basis technischer, normativer und wissenschaftlich fundierter Kriterien.

Ausgangssituation

Das Unternehmen betrieb eine mehrschichtige ERP-Plattform zur Abbildung zentraler Geschäftsprozesse in Produktion, Logistik und Rechnungswesen. Das System bestand aus einer Kombination proprietärer Softwaremodule, individueller Anpassungen und mehrerer externer Schnittstellen zu Lieferanten- und Finanzsystemen. Aufgrund wiederkehrender Systemausfälle, Performanceprobleme bei hoher Benutzerlast und divergierender Datenstände wurde der IT-Sachverständige mit einer unabhängigen technischen Analyse beauftragt. Die Untersuchung sollte Ursachen, Risiken und Optimierungspotenziale aufdecken und eine fundierte Grundlage für technische und organisatorische Entscheidungen liefern.

Problemstellung

Die Analyse verfolgte das Ziel, die technische Qualität und Reife der Plattform anhand reproduzierbarer Kriterien zu bewerten. Die Kernfragen lauteten:

• Erfüllt die Softwarearchitektur die Anforderungen an Wartbarkeit, Skalierbarkeit und Sicherheit gemäß [NORM_PLATZHALTER]?
• Wie konsistent, vollständig und aktuell sind die Datenbestände im Sinne des [NORM_PLATZHALTER] Data Quality Model?
• Welche systemischen Engpässe oder architektonischen Schwachstellen führen zu Performanceproblemen?
• Wie transparent und dokumentiert sind Architekturentscheidungen, Prozesse und Schnittstellen?
• Welche Risiken bestehen hinsichtlich technischer Schulden, Systemstabilität und organisatorischer Verantwortlichkeiten?

Das Gutachten sollte eine objektive, quantitativ belegbare Bewertung liefern und konkrete Handlungsempfehlungen ableiten.

Vorgehen des IT-Sachverständigen

Die Untersuchung folgte einem methodisch klar definierten Vier-Phasen-Modell nach ingenieurmäßigen Analyseprinzipien (angelehnt an Nicolai Andler, Publicis, 2015) und den Normen [NORM_PLATZHALTER], 12207 und 27001:

• 1. Diagnosephase: Vollständige Erfassung der Systemlandschaft (ERP-Kernsystem, Datenbanken, Middleware, API-Gateways) sowie der Infrastrukturparameter. Dokumentations- und Quellcodeanalyse mit Fokus auf Versionierung, Abhängigkeiten und technischen Schulden.
• 2. Zielformulierung: Definition von Prüf- und Bewertungsmetriken, darunter:
  • Cyclomatic Complexity (Code-Komplexität)
  • Coupling/Cohesion Ratio (Modularität)
  • Data Completeness Ratio (Datenvollständigkeit)
  • MTTR/MTBF (Systemzuverlässigkeit)
  • Response Time / Throughput (Leistungskennzahlen)
• 3. Analysephase: Anwendung kombinierter Verfahren aus Softwaretechnik und Data Engineering:
  • Statische und dynamische Codeanalysen mit SonarQube und PMD,
  • Architektur-Review (Layer-Struktur, Schnittstellen, Abhängigkeiten, Deployment-Topologie),
  • Datenfluss- und ETL-Analyse zur Überprüfung von Synchronisationszyklen und Datenintegrität,
  • Last- und Performancetests (JMeter, Grafana) zur Identifikation von Skalierungsengpässen.
• 4. Bewertung & Klassifikation: Zusammenführung aller Ergebnisse in einer normbasierten Reifegradmatrix (1 = kritisch – 5 = exzellent) für die Dimensionen Codequalität, Architektur, Datenqualität, Performance, Dokumentation und Governance.

Ergänzend wurden qualitative Interviews mit Softwarearchitekten, Datenbankadministratoren und Fachbereichsverantwortlichen durchgeführt, um Prozessflüsse, Entscheidungswege und technische Abhängigkeiten nachvollziehbar abzubilden.

Analyseergebnisse

Die Untersuchung führte zu einem differenzierten Gesamtbild:

• Softwarequalität: Der Quellcode war grundsätzlich stabil, aber stark heterogen. Nur 42 % der Module erfüllten interne Coding-Standards; Testabdeckung: 36 %. Durchschnittliche Cyclomatic Complexity: 14,2 (Grenzwert: 10). Identifiziert wurden 124 Code Smells und 18 potenzielle Sicherheitslücken.
• Architektur: Die Applikation wies redundante Logikschichten auf. Ein direkter Datenbankzugriff aus der UI-Schicht verletzte das Schichtenprinzip (Layer Violation). Fehlende API-Governance führte zu inkonsistentem Schnittstellenverhalten.
• Datenqualität: ETL-Prozesse synchronisierten Daten nur alle 12 Stunden. Abweichungen zwischen Quellsystem und Zielsystem betrugen bis zu 8 %. Data Completeness Ratio: 91,7 %, Data Accuracy Score: 93,4 %.
• Performance: Durchschnittliche Antwortzeiten: 340–380 ms bei 1.000 gleichzeitigen Anfragen; Spitzenlast führte zu 11 % Timeouts. Hauptursache: Ineffiziente Joins und fehlende Indexierung im Order-Management-Modul.
• Dokumentation & Governance: Architekturdiagramme veraltet (Stand 2021), keine dokumentierten Architecture Decision Records (ADRs). Verantwortlichkeiten für Datenflüsse nicht eindeutig definiert.

Die technische Reife wurde im Durchschnitt mit 3,1 von 5 Punkten bewertet („funktionsfähig, aber mit mittlerem Sanierungsbedarf“).

Erkenntnisse & Empfehlungen

Aus der Analyse leitete der IT-Sachverständige einen priorisierten Maßnahmenplan ab:

• Architekturmodernisierung: Einführung eines konsistenten Drei-Schichten-Modells (Presentation – Business – Data Layer) mit API-Gateway und Service Registry. Refactoring der Schichtenkommunikation nach dem Dependency-Inversion-Prinzip.
• Softwarequalität: Aufbau eines Continuous-Integration-Systems mit automatisierter Testabdeckung (>80 %) und statischen Codeanalysen in der Build-Pipeline.
• Datenmanagement: Implementierung einer Datenqualitätsüberwachung mit Monitoring der KPIs Data Accuracy, Completeness und Timeliness.
• Performance: Optimierung der Abfragen (Query-Refactoring, Indexierung), Einführung von Connection-Pooling und Caching auf Application-Ebene, Integration von Load-Balancern zur horizontalen Skalierung.
• Governance & Dokumentation: Aufbau eines zentralen Architektur-Repositorys mit ADR-Dokumentation, klarer Verantwortlichkeitsstruktur (Data Owner / Process Owner) und jährlicher interner Auditierung nach [NORM_PLATZHALTER].

Nach Umsetzung dieser Empfehlungen ergab ein Folgegutachten:

• Testabdeckung: +42 %
• Durchschnittliche Antwortzeit: –48 %
• Reduktion von Dateninkonsistenzen: –5,6 %
• Gesamtreifegrad: 4,4 / 5

Die Plattform erreichte somit ein stabiles, skalierbares und dokumentiertes Qualitätsniveau.

Reflexion

Diese Fallstudie verdeutlicht den Nutzen einer methodisch fundierten, datenbasierten Analyse als Grundlage technischer und strategischer Entscheidungen. Der IT-Sachverständige schafft durch den Einsatz normierter Bewertungsverfahren, reproduzierbarer Kennzahlen und technischer Transparenz eine belastbare Entscheidungsbasis für Geschäftsführung, Projektsteuerung und – im Streitfall – juristische Beurteilungen. Die Kombination aus technischer Tiefenanalyse und strukturiertem Bewertungsrahmen gewährleistet Objektivität, Nachvollziehbarkeit und Nachhaltigkeit der Gutachtenergebnisse.

Ein E-Commerce-Unternehmen beauftragte den IT-Sachverständigen mit der umfassenden Analyse und Bewertung von Performanceproblemen in seiner Cloud-basierten Handelsplattform. Ziel war die Identifikation systemischer Engpässe, die Überprüfung der Skalierbarkeit und die Erarbeitung konkreter Optimierungsmaßnahmen auf Grundlage objektiver, reproduzierbarer Messwerte.

Ausgangssituation

Das Unternehmen betrieb eine hochverfügbare E-Commerce-Plattform mit Microservice-Architektur auf Kubernetes-Basis. Die Systeme verarbeiteten täglich bis zu 1,2 Mio. API-Requests und über 15 000 Bestellvorgänge. Seit dem Anstieg der Nutzerzahlen im Weihnachtsgeschäft traten wiederholt Latenzspitzen, unvollständige Bestelltransaktionen und API-Timeouts auf. Trotz interner Log-Analysen konnten die Ursachen nicht eindeutig identifiziert werden. Der IT-Sachverständige wurde mit einer unabhängigen technischen Performanceanalyse beauftragt, um technische Schwachstellen, strukturelle Bottlenecks und Skalierungsdefizite zu ermitteln.

Problemstellung

Im Mittelpunkt der Untersuchung standen folgende Fragestellungen:

• In welchen Komponenten der Microservice-Architektur entstehen die beobachteten Performance-Engpässe?
• Sind Datenbankzugriffe, API-Kommunikation oder die Container-Orchestrierung ursächlich beteiligt?
• Wie effizient nutzt die Plattform ihre Cloud-Ressourcen (CPU, I/O, Netzwerk, Storage)?
• Erfüllt das Gesamtsystem die definierten Service-Level-Agreements (SLAs) hinsichtlich Antwortzeit, Verfügbarkeit und Durchsatz?

Ziel war eine objektive, nachvollziehbare Bewertung der Systemleistung unter realen Lastbedingungen sowie die Formulierung technischer Handlungsempfehlungen zur Stabilisierung und Skalierung.

Vorgehen des IT-Sachverständigen

Der Gutachter wendete einen normgestützten, mehrstufigen Analyseansatz an, basierend auf [NORM_PLATZHALTER] und [NORM_PLATZHALTER]:

• 1. Mess- und Monitoringphase: Einrichtung reproduzierbarer Lasttests mit JMeter und K6; Erfassung von Response Times, CPU-, RAM- und I/O-Last über Prometheus und Grafana. Tracing der Service-Latenzen mittels OpenTelemetry und Jaeger.
• 2. Architektur- und Infrastruktur-Review: Bewertung der Container-Topologie (Kubernetes, Istio), Analyse der Horizontal Scaling Policies, Load Balancer-Konfiguration und Service Dependencies.
• 3. Datenbank- und API-Analyse: Messung von Query-Laufzeiten, Indexverwendung, Connection-Pooling und Transaktionsverhalten; Analyse der API-Gateways auf Timeouts, Retries und Caching-Strategien.
• 4. Vergleich Soll/Ist: Gegenüberstellung der gemessenen Kennzahlen mit SLA-Vorgaben (Zielwert: ≤ 250 ms Response Time, 99,5 % Uptime) und internen Architekturstandards.

Alle Messungen wurden mehrfach unter kontrollierten Bedingungen durchgeführt, um externe Störeinflüsse auszuschließen. Ergänzend erfolgten Interviews mit Cloud-Architekten, DevOps-Teams und Fachbereichsleitern.

Analyseergebnisse

Die Untersuchung lieferte ein konsistentes technisches Befundbild:

• Systemleistung: 87 % aller Requests überschritten den SLA-Schwellenwert von 250 ms. Durchschnittliche Antwortzeit: 348 ms (Peak 520 ms). CPU-Auslastung einzelner Container bis 93 %, ungleichmäßiges Pod-Balancing.
• Datenbankebene: Fehlende Indexierung führte zu durchschnittlichen Query-Laufzeiten von 120 ms; Connection-Pools waren auf 15 Verbindungen limitiert (Sollwert ≥ 50). Deadlocks traten bei hoher Parallelität regelmäßig auf.
• Orchestrierung: Der Horizontal Pod Autoscaler war unzureichend konfiguriert – Skalierung erfolgte erst bei 80 % CPU-Last mit 10-Minuten-Cooldown, wodurch Lastspitzen nicht rechtzeitig abgefangen wurden.
• Logging / I/O: Die synchrone Log-Aggregation belastete den Storage-I/O; Schreibwartezeiten von bis zu 300 ms erhöhten die Gesamtlatenz deutlich.
• Netzwerk: API-Gateways arbeiteten ohne Circuit-Breaker-Mechanismen; Retries bei Fehlanfragen verstärkten die Lastspitzen.

Insgesamt wurde die technische Leistungsfähigkeit mit einem Reifegrad von 3,0 / 5 bewertet („stabil, aber nicht skalierungsoptimiert“).

Erkenntnisse & Empfehlungen

Der IT-Sachverständige formulierte auf Basis der Analyse einen priorisierten Optimierungskatalog:

• Datenbankoptimierung: Einführung automatischer Indexierung und Query-Caching, Anpassung der Poolgrößen auf ≥ 60 Verbindungen, Refactoring komplexer Joins und Implementierung von Read Replicas.
• Skalierungsstrategie: Re-Konfiguration des Autoscalers mit dynamischen Thresholds (Start bei 55 % CPU-Last, Cooldown 60 Sekunden) und Implementierung einer Blue-Green-Deployment-Strategie zur unterbrechungsfreien Skalierung.
• Monitoring & Alerting: Einführung eines zentralen APM-Systems (z. B. Datadog / New Relic) mit automatisierten Anomalieerkennungen und SLAM-Reports nach [NORM_PLATZHALTER]-1.
• Architekturmaßnahmen: Einführung von Circuit-Breaker-Patterns und asynchroner Log-Verarbeitung (Message-Queue-basierte Aggregation), um Latenzen zu reduzieren.
• Governance: Aktualisierung des Architekturhandbuchs, Definition klarer SLAs und Capacity-Planning-Richtlinien in Abstimmung mit dem DevOps-Team.

Nach Umsetzung der empfohlenen Maßnahmen zeigte ein Folgeaudit folgende Verbesserungen:

• ⟶ Durchschnittliche Antwortzeit: −52 %
• ⟶ Timeout-Rate: < 0,5 %
• ⟶ CPU-Spitzenlast: −37 %
• ⟶ Systemverfügbarkeit: 99,8 %

Die Plattform bestand einen abschließenden Stresstest mit 20 % höherer Last ohne Funktionsstörungen und wurde von den Investoren für internationale Skalierung freigegeben.

Reflexion

Diese Fallstudie verdeutlicht, dass Performanceanalysen nur auf Basis messbarer, reproduzierbarer Kennzahlen objektiv durchgeführt werden können. Die Kombination aus technischer Instrumentierung, normbasierter Bewertung und organisatorischer Nachsteuerung führt zu nachhaltig belastbaren Ergebnissen. Der IT-Sachverständige verbindet hierbei ingenieurmäßige Präzision mit Management-Relevanz – ein entscheidender Erfolgsfaktor für die Stabilität und Skalierbarkeit moderner Cloud-Infrastrukturen.

Ein Industrieunternehmen beauftragte den IT-Sachverständigen mit einer unabhängigen technischen Analyse der Daten- und Modellqualität eines Machine-Learning-Systems zur Anomalieerkennung in Produktionsanlagen. Ziel war eine nachvollziehbare Bewertung der Reproduzierbarkeit, Robustheit, Nachvollziehbarkeit und Datenintegrität gemäß wissenschaftlich und normativ fundierten Qualitätskriterien.

Ausgangssituation

Das Unternehmen setzte ein KI-basiertes System zur Echtzeitüberwachung von Produktionsmaschinen ein. Das Modell sollte aus Sensordaten (Temperatur, Vibration, Stromaufnahme) frühzeitig Anomalien erkennen und Wartungsbedarf prognostizieren. Nach wiederholten Fehlalarmen, unklaren Modellentscheidungen und widersprüchlichen Prognoseergebnissen wurde der IT-Sachverständige mit einer technischen Untersuchung der zugrunde liegenden Daten- und Modellqualität beauftragt. Ziel war die objektive Beurteilung der Zuverlässigkeit, Reproduzierbarkeit und methodischen Integrität des Machine-Learning-Systems.

Problemstellung

Der Gutachter sollte klären, inwieweit die eingesetzten Modelle den Qualitätsanforderungen aus den Normen [NORM_PLATZHALTER], [NORM_PLATZHALTER] und [NORM_PLATZHALTER] genügten. Zentrale Fragestellungen waren:

• Wie vollständig, valide und konsistent sind die verwendeten Trainings- und Sensordaten?
• Wie stabil und reproduzierbar sind die Ergebnisse der ML-Modelle bei identischen Eingangsdaten und Parametern?
• Welche Mechanismen zur Fairness-, Bias- und Robustheitskontrolle sind implementiert?
• Wie ist die Nachvollziehbarkeit der Modellentwicklung und -versionierung dokumentiert (Audit-Trail, Model Cards)?
• Erfüllt das System die regulatorischen Anforderungen an Transparenz, Reproduzierbarkeit und Rechenschaftspflicht gemäß [GESETZ_PLATZHALTER]?

Vorgehen des IT-Sachverständigen

Die technische Analyse erfolgte nach einem methodisch fundierten, mehrstufigen Ansatz, der Verfahren aus Data Science, Softwaretechnik und KI-Ethik kombinierte:

• 1. Datenanalyse: Überprüfung der Datenpipelines auf Vollständigkeit, zeitliche Konsistenz und Anomalien; statistische Bewertung der Trainingsdaten (z. B. Missing-Value-Rate, Outlier-Quoten, Feature-Correlation). Einsatz von Data-Profiling-Tools (Pandas-Profiling, Great Expectations) zur quantitativen Bewertung der Datenqualität.
• 2. Modellbewertung: Durchführung von Cross-Validation-Tests (10-fold CV) und Monte-Carlo-Repeats, Berechnung von F1-Score, Precision, Recall und Variance-Coefficient zur Beurteilung der Modellstabilität über 50 Trainingsläufe.
• 3. Explainable-AI-Prüfung: Anwendung von LIME- und SHAP-Analysen zur Modellinterpretation; Identifikation überproportional gewichteter Features und Beurteilung der Kausalitätslogik anhand globaler und lokaler Erklärungsmodelle.
• 4. Reproduzierbarkeitstest: Fixierung der Random Seeds, Protokollierung der Hyperparameter, Wiederholung der Trainingsprozesse mit identischen Daten-Snapshots und anschließender Ergebnisverifikation (Diff-Analyse der Predictions).
• 5. Dokumentations- und Governance-Prüfung: Analyse der Model Cards, Audit-Protokolle und Trainingsdokumentationen auf Vollständigkeit, Versionierung und Nachvollziehbarkeit der Änderungen.

Analyseergebnisse

Die technische Analyse ergab mehrere signifikante Befunde:

• Datenqualität: 5,8 % der Sensordaten wiesen fehlende oder unplausible Werte auf; 2,1 % der Datenpunkte lagen außerhalb physikalisch erklärbarer Wertebereiche. Feature-Korrelationen zeigten Redundanzen von bis zu 0,89 (Overfitting-Risiko).
• Modellstabilität: Varianz im F1-Score über 50 Läufe: 0,117; Accuracy-Schwankung ±3,4 %. Reproduzierbarkeitstest zeigte Abweichungen von bis zu 2,8 % bei identischen Eingangsdaten, bedingt durch nicht deterministische GPU-Operationen.
• Explainability: SHAP-Analysen belegten eine Übergewichtung einzelner Temperaturkanäle (Feature Importance: 62 %). LIME-Analysen zeigten fehlende Interpretierbarkeit in seltenen Störfallklassen (Cluster < 2 %).
• Bias & Fairness: Keine nachweisbare systematische Diskriminierung, jedoch ungleiche Sensitivität zwischen Maschinentypen (Differenz der False-Positive-Rate: 7,4 %).
• Dokumentation: Audit-Trail unvollständig (nur 68 % der Modellversionen protokolliert); Model Cards ohne Angaben zu Hyperparametern und Trainingsdatenständen.

Die Gesamtbewertung ergab einen durchschnittlichen Qualitätsreifegrad von 3,6 / 5 („robust, aber eingeschränkt reproduzierbar und dokumentiert“).

Erkenntnisse & Empfehlungen

Der Sachverständige formulierte konkrete Maßnahmen zur Verbesserung von Stabilität, Nachvollziehbarkeit und Datenqualität:

• Datenmanagement: Implementierung eines Data-Version-Control-Systems (DVC) mit automatischer Snapshot-Erstellung und Reproduzierbarkeitsprotokollen; Einführung von Quality-Gates für Vollständigkeit, Konsistenz und Anomalieerkennung.
• Modell-Governance: Einführung eines MLOps-Frameworks mit MLflow-Tracking, automatischer Protokollierung von Parametern, Modellen und Evaluierungsergebnissen; Integration eines Reproducibility-Index in den CI/CD-Workflow.
• Bias- und Fairness-Überwachung: Aufbau eines periodischen Bias-Monitoring-Systems (Fairlearn, AIF360) und Durchführung halbjährlicher Fairness-Audits.
• Dokumentation: Erstellung vollständiger Model Cards und Audit-Protokolle nach [NORM_PLATZHALTER] mit Erfassung aller Modellversionen, Trainingsumgebungen und Hyperparameter-Settings.
• Explainability & Qualitätssicherung: Etablierung einer internen KI-Prüfgruppe mit Verantwortlichkeiten für Modellvalidierung, Nachvollziehbarkeit und ethische Bewertung.

Ein Folgeaudit sechs Monate nach Umsetzung ergab messbare Verbesserungen:

• ⟶ Varianz im F1-Score: 0,028 (−76 %)
• ⟶ Fehlalarme: −42 %
• ⟶ Datenvollständigkeit: +6,3 %
• ⟶ Dokumentationsabdeckung: 100 %

Das System wurde anschließend erfolgreich als „technisch validiert und reproduzierbar“ freigegeben.

Reflexion

Diese Fallstudie zeigt exemplarisch, dass KI-Systeme nicht nur softwaretechnisch, sondern auch daten- und modellseitig einer methodischen Qualitätssicherung unterliegen müssen. Eine technische Bewertung nach objektiven, normgestützten Kriterien schafft Nachvollziehbarkeit, Reproduzierbarkeit und Vertrauen – sowohl im industriellen Einsatz als auch gegenüber Aufsichtsbehörden und Investoren. Der IT-Sachverständige trägt dabei entscheidend zur technischen, ethischen und regulatorischen Absicherung datengetriebener Systeme bei.