Die eigentliche Leistung: klare Grundlagen für technische Entscheidungen schaffen
In vielen Engineering-Teams und technischen Fachbereichen ist das Problem nicht fehlende Technologie. Das Problem ist strukturelle Unklarheit: gewachsene Plattformen, implizites Wissen, uneinheitliche Schnittstellen, Sicherheitsanforderungen, Legacy-Code und ähnliche technische Probleme, die in verschiedenen Projekten oder Teams unterschiedlich gelöst werden.
Meine Arbeit beginnt dort, wo Systemzusammenhänge unklar und technische Entscheidungen schwierig werden. Ich analysiere Systeme nicht nur entlang einzelner Komponenten, sondern entlang wiederkehrender Muster: Datenflüsse, Verantwortlichkeiten, Kopplungen, Sicherheitsgrenzen, Wartbarkeit und operative Randbedingungen.
Das Ziel ist nicht eine abstrakte Zielarchitektur auf Folien. Das Ziel ist eine Struktur, die Engineering-Teams in ihrer täglichen Arbeit nutzen können: verständlicher, sicherer, leichter weiterentwickelbar und mit weniger unnötiger Komplexität.
Der Wert der Leistung zeigt sich darin, dass technische Entscheidungen nachvollziehbar werden, Risiken früher sichtbar sind und Kundenteams mit den Ergebnissen selbstständig weiterarbeiten können.
Architecture Assessments und erste Mandate
Komplexe technische Entscheidungen brauchen mehr als zusätzliche Engineering-Kapazität. Der Einstieg muss dabei nicht groß sein: Häufig reicht ein klar begrenztes Assessment, um Architektur, technische Risiken und Handlungsoptionen strukturiert zu bewerten und die nächsten Entscheidungen vorzubereiten.
Ein Assessment umfasst typischerweise die Analyse der Ausgangslage, technische Reviews und Interviews, eine nachvollziehbare Bewertung, empfohlene Architekturentscheidungen und eine priorisierte Roadmap.
Architecture Assessment
Für gewachsene Systeme, Plattformen oder Integrationslandschaften, deren Struktur unklar geworden ist. Ergebnis nach typischerweise 2 bis 6 Wochen: technisches Lagebild, zentrale Abhängigkeiten, Risiken, Entscheidungsoptionen und empfohlene nächste Schritte.
Security Architecture Review
Für Plattformen, Embedded-Systeme oder Security-relevante Systemgrenzen, bei denen Schutzgrenzen, HSM-Integration, Security-Services oder Product-Security-Anforderungen geklärt werden müssen. Ergebnis: bewertete Security-Grenzen, Architektur-Risiken, Integrationsoptionen und konkrete technische Empfehlungen.
AI Engineering Readiness Review
Für Teams, die AI-Assisted Engineering, lokale LLMs, RAG oder Agents einsetzen wollen, ohne vertraulichen Quellcode, internes Wissen oder Review-Verantwortung unkontrolliert zu öffnen. Ergebnis: bewertete Use Cases, Datenflüsse, Schutzbedarf, Betriebsoptionen und ein risikoarmer Einstiegspfad.
Architecture Work Package
Für Fragestellungen, die über eine Bewertung hinausgehen: ein mehrwöchiges, klar abgegrenztes Arbeitspaket mit Zielarchitektur, bewerteten Entscheidungsalternativen und strukturierter Übergabe an das Engineering-Team.
Der Wert eines solchen Einstiegs liegt darin, dass Umfang, Risiken und Folgeschritte sichtbar werden, bevor größere Architektur- oder Implementierungsentscheidungen getroffen werden.
Welche Engineering-Probleme ich löse
Systems Architecture & Complexity Reduction
Analyse komplexer Softwarelandschaften, Legacy-Systeme und Plattformen. Wiederkehrende Muster sichtbar machen, Kopplung reduzieren, tragfähige Plattformdesigns entwickeln und technische Entscheidungen so strukturieren, dass Teams nicht dauerhaft gegen die Architektur arbeiten müssen. Die Details sind auf der Seite Systems Architecture beschrieben.
Platform Security & Security by Design
Security dort verankern, wo technische Architektur entsteht: Schutzgrenzen, gemeinsam nutzbare Security-Services, HSM-Integration, Plattformentscheidungen und Integrationsguidance. Regulatorische Rahmenbedingungen wie Cyber Resilience Act (CRA) oder NIS2 werden dabei technisch eingeordnet, soweit sie Architektur, Product Security, Security by Design, technische Dokumentation oder Lifecycle-Anforderungen betreffen. Der Fokus liegt auf Engineering-Architektur, nicht auf Compliance, GRC oder Pentesting. Die Details sind auf der Seite Platform Security beschrieben.
AI-Assisted Engineering als unterstützende Methodik
Wenn AI-Assisted Engineering sinnvoll ist, geht es um sichere Grundlagen: lokale Ausführung, Retrieval-Augmented Generation (RAG) und kontrollierte Agent-Workflows. Dazu gehören Zugriffsschutz, Schutz vertraulichen Quellcodes, Review-Prozesse und Architektur-Grenzen. KI wird dabei als technisches Subsystem betrachtet, nicht als isoliertes Werkzeug. Der EU AI Act wird als technischer Rahmen berücksichtigt: nicht als Rechtsberatung oder Konformitätsbewertung, sondern für Architekturfragen wie Datenflüsse, Zugriffsschutz, Nachvollziehbarkeit, Review-Regeln und verantwortbare Nutzung. Die Details sind auf der Seite AI-Assisted Engineering beschrieben.
Engineering Enablement als Arbeitsweise
Engineering Enablement ist technische Befähigung, kein HR-Thema. Architekturarbeit wird wirksam, wenn Implementierungskonzepte, Engineering-Dokumentation, technische Leitlinien, Review-Strukturen und wiederverwendbares Engineering-Wissen so aufbereitet sind, dass Teams Plattformfähigkeiten selbstständig nutzen und konsistente Entscheidungen treffen können. Architektur- und Security-Arbeit endet nicht mit Review oder Konzept: Entscheidungen werden nachvollziehbar dokumentiert, Wissen wird vermittelt und Teams werden befähigt, Architektur-, Security- und regulatorisch getriebene technische Anforderungen selbstständig umzusetzen. Konkrete Formen sind strukturierte Einarbeitungspfade, Wiki- und How-to-Wissen, technische Videos, Implementierungskonzepte, Security-Engineering-Transparenzformate sowie Review- und Guidance-Strukturen.
Praxisbeleg: lokales Engineering-Wissenssystem
Ein konkretes Beispiel ist eine vollständig lokal betriebene Wissenslösung, die aus der Praxis heraus konzipiert, umgesetzt und über mehrere Iterationen hinweg im realen Engineering-Einsatz weiterentwickelt wurde. Der Zweck war nicht, moderne KI auszuprobieren. Der Zweck war, vorhandenes Engineering-Wissen in großen Softwarelandschaften sicher nutzbar zu machen. Die eingesetzte KI war Werkzeug; der eigentliche Wert lag in Systems Architecture, Security, strukturierter Organisation von Engineering-Wissen und Engineering Enablement.
Weil vertraulicher Quellcode und internes Wissen betroffen waren, mussten lokale Verarbeitung, Schutz vor unkontrolliertem Datenabfluss, Zugriffsschutz, Nachvollziehbarkeit und Security by Design Teil der Architektur sein. Das ist der Unterschied zwischen einer KI-Demo und einer tragfähigen Engineering-Lösung.
Anonymisierte Beispiele
Anonymisierte Beispiele für diese Arbeitsweise finden Sie im Portfolio.
Wie eine Zusammenarbeit typischerweise beginnt
Ich starte nicht mit einem Tool oder einer vorgegebenen Methode, sondern mit der konkreten technischen Ausgangslage: Problem, Kontext, vorhandene Architektur, technische Risiken, Sicherheitsgrenzen, vorhandenes technisches Wissen, bestehende Plattformfähigkeiten und technische Verantwortlichkeiten.
Analyse
Welche Strukturen existieren tatsächlich? Wo entstehen Komplexität, Risiken, Integrationsaufwand oder Wissensverluste? Welche Muster wiederholen sich?
Architektur
Welche Zielstruktur reduziert Komplexität, schützt kritische Daten und erleichtert Weiterentwicklung? Welche Guardrails brauchen Teams, damit sichere Entscheidungen leichter werden?
Enablement
Welche technischen Leitlinien, Reviews, Regeln und Arbeitsweisen helfen Teams, die neue Struktur selbstständig anzuwenden? Wie wird Wissen dauerhaft zugänglich, statt erneut in einzelnen Köpfen oder Tool-Silos zu verschwinden?
Typische Ergebnisse
Das Ergebnis ist nicht eine einzelne Präsentation oder ein fertiges Tool-Versprechen. Je nach Ausgangslage entsteht eine belastbarere Grundlage für technische Entscheidungen.
- Klarere Architektur in gewachsenen oder unübersichtlichen Systemen
- Reduzierter Integrationsaufwand durch konsistente Integrationsansätze
- Kontrollierte lokale Wissenssysteme mit lokalen Modellen, Retrieval-Augmented Generation, Agent-Workflows und nachvollziehbaren Datenflüssen
- Klarere Entscheidungsgrundlagen sowie nachvollziehbare technische Entscheidungen und Review-Strukturen
- Besser zugängliches Engineering-Wissen für bestehende und neue Teams, inklusive Onboarding-Pfaden und technischer Guidance
- Guardrails, die sichere und sinnvolle Entscheidungen im Alltag erleichtern
Die passende Form ergibt sich aus dem System
Manche technischen Organisationen benötigen zunächst ein Assessment, ein Architecture Review oder eine Discovery Session, um Architektur, Security, Engineering-Wissen und Verantwortlichkeiten an einer konkreten Fragestellung zusammenzuführen. Daraus entsteht kein eigenständiges Produkt, sondern der passende Einstieg in ein Beratungsmandat, Architecture Review oder konkrete Architekturarbeit.
Entscheidend ist der konkrete Kontext: bestehende Software, regulatorische Anforderungen, Sicherheitsgrenzen, technische Rollen, vorhandenes Engineering-Wissen und die Frage, welche Komplexität wirklich reduziert werden muss.