Engineering experience and way of working
My background includes more than 20 years of engineering experience in software engineering, embedded systems, Linux, platform security and systems architecture. In recent years, technical guidance, engineering enablement and knowledge transfer have become a stronger part of my responsibilities. What matters is not a specific tool or a single technology, but a way of thinking: understand complex technical landscapes, recognize recurring engineering patterns and derive reusable structures that make engineering teams more effective in daily work.
Software development, embedded platforms, security architectures and local AI-assisted engineering systems are different fields of work. In practical architecture work, however, similar technical tasks keep appearing: abstraction, clear system boundaries, protection of critical information, reusable platform structures and architecture that gives teams clear system boundaries, usable platform capabilities and traceable decision foundations.
My consulting and technical working formats originate from concrete engineering questions and combine analysis, architecture work, technical facilitation and documented decision support.
The architecture work builds on long-standing hands-on software development and technical implementation experience. The current focus, however, is analysis, architecture, technical coordination and engineering enablement.
Why systems thinking matters
In large software landscapes, the difficulty rarely sits inside one module. The real difficulty is in the relationships: dependencies, data flows, implicit assumptions, historical decisions, security boundaries and different ways of working across multiple teams.
My strength is recognizing these relationships and translating them into durable patterns: platform structures, interfaces, guardrails, review points and traceable decisions. Engineering documentation, implementation concepts, architectural guidance, platform structures and review concepts therefore become part of the technical solution itself, rather than being added later as separate process requirements.
This is especially relevant for technical cross-cutting topics that reach deeply into existing systems and development workflows. Security and AI become difficult to manage when they are added later as another layer on top of an existing architecture. Both work better when embedded in the architecture and when they guide developers in the right direction during daily work.
Experience under real constraints
My experience comes from engineering environments where architecture has to do more than look clean. It has to work under constraints: embedded systems, automotive, Linux, C/C++, HSM, cryptography, security by design and regulated development environments.
Long-standing experience with Systems Architecture, Product Security, Security by Design, embedded systems and regulated development environments provides the foundation for interpreting new regulatory requirements technically and translating them into actionable architecture and engineering decisions. The competence sits at the intersection of system architecture, software, embedded systems, security and engineering organization, not in legal advisory work.
In such environments, poor abstractions become expensive. Good patterns reduce integration effort, make systems easier to understand and support consistent secure decisions across teams. One example is reducing integration effort by approximately 75 percent through a shared embedded-security platform.
Demonstrable impact
Examples of this way of working include reusable platform structures, training around 15 engineers over five years through documented technical guidance and knowledge continuity, and approximately 75 percent lower integration effort in an embedded security context. The anonymized examples are summarized in the case studies.
How I work
Analytical
I start with the system, context, dependencies, risks and recurring patterns, not with a tool.
Architectural
I look for structures that reduce complexity, enable reuse, make further development easier and make decisions traceable.
Security-conscious
Security, privacy, source-code protection and operating models are treated as part of the architecture, not as later additions.
Enabling
The goal is to make teams more independent through reusable engineering structures, guardrails and understandable architecture.
Working with confidential engineering content
Assessments, architecture reviews and technical engagements often involve confidential engineering topics: architecture decisions, source code, internal documentation, technical debt, security questions, process breaks and organizational friction. This requires careful, discreet and technically precise work.
My role is not to impress teams with AI demos. I work with attention to system relationships, technical responsibility, security by design, traceability and whether a structure holds up in real engineering work.
Companies can expect critical topics not to be simplified away. If AI is useful, it is placed into a clear architecture. If risks, missing prerequisites or unsuitable use cases become visible, they are named clearly.
Why I now work on AI-assisted engineering
I am not interested in AI as an end in itself. I am interested in how engineering teams can make knowledge more usable, understand complex systems faster and make sound security decisions consistently.
Local Large Language Models (LLMs), RAG (Retrieval-Augmented Generation), AI agents and AI-assisted engineering can help with that. But only when they are architecturally guided: with clear data flows, access protection, review, security by design and a realistic understanding of which decisions remain with people.
I therefore apply AI-assisted engineering with the same architecture and security principles as other complex engineering systems.