Raphael Strotz

Was ich mache

Ausgewählte Erfahrung

1. 2023 – heute

   Senior Software Engineer & Architekt · Swiss GRC

   Entwurf und Weiterentwicklung mandantenfähiger SaaS-Plattformen mit strikter Mandantentrennung, automatisiertem Provisioning, Messaging und Kubernetes-basierten Deployments.

   Leitung des Engineering-Teams als Head Software Engineering und anschliessend bewusster Wechsel zurück zu praxisnaher Architektur und Umsetzung.

   • C#
   • .NET
   • PostgreSQL
   • Marten
   • Azure Service Bus
   • AKS

2. 2021 – 2023

   Software Engineer · Franke Coffee Systems

   Mitarbeit an einer Cloud-nativen Azure/AKS-Plattform, die mehr als 7’000 Kaffeemaschinen verbindet — .NET-Backend-Services, verteilte Systeme und IoT.

   Infrastructure as Code, CI/CD und Deployment-Automatisierung sowie Vue.js-Microfrontends.

   • C#
   • .NET
   • Azure
   • AKS
   • Azure IoT Hub
   • Vue.js

3. 2018 – 2021

   Software Engineer · Network 41

   Modernisierung geschäftskritischer ASP.NET-Anwendungen und Integrationen mit schrittweiser Migration Richtung .NET Core statt kompletter Neuentwicklung.

   • C#
   • ASP.NET
   • SQL Server
   • .NET Core

4. 2013 – 2018

   Software Engineer · JMC Software

   Entwicklung von .NET-Desktop- und Business-Anwendungen, Web-Systemen sowie ERP- und Drittsystem-Integrationen.

   • C#
   • .NET
   • DevExpress XAF
   • ASP.NET MVC

5. 2008 – 2012

   Lehre & Software-Entwicklung · Data Unit

   Start meiner beruflichen C#/.NET-Laufbahn (Informatiker EFZ – Applikationsentwicklung) mit Arbeit an SAP-Business-One-Anpassungen und Reporting.

   • C#
   • .NET
   • SQL Server
   • SAP Business One

Wie ich arbeite

• Verstehen, bevor man ändert

  Ich will wissen, warum ein System so aussieht, wie es ist, bevor ich einen Umbau vorschlage. Die kleinste sinnvolle Verbesserung schlägt meist die Neuentwicklung.

• Architektur mit Augenmass

  Keine verteilten Systeme, Microservices oder Kubernetes, solange sie kein echtes Problem lösen. Komplexität muss man sich verdienen.

• Für den Fehlerfall entwerfen

  Netzwerke fallen aus, Nachrichten kommen doppelt, Prozesse stürzen mittendrin ab. Die Architektur sollte das voraussetzen, nicht darauf hoffen.

• Systeme beobachtbar machen

  Ein System, das läuft, aber nicht erklären kann, warum es ausgefallen ist, wird nicht gut betrieben. Logs und Traces sollten die Geschichte erzählen.

• Entwicklung und Betrieb gehören zusammen

  Anwendungscode, CI/CD und Infrastruktur sind eine Sache. Entwickler sollten verstehen, wie ihre Software gebaut, ausgeliefert und betrieben wird.

Technologien

Ein kuratierter Ausschnitt, nicht der ganze Werkzeugkasten.

Backend

• C#
• .NET
• ASP.NET Core
• REST APIs
• Entity Framework Core
• Marten

Daten & Messaging

• PostgreSQL
• SQL Server
• Azure Service Bus
• RabbitMQ
• Outbox / event-driven

Cloud & Plattform

• Azure
• Kubernetes / AKS
• Docker
• Helm
• Terraform

CI/CD & Observability

• GitHub Actions
• Azure Pipelines
• OpenTelemetry
• Application Insights

Frontend (ergänzend)

• TypeScript
• React
• Vue.js

Abseits der Tastatur

Wenn ich nicht gerade ein Problem durch ein verteiltes System verfolge, findet man mich meistens auf dem Mountainbike oder beim Karate (2. Dan / Nidan).

Kontakt

Ab November 2026 für Freelance-Projekte in Software-Engineering und Architektur verfügbar. Am schnellsten erreichen Sie mich per E-Mail.

• E-Mail
• GitHub
• LinkedIn