The actual work: creating clear foundations for technical decisions
In many technical teams and engineering functions, the problem is not missing technology. The problem is structural ambiguity: grown platforms, implicit knowledge, inconsistent interfaces, security requirements, legacy code and similar technical problems being solved differently across projects or teams.
My work starts where system relationships are unclear and technical decisions become difficult. I do not analyze systems only along individual components, but along recurring patterns: data flows, responsibilities, coupling, security boundaries, maintainability and operational constraints.
The goal is not an abstract target architecture on slides. The goal is a structure that engineering teams can use in their daily work: easier to understand, safer, easier to evolve and with less unnecessary complexity.
The value of the work becomes visible when technical decisions are traceable, risks surface earlier and client teams can continue working independently with the results.
Architecture assessments and first engagements
Complex technical decisions need more than additional engineering capacity. The starting point does not need to be large: often, a clearly bounded assessment is enough to evaluate architecture, technical risks and options in a structured way and to prepare the next decisions.
An assessment typically covers an analysis of the current situation, technical reviews and interviews, a traceable evaluation, recommended architecture decisions and a prioritized roadmap.
Architecture Assessment
For grown systems, platforms or integration landscapes whose structure has become unclear. Typical outcome after 2 to 6 weeks: technical view of the situation, key dependencies, risks, decision options and recommended next steps.
Security Architecture Review
For platforms, embedded systems or security-relevant system boundaries where protection boundaries, HSM integration, security services or product-security requirements need to be clarified. Outcome: assessed security boundaries, architecture risks, integration options and concrete technical recommendations.
AI Engineering Readiness Review
For teams that want to use AI-assisted engineering, local LLMs, RAG or agents without exposing confidential source code, internal knowledge or review responsibilities in an uncontrolled way. Outcome: assessed use cases, data flows, protection needs, operating options and a low-risk entry path.
Architecture Work Package
For questions that go beyond an assessment: a clearly bounded work package over several weeks with a target architecture, evaluated decision alternatives and a structured handover to the engineering team.
The value of such an entry point is that scope, risks and follow-up steps become visible before larger architecture or implementation decisions are made.
Which engineering problems I solve
Systems Architecture & Complexity Reduction
Analyze complex software landscapes, legacy systems and platforms. Make recurring patterns visible, reduce coupling, develop platform structures that remain usable over time and structure technical decisions so teams do not have to work against the architecture. The details are described on the Systems Architecture page.
Platform Security & Security by Design
Embed security where technical architecture is created: protection boundaries, shared security services, HSM integration, platform decisions and integration guidance. Regulatory frameworks such as the Cyber Resilience Act (CRA) or NIS2 are interpreted technically where they affect architecture, Product Security, Security by Design, technical documentation or lifecycle requirements. The focus is engineering architecture, not compliance, GRC or pentesting. The details are described on the Platform Security page.
AI-assisted engineering as a supporting method
Where AI-assisted engineering is useful, the work is about secure foundations: local execution, Retrieval-Augmented Generation (RAG) and controlled agent workflows. This includes access protection, protection of confidential source code, review processes and architecture boundaries. AI is treated as a technical subsystem, not as an isolated tool. The EU AI Act is treated as technical context: not as legal advice or conformity assessment, but for architecture questions such as data flows, access control, traceability, review rules and responsible use. The details are described on the AI-Assisted Engineering page.
Engineering Enablement as a working method
Engineering Enablement is technical enablement, not HR work. Architecture work becomes effective when implementation concepts, engineering documentation, technical guidelines, review structures and reusable engineering knowledge are prepared so teams can use platform capabilities independently and make consistent decisions. Architecture and security work does not end with a review or concept: decisions are documented traceably, knowledge is transferred and teams are enabled to implement architecture, security and regulatory-driven technical requirements independently. Concrete forms include structured onboarding paths, wiki and how-to knowledge, technical videos, implementation concepts, security engineering transparency formats, and review and guidance structures.
Practical proof: local engineering knowledge system
One concrete example is a fully local knowledge solution that was designed from practical engineering needs, implemented and developed further through several iterations in real engineering use. The purpose was not to experiment with modern AI. The purpose was to make existing engineering knowledge in large software landscapes safely usable. The AI used was a tool; the real value was systems architecture, security, structured organization of engineering knowledge and engineering enablement.
Because confidential source code and internal knowledge were involved, local processing, safeguards against uncontrolled data leakage, access protection, traceability and security by design had to be part of the architecture. That is the difference between an AI demo and a durable engineering solution.
Anonymized examples
Anonymized examples of this way of working are available in the case studies.
How collaboration typically starts
I do not start with a tool or a predefined method. I start with the concrete technical situation: the problem, the context, the existing architecture, technical risks, security boundaries, existing technical knowledge, available platform capabilities and technical responsibilities.
Analysis
Which structures actually exist? Where do complexity, risk, integration effort or knowledge loss appear? Which patterns repeat?
Architecture
Which target structure reduces complexity, protects critical data and makes further development easier? Which guardrails do teams need so secure decisions become easier?
Enablement
Which patterns, reviews, rules and working practices help teams apply the new structure independently? How does knowledge remain available over time instead of disappearing again into individual heads or tool silos?
Typical outcomes
The result is not a single presentation or a promise of a finished tool. Depending on the situation, companies get a stronger foundation for technical decisions.
- Clearer architecture in grown or hard-to-understand systems
- Reduced integration effort through consistent integration approaches
- Controlled local knowledge systems with local models, Retrieval-Augmented Generation, agent workflows and traceable data flows
- Clearer decision foundations, traceable technical decisions and review structures
- Engineering knowledge that is easier for existing and new teams to access, including onboarding paths and technical guidance
- Guardrails that make safe and useful decisions easier in daily work
The right format follows from the system
Some technical organizations first need an assessment, architecture review or discovery session that brings architecture, security, engineering knowledge and responsibilities together around a concrete question. This is not a standalone product, but the appropriate entry point into a consulting mandate, architecture review or concrete architecture work.
What matters is the concrete context: existing software, regulatory requirements, security boundaries, technical roles, available engineering knowledge and the question of which complexity actually needs to be reduced.