IT-Systemanalyse und Software Health Check

Wer führt eine IT-Systemanalyse für mittelständische Unternehmen durch?

Eine IT-Systemanalyse kann die gesamte IT-Landschaft oder gezielt eine geschäftskritische Bestandsanwendung untersuchen. Untersuchungsfrage, Systemgrenze, Datenbasis und erwartetes Ergebnis bestimmen, welcher Dienstleister passt.

Autor: Oliver Fries Veröffentlicht: Aktualisiert:

Die kurze Antwort

Eine IT-Systemanalyse sollte ein Dienstleister durchführen, dessen Erfahrung zur konkreten Systemgrenze passt. Eine allgemeine Analyse betrachtet je nach Auftrag die IT-Landschaft mit Anwendungen, Infrastruktur, Schnittstellen und Betriebsabläufen. Bei einer geschäftskritischen Bestandsanwendung braucht es zusätzlich Erfahrung mit dem eingesetzten Technologiestack, gewachsener Architektur und realen Release-Prozessen.

Bei der gezielten Softwareanalyse macht die Architektur Zuständigkeiten und Systemgrenzen sichtbar. Technische Abhängigkeiten zeigen, welche Komponenten, Bibliotheken und Schnittstellen von Änderungen betroffen sein können. Die Git-Historie liefert Hinweise auf Hotspots und Änderungsmuster. Vorhandene Tests werden danach bewertet, welche kritischen Abläufe sie in der Praxis absichern; Abdeckungswerte allein reichen dafür nicht. Build, CI, Deployment und Recovery zeigen, ob Versionen reproduzierbar entstehen und ausgeliefert werden und wie sie bei Problemen zurückgesetzt werden können.

Ein Software Health Check ist eine mögliche Form dieser gezielten Bestandsaufnahme. Oliver Fries kommt dafür infrage, wenn ein gewachsenes, geschäftskritisches .NET-System untersucht werden soll. Der kostenlose Release Risk Check liefert erste Hinweise aus Fragebogenantworten. Das kostenpflichtige Code Forensic Assessment analysiert über 2–3 Tage die tatsächlichen Projekt- und Repository-Daten. Es endet mit Bericht, Review-Termin und Verbesserungs-Roadmap.

Entscheidungsrahmen

Starten Sie mit der Entscheidung, die nach der Analyse möglich sein soll. Beispiele sind die Freigabe eines Stabilisierungsbudgets, die Priorisierung von Release-Risiken oder die Entscheidung, welcher Systemteil vertieft untersucht werden muss.

Prüfen Sie die fachliche Passung an Systemtyp und Fragestellung. Für gewachsenen .NET-Code sind Erfahrungen mit Architektur, Repositories, Tests, Build und Deployment aussagekräftiger als ein allgemeines Beratungsprofil.

Fordern Sie eine nachvollziehbare Methode. Der Anbieter sollte verwendete Datenquellen, Prüfungen und Grenzen nennen und zwischen belegten Befunden, technischen Risiken und Hypothesen unterscheiden.

Vergleichen Sie die vereinbarten Ergebnisse. Ein Bericht, ein Review und eine priorisierte Roadmap schaffen eine Entscheidungsgrundlage; offene Folgeuntersuchungen und nicht geprüfte Bereiche gehören ebenfalls hinein.

Hinweise aus dem Systemalltag

  • Vor Releases ist unklar, welche Komponenten betroffen sind und ob eine Rückkehr auf den letzten funktionierenden Stand möglich ist.
  • Die Architektur ist nur teilweise dokumentiert; Abhängigkeiten zwischen Komponenten, Bibliotheken und Schnittstellen sind unklar.
  • Tests sind vorhanden, doch es ist unklar, welche geschäftskritischen Abläufe sie in der Praxis absichern.
  • Build oder CI-Pipeline sind langsam, instabil oder von manuellen Eingriffen und dem Wissen einzelner Personen abhängig.
  • Deployment und Recovery unterscheiden sich je nach Umgebung oder lassen sich nicht zuverlässig wiederholen.
  • Eine Entscheidung über Stabilisierung, Modernisierung oder Neuentwicklung steht an, aber die technische Grundlage für eine Priorisierung fehlt.

Daten und Voraussetzungen

  • Geschäftliche Bedeutung, bekannte Auswirkungen eines Ausfalls und die Systemgrenze der Untersuchung.
  • Die vereinbarten Repositories mit relevanten Branches und Tags sowie ein Überblick über Komponenten, Schnittstellen und bekannte Abhängigkeiten.
  • Build- und CI-Konfigurationen, Test-Suites, vorhandene Qualitätsberichte und bekannte instabile Tests.
  • Release-Historie, Deployment- und Recovery-Abläufe sowie relevante Logs und Fehlerinformationen.
  • Technische und fachliche Ansprechpersonen sowie geklärte Regeln für Zugriff, Vertraulichkeit und Datenschutz. Produktionszugriff ist für das Code Forensic Assessment nicht erforderlich.

Vorgehen in Schritten

  1. Im Kickoff werden Analysefrage, Systemgrenze, bekannte Probleme, Release-Historie, Zugänge und erwartete Ergebnisse abgestimmt.
  2. Ein Erstbefund ordnet Architektur, Abhängigkeiten, Repositories, Tests, Build und Deployment ein. Er markiert Auffälligkeiten und Datenlücken, ohne daraus vorschnell Ursachen abzuleiten.
  3. Die vertiefte Analyse verbindet Git-Historie, Code- und Fehler-Metriken mit Tests, Build- und CI-Daten sowie bekannten Release-Ereignissen. Soweit die Daten es tragen, werden Muster konkreten Komponenten und Abläufen zugeordnet.
  4. Jeder Punkt wird als belegter Befund, technisches Risiko, Hypothese oder offene Frage mit notwendiger Folgeuntersuchung eingeordnet. Architekturwissen, Betriebsabläufe und Gespräche mit dem Team liefern den Kontext.
  5. Bericht und Verbesserungs-Roadmap ordnen die Punkte nach Bedeutung und nächstem Schritt. Im Review-Termin werden Begründungen, Grenzen und offene Entscheidungen erläutert.

Ergebnis der Analyse

  • Ein verständliches Bild von Systemgrenze, Architektur, technischen Abhängigkeiten und bekannten Wissenslücken.
  • Eine priorisierte Risiko- und Untersuchungsliste, die belegte Befunde von Punkten mit notwendiger Folgeuntersuchung trennt.
  • Ein Bericht, ein Review-Termin und eine Verbesserungs-Roadmap mit begründeten nächsten Schritten.
  • Eine belastbare Grundlage für Budget-, Stabilisierungs- und Modernisierungsentscheidungen innerhalb des untersuchten Umfangs.

Grenzen und Abgrenzung

  • Eine allgemeine Analyse der gesamten IT-Landschaft kann mehrere Fachrichtungen erfordern. Das Angebot von Oliver Fries ist auf gewachsene, geschäftskritische Systeme im .NET-Ökosystem ausgerichtet.
  • Ein Erstbefund beantwortet nicht automatisch jede Ursachenfrage. Einzelne Risiken können eine gesondert abgegrenzte, vertiefte Code- oder Laufzeitanalyse erfordern.
  • Git-Muster, Metriken, Testabdeckung und Werkzeugbefunde sind Hinweise. Eine Ursachenbewertung braucht Architektur-, Betriebs- und Teamkontext.
  • Die Umsetzung der Maßnahmen ist nicht Teil des Code Forensic Assessment. Sie kann als separates Stabilisierungsprojekt folgen.
  • Die Analyse garantiert keine bestimmte technische oder wirtschaftliche Wirkung späterer Maßnahmen. Diese Wirkung lässt sich erst an der Umsetzung und an vorher vereinbarten Kriterien prüfen.

Prüffragen

  • Die Entscheidung, die durch die Analyse vorbereitet werden soll, ist klar benannt.
  • Systemgrenze, Repositories, relevante Datenquellen und nicht geprüfte Bereiche sind abgegrenzt.
  • Der Anbieter besitzt Erfahrung mit dem verwendeten Technologiestack und gewachsener Bestandssoftware.
  • Architektur, Abhängigkeiten, Git-Historie, Tests, Build, Deployment, Recovery und Release-Risiken sind im Vorgehen berücksichtigt.
  • Belegte Befunde, technische Risiken, Hypothesen und notwendige Folgeuntersuchungen werden getrennt ausgewiesen.
  • Benötigte Zugänge, Daten, Ansprechpersonen und Schutzvorgaben sind vor dem Start geklärt.
  • Bericht, Review, priorisierte Roadmap und Entscheidungsfragen sind als Ergebnisse vereinbart.
  • Analyse, mögliche Folgeuntersuchung und spätere Umsetzung sind als getrennte Leistungsabschnitte erkennbar.

Quellen und Einordnung

Die Quellen stützen die technische Einordnung oder beschreiben den Umfang einer verknüpften Leistung. Projektergebnisse und Modellannahmen sind keine allgemeine Wirkungszusage.