Engineering-Erfahrung und Arbeitsweise
Mein fachlicher Hintergrund umfasst mehr als 20 Jahre Engineering-Erfahrung in Software Engineering, Embedded Systems, Linux, Platform Security und Systems Architecture. In den letzten Jahren sind technische Guidance, Engineering Enablement und Wissenstransfer stärker Teil meiner Verantwortung geworden. Entscheidend ist nicht ein bestimmtes Tool oder eine einzelne Technologie, sondern eine Denkweise: komplexe technische Landschaften verstehen, wiederkehrende Engineering-Muster erkennen und daraus wiederverwendbare Strukturen ableiten, die Entwicklungsteams im Alltag entlasten.
Softwareentwicklung, Embedded-Plattformen, Security-Architekturen und lokale Systeme für AI-Assisted Engineering sind unterschiedliche Arbeitsfelder. In der praktischen Architekturarbeit tauchen jedoch ähnliche technische Aufgaben wieder auf: Abstraktion, klare Systemgrenzen, Schutz kritischer Informationen, wiederverwendbare Plattformstrukturen und Architektur, die Teams klare Systemgrenzen, nutzbare Plattformfähigkeiten und nachvollziehbare Entscheidungsgrundlagen gibt.
Meine Beratungs- und technischen Arbeitsformate entstehen aus konkreten Engineering-Fragestellungen und verbinden Analyse, Architekturarbeit, technische Moderation und dokumentierte Entscheidungsgrundlagen.
Die Architekturarbeit baut auf langjähriger Hands-on-Softwareentwicklung und technischer Implementierung auf. Der heutige Schwerpunkt liegt jedoch auf Analyse, Architektur, technischer Koordination und Engineering Enablement.
Warum Systems Thinking zählt
In großen Softwarelandschaften liegt die Schwierigkeit selten in einem einzelnen Modul. Die eigentliche Schwierigkeit liegt in den Beziehungen: Abhängigkeiten, Datenflüsse, implizite Annahmen, historische Entscheidungen, Sicherheitsgrenzen und unterschiedliche Arbeitsweisen mehrerer Teams.
Meine Stärke liegt darin, diese Beziehungen zu erkennen und in tragfähige Muster zu übersetzen: Plattformstrukturen, Schnittstellen, Guardrails, Review-Punkte und nachvollziehbare Entscheidungen. Engineering-Dokumentation, Implementierungskonzepte, Architektur-Guidance, Plattformstrukturen und Review-Konzepte werden dadurch Teil der technischen Lösung selbst, nicht nachgelagerte Prozessvorgaben.
Das gilt besonders für technische Querschnittsthemen, die tief in bestehende Systeme und Entwicklungsabläufe eingreifen. Security und AI werden schwer beherrschbar, wenn sie erst nachträglich als zusätzliche Schicht auf eine bestehende Architektur gesetzt werden. Beides funktioniert besser, wenn es in die Architektur eingebettet ist und Entwickler im Alltag automatisch in die richtige Richtung führt.
Erfahrung unter realen Randbedingungen
Meine Erfahrung kommt aus Engineering-Umgebungen, in denen Architektur nicht nur sauber aussehen muss, sondern unter Einschränkungen funktionieren muss: Embedded Systems, Automotive, Linux, C/C++, HSM, Kryptografie, Security by Design und regulierte Entwicklungsumfelder.
Die langjährige Erfahrung mit Systems Architecture, Product Security, Security by Design, Embedded Systems und regulatorisch geprägten Entwicklungsumgebungen bildet die Grundlage, neue regulatorische Anforderungen technisch einzuordnen und in umsetzbare Architektur- und Engineering-Entscheidungen zu überführen. Die Kompetenz liegt an der Schnittstelle zwischen Systemarchitektur, Software, Embedded Systems, Security und Engineering-Organisation, nicht in juristischer Beratung.
In solchen Umgebungen werden schlechte Abstraktionen teuer. Gute Muster reduzieren Integrationsaufwand, machen Systeme verständlicher und erlauben Teams, sichere Entscheidungen wiederholbar zu treffen. Ein Beispiel dafür ist die Reduktion des Integrationsaufwands um etwa 75 Prozent durch eine gemeinsam genutzte Embedded-Security-Plattform.
Nachweisbare Wirkung
Beispiele für diese Arbeitsweise sind wiederverwendbare Plattformstrukturen, die Ausbildung von etwa 15 Ingenieuren über fünf Jahre hinweg durch dokumentierte technische Guidance und Wissenssicherung sowie etwa 75 Prozent geringerer Integrationsaufwand in einem Embedded-Security-Kontext. Die anonymisierten Beispiele sind im Portfolio zusammengefasst.
Wie ich arbeite
Analytisch
Ich beginne mit System, Kontext, Abhängigkeiten, Risiken und wiederkehrenden Mustern, nicht mit einem Tool.
Architektonisch
Ich suche nach Strukturen, die Komplexität reduzieren, Wiederverwendung ermöglichen, Weiterentwicklung erleichtern und Entscheidungen nachvollziehbar machen.
Sicherheitsbewusst
Security, Datenschutz, Quellcode-Schutz und Betriebsmodell werden nicht nachträglich ergänzt, sondern als Teil der Architektur behandelt.
Befähigend
Ziel ist, Teams durch wiederverwendbare Engineering-Strukturen, Guardrails und verständliche Architektur selbstständiger zu machen.
Arbeit mit vertraulichen Engineering-Inhalten
In Assessments, Architecture Reviews und technischer Zusammenarbeit werden häufig vertrauliche Engineering-Themen sichtbar: Architekturentscheidungen, Quellcode, interne Dokumentation, technische Schulden, Sicherheitsfragen, Prozessbrüche und organisatorische Reibung. Damit muss sorgfältig, diskret und technisch sauber gearbeitet werden.
Meine Rolle ist deshalb nicht, Teams mit KI-Demos zu beeindrucken. Ich arbeite mit Blick auf Systemzusammenhänge, technische Verantwortung, Security by Design, Nachvollziehbarkeit und die Frage, ob eine Struktur im realen Engineering-Alltag trägt.
Unternehmen können erwarten, dass kritische Themen nicht vereinfacht oder übergangen werden. Wenn KI sinnvoll ist, wird sie strukturiert eingeordnet. Wenn Risiken, fehlende Voraussetzungen oder ungeeignete Anwendungsfälle sichtbar werden, werden sie klar benannt.
Warum ich heute AI-Assisted Engineering begleite
Mich interessiert nicht KI als Selbstzweck. Mich interessiert die Frage, wie Engineering-Teams Wissen besser nutzbar machen, komplexe Systeme schneller verstehen und sichere Entscheidungen wiederholbarer treffen können.
Lokale Large Language Models (LLMs), RAG (Retrieval-Augmented Generation), AI Agents und AI-Assisted Engineering können dabei helfen. Aber nur, wenn sie architektonisch geführt werden: mit klaren Datenflüssen, Zugriffsschutz, Review, Security by Design und einem realistischen Verständnis dafür, welche Entscheidungen weiterhin beim Menschen bleiben.
AI-Assisted Engineering wende ich deshalb mit denselben Architektur- und Security-Prinzipien an wie andere komplexe Engineering-Systeme.