Strukturelle Prüfparameter

3×

Skalierungsreserve über aktuelle Spitzenlast

99,9%+

Nachgewiesene Systemverfügbarkeit pro Quartal

<60 Min.

MTTR bei kritischen
Vorfällen

>85%

Testabdeckung in sicherheitsrelevanten Komponenten

Was wir tun

Technische Prüfung erfolgt als strukturierte Systemanalyse entlang klar definierter Ebenen.

Wir:

bewerten die systemische Rolle der Technologie innerhalb kritischer Infrastrukturen und identifizieren Ausfallfolgen
analysieren die Architektur über physische, Daten-, Verarbeitungs-, Kontroll-, Schnittstellen- und Observability-Schichten
prüfen Skalierbarkeit und Resilienz durch Lastszenarien, Failover-Fähigkeit und Chaos-Testing-Historie
validieren Security-by-Design entlang von Identität, Netzwerksegmentierung, Daten- und Lieferkettenschutz
untersuchen Betriebsprozesse, Incident-Management, Change-Disziplin und SRE-Metriken
bewerten Teamstruktur, Prozessreife und Dokumentationsgrad als Voraussetzung nachhaltiger Systemstabilität

Ziel ist die Bestätigung, dass das System seine strukturelle Funktion unter Last erfüllen kann.

Strukturelles Ergebnis

Belastbare Systemarchitektur

Tragfähige, mehrschichtige Architektur mit Skalierungsreserve

Nachgewiesene Resilienz

Failover-Fähigkeit, kurze Wiederherstellungszeiten und DR-Validierung

Regulatorisch kompatible Sicherheit

Auditierbare Sicherheits- und Compliance-Architektur

Operative
Kontinuität

Reife Prozesse, stabile SRE-Metriken und teamseitige Ausführungskraft

Makrokontext – Technologie als Infrastruktur

Fortgeschrittene Systeme operieren an der Schnittstelle von Technologie und Infrastruktur.

Die strukturelle Perspektive:

Moderne Volkswirtschaften sind auf Technologien angewiesen, die auch dann funktionieren, wenn normale Rahmenbedingungen versagen:

Netzstabilität bei Spitzenlast oder Angriff.
Kommunikationskontinuität bei Ausfällen oder Störungen.
Prozesssteuerung, wenn menschliches Eingreifen nicht möglich ist.

Perimetersicherheit unter koordinierten Bedrohungsszenarien.
Datensysteme, die ihre Integrität trotz Kompromittierungsversuchen bewahren.

Die technische Due Diligence beginnt mit der Position des Systems innerhalb dieser Architektur:

Welche kritische Funktion erfüllt es?
Welche Abhängigkeiten erzeugt oder löst es?
Was sind die realistischen Ausfallmodi und deren Konsequenzen?
Wie integriert es sich in benachbarte Systeme, die ebenfalls funktionsfähig bleiben müssen?

Eine Technologiebewertung ist bedeutungslos ohne das Verständnis der strukturellen Rolle des Systems.
Ein brillanter Algorithmus, der eine Spannungsschwankung nicht übersteht, versagt in der Praxis.

Diligence-Prozess – strukturiert und reproduzierbar

Phase 1: Kontextuelle Einordnung (1–2 Tage)

Klärung der Systemrolle gemeinsam mit der technischen Leitung.
Anforderung von Architekturdiagrammen, Sequenzdiagrammen und Datenflussanalysen.
Überprüfung des Bedrohungsmodells, der Kapazitätsplanung und der Incident-Historie.

Phase 2: Vertiefte technische Prüfung (3–5 Tage)

Stichprobenanalyse der Codebasis (10–20 % des kritischen Pfads).
Audit der Infrastrukturkonfiguration.
Prüfung der Sicherheits- und Compliance-Dokumentation.
Validierung der Ergebnisse von Lasttests und Chaos-Engineering.

Phase 3: Operative Bewertung (2–3 Tage)

Begehung der Entwicklungsumgebung.
Demonstration der Deployment- und Delivery-Pipelines.
Fachliche Durchsprache von Incident-Response-Szenarien.
Analyse von Teamstruktur und Kompetenzprofilen.

Phase 4: Synthese und Risikobewertung (1–2 Tage)

Konsolidierung der Erkenntnisse über fünf Analyseebenen hinweg.
Kategorisierung der Risiken: kurzfristig, mittelfristig, langfristig.
Maßnahmen-Roadmap mit Verantwortlichkeiten und Zeitachsen.

Ergebnisdokument:
Bericht im Umfang von 15–25 Seiten mit Executive Summary, technischen Befunden, Risikomatrix und Maßnahmenplan.

Bewertungsrahmen – fünf Analyseebenen

Die technische Due Diligence folgt einem konsistenten Rahmen entlang von fünf Ebenen:

Architektonische Integrität
Skalierbarkeit und Resilienz
Sicherheit und Härtung

Integrations- und Abhängigkeitsmanagement
Operative Nachhaltigkeit

Jede Ebene ist mit den anderen verbunden. Defizite in einer Ebene erzeugen Risiken, die sich systemweit fortpflanzen.

1. Architektonische Integrität

Die Architektur entscheidet darüber, ob ein System seine strukturelle Funktion erfüllen kann.

Zentrale Fragestellungen:

Ist das System für seine reale Betriebsumgebung ausgelegt und nicht für theoretische Idealannahmen?
Trennt die Architektur Verantwortlichkeiten angemessen – Control Plane von Data Plane, Sicherheit von Funktionalität, Monitoring von Betrieb?
Sind Ausfalldomänen klar definiert und isoliert?
Berücksichtigt das Design realistische regulatorische und Audit-Anforderungen?

Bewertungskriterien:

Modularität und Kohäsion

Komponenten besitzen eindeutige, klar abgegrenzte Verantwortlichkeiten.
Schnittstellen sind stabil, versioniert und gut dokumentiert.
Änderungen in einem Modul erzeugen minimale Kaskadeneffekte.

Zustandsmanagement

Kritische Zustände sind dauerhaft, repliziert und wiederherstellbar.
Verteilte Konsensmechanismen sind erprobt und nicht experimentell.
Datenflüsse behalten ihre Integrität auch in Fehlerszenarien.

Observability by Design

Metriken, Logs und Traces werden ohne signifikante Performance-Einbußen erzeugt.
Interne Zustände sind über Instrumentierung rekonstruierbar.
Anomalien werden vor Nutzerbeeinträchtigungen erkannt.

Schwache Architektur zeigt sich durch:

Enge Kopplung, die Skalierung oder Upgrades verhindert.
Versteckte Zustände mit unvorhersehbarem Verhalten nach Neustarts.
Monitoring-Lücken, die die Incident-Erkennung verzögern.

2. Skalierbarkeit und Resilienz

Systemkritische Technologie muss Schocks absorbieren, nicht verstärken.

Kapazitätsbewertung:

Aktuelle Auslastung im Verhältnis zu realistischen Lastspitzen.
Validierte vertikale und horizontale Skalierungspfade.
Datenbankkapazität für ein Wachstum um das 3- bis 5-Fache ohne Neudesign.

Resilienz-Muster:

Zustandslose Komponenten, wo immer praktikabel.
Circuit Breaker, Timeouts, Retries mit exponentiellem Backoff.
Definierte und getestete Graceful-Degradation-Pfade.
Dokumentierte Chaos-Engineering-Übungen.

Speicherung und Persistenz:

Replikation kritischer Daten über mindestens drei Availability Zones.
Validierte Backups, nicht nur Backup-Erstellung.
Disaster-Recovery-RTO entspricht den Geschäftsanforderungen.

Validierung von Skalierungsannahmen durch:

Lasttestergebnisse unter realistischen Szenarien.
Post-Mortem-Analysen mit dokumentierten Wiederherstellungszeiten.
Kapazitätsplanung inklusive regulatorischer Reporting-Lasten.

3. Sicherheit und Härtung

Sicherheit ist kein Feature, sondern eine architektonische Randbedingung.

Vollständigkeit des Bedrohungsmodells:

Realistische Angreiferprofile (Insider, staatliche Akteure, Commodity-Kriminalität).
Vollständiges und aktuelles Angriffsfächen-Inventar.
Zero-Trust-Prinzip auf Netzwerk-, Applikations- und Datenebene.

Implementierungsprüfung:

Geheimnismanagement ohne Hardcoding, automatisierte Rotation.
Netzwerksegmentierung mit kontrolliertem Ost-West-Traffic und Mikrosegmentierung.
Software-Zusammensetzung mit gepflegtem SBOM und fristgerechtem Patch-Management.

Regulatorische Ausrichtung:

Datenresidenzanforderungen architektonisch erfüllt.
Umfassende, manipulationssichere und exportierbare Audit-Logs.
Glaubwürdige Zertifizierungs-Roadmaps mit Ressourcenplanung.

Warnsignale:

Sicherheit als nachträgliches Add-on statt als native Kontrolle.
Ungepatchte CVEs in produktiven Komponenten.
Fehlende Penetrationstests oder Red-Team-Nachweise.

4. Integrations- und Abhängigkeitsmanagement

Kein System operiert isoliert.
Die Due Diligence umfasst Schnittstellen und Lieferketten.

Integrationsbewertung:

APIs mit vollständigen, versionierten und überwachten OpenAPI/Swagger-Spezifikationen.
Datenverträge mit validierten Schemata und kontrollierter Deprecation von Breaking Changes.
Service-zu-Service-Authentifizierung über mTLS oder gleichwertige Verfahren.

Abhängigkeitsanalyse:

Open Source: Lizenzkonformität geprüft, Schwachstellen gescannt.
Kommerzielle Komponenten: EOL-Termine kartiert, Migrationspläne vorhanden.
Cloud-Provider: Multi-Cloud-Strategie oder fundierte Lock-in-Begründung.

Lieferantenrisiko:

Kritische Anbieter hinsichtlich finanzieller Stabilität und Sicherheitsniveau bewertet.
Single Points of Failure identifiziert und mitigiert.
Vertragsbedingungen entsprechen operativen SLAs.

Typische Befunde:

Verdeckte Kopplung über gemeinsame Datenbanken oder Message Broker.
Unkontrollierte technische Schulden in Adaptern und Protokoll-Übersetzern.
Lieferketten-Schwachstellen mit operativen Auswirkungen.

5. Operative Nachhaltigkeit

Technologie muss von realistischen Teams über realistische Zeithorizonte betreibbar sein.Entwicklungspraktiken:

Entwicklungspraktiken:

Vollständige CI/CD-Pipelines: Build, Test, Deploy, Rollback.
Testpyramide: >70 % Unit-Tests, ~20 % Integrations-Tests, ~10 % End-to-End.
Infrastructure as Code: deklarativ, versioniert, peer-reviewt.

Teamfähigkeit:

Kognitive Last wird gemessen und aktiv gesteuert.
Dokumentation deckt Deployment, Skalierung und Recovery ab.
Nachhaltige On-Call-Modelle mit dokumentierter Incident-Response.

Management technischer Schulden:

Geführtes und priorisiertes Debt-Register.
Refactoring als fester Anteil der Sprint-Kapazität.
Gepflegte Architecture Decision Records (ADRs).

Nachhaltigkeit scheitert, wenn:

Schlüsselwissen bei einzelnen „Hero-Developern“ konzentriert ist.
Deployments auf implizitem, nicht dokumentiertem Wissen beruhen.
Incidents fehlende Instrumentierung oder Runbooks offenlegen.

Entscheidungsrahmen

Grün: Fortfahren

Die Architektur unterstützt ein dreifaches Wachstum ohne grundlegende Neuentwicklung.
Das Sicherheitsniveau entspricht den regulatorischen Anforderungen.
Der Betrieb ist durch generalistische Teams nachhaltig gewährleistet.
Die Dokumentation ermöglicht effektiven Wissenstransfer.

Gelb: Absichern / Mitigieren

Bekannte technische Schulden mit klarem Maßnahmenplan zur Behebung.
Skalierungsgrenzen, die innerhalb von 6–12 Monaten adressiert werden können.
Sicherheitslücken mit Hersteller-/Anbieterunterstützung während der Übergangsphase.
Teamlücken, die innerhalb des operativen Budgets rekrutierbar sind.

Rot: Abstand nehmen

Grundlegende architektonische Fehlanpassung an die Anforderungen.
Nicht behebbare Sicherheits- oder Compliance-Defizite.
Operative Fragilität mit kritischen Single Points of Failure.
Kein realistischer Weg zu nachhaltigem Betrieb innerhalb angemessener Zeiträume.

Post-Investment-Begleitung

Die technische Due Diligence geht in eine aktive Unterstützungsphase über:

Vierteljährliche Architektur-Reviews

Validierung des Fortschritts gegenüber der Sanierungs-Roadmap.
Bewertung neuer Initiativen im Einklang mit den Architekturprinzipien.
Abstimmung der Kapazitätsplanung mit den Wachstumsprognosen.

Technische Beratung

Definition von Standards für neue Komponenten.
Kriterien zur Anbieterauswahl für technologie-kritische Pfade.
Ausrichtung der regulatorischen Technologieanforderungen.

Talentarchitektur

Bewertung und Entwicklung der Engineering-Führung.
Analyse von Kompetenzlücken im Verhältnis zur Skalierungs-Roadmap.
Vergütungs-Benchmarking für Schlüsselrollen.

Die strukturelle Quintessenz

Technologische Due Diligence bestätigt eine grundlegende Frage:

Kann dieses System seine strukturelle Verantwortung tragen?

Komponenten versagen.
Integration bricht.
Teams verändern sich.
Regulatorische Rahmenbedingungen entwickeln sich weiter.

Das System, das Bestand hat:
– antizipiert Ausfallmodi durch seine Architektur.
– absorbiert Schocks durch Resilienzmechanismen.
– wahrt Integrität durch konsequente Sicherheitsdisziplin.
– passt sich durch operative Nachhaltigkeit an.

So unterstützt die Technologiebewertung die langfristige Positionierung in systemkritischen Branchen.

Die Skalierung komplexer Technologien von Pilotprojekten zur Infrastruktur wird auch im Beitrag zu Robotics und Autonomous Systems – von Piloten zur Infrastruktur erläutert.

Technische Bewertungsstandards für komplexe Systeme werden unter anderem vom VDI – Verein Deutscher Ingenieure entwickelt.

Wie gesehen

Fokus

Unbemannte Luft-, See- und Bodensysteme, autonome Plattformen, KI-gestützte Sensorik und Bildintelligenz sowie sichere cyber-physische Systemarchitekturen.