Ich entwerfe Architekturen, die zu Ihrem Team und Ihrer bestehenden Landschaft passen – Microservices dort, wo sie sich rechnen, klare Schnitte und dokumentierte Entscheidungen überall sonst. Als Freelancer, remote in der DACH-Region und vor Ort in NRW.
Architektur entscheidet darüber, wie teuer eine Änderung in zwei Jahren ist. Wird der Schnitt zwischen Diensten falsch gewählt, entsteht ein verteilter Monolith: viele Deployments, aber jede Anpassung zieht sich durch fünf Repositories. Wird zu früh verteilt, zahlt ein kleines Team Betriebskosten für Komplexität, die es noch gar nicht braucht. Mein Ziel ist deshalb nicht die eleganteste Architektur, sondern die, die Ihr Team tatsächlich betreiben und weiterentwickeln kann.
Ich bin Senior Software Engineer mit Architektur-Erfahrung, kein zertifizierter Enterprise-Architekt – und genau das ist der Unterschied in der Zusammenarbeit. Meine Entwürfe entstehen aus der Umsetzung heraus: Ich habe bei der DVV Duisburg als Softwarearchitekt den Aufbau einer unternehmensweiten Microservice-Architektur verantwortet und arbeite seit über zehn Jahren in gewachsenen Systemen mit Java, .NET, PHP, Python und TypeScript. Was ich vorschlage, habe ich selbst gebaut und betrieben.
Ein Architekturkonzept, das niemand liest, hilft niemandem. Deshalb halte ich Entscheidungen kurz und nachvollziehbar fest – welche Optionen es gab, warum eine davon gewählt wurde und unter welchen Bedingungen sie neu zu bewerten ist. So bleibt Wissen im Unternehmen, auch wenn ich das Projekt wieder verlasse.
Vier Themen, die sich einzeln beauftragen oder zu einem vollständigen Architekturvorhaben verbinden lassen.
Wo verlaufen die Grenzen zwischen Diensten? Mit Domain-Driven Design und Methoden wie Event Storming arbeite ich die fachlichen Kontexte heraus und leite daraus den Schnitt ab – inklusive einer ehrlichen Empfehlung, wenn ein gut geschnittener Modulith die bessere Wahl ist.
Verträge, die Bestand haben: REST-Schnittstellen nach OpenAPI-Spezifikation, klare Fehler- und Versionierungsstrategien, Idempotenz und Paginierung. Dazu die Anbindung vorhandener Systeme – von Fachanwendungen über Datenbanken bis zu ERP- und SAP-Landschaften über OData.
Asynchrone Kommunikation über RabbitMQ oder Apache Kafka, wo synchrone Aufrufe Systeme unnötig aneinanderketten: Event-Design, Zustellgarantien, Wiederholungen und Dead-Letter-Behandlung – und die Frage, welche Konsistenz Ihre Fachlichkeit wirklich braucht.
Bestehende Anwendungen Schritt für Schritt entflechten, statt sie neu zu schreiben: Fachbereiche nacheinander herauslösen, Daten sauber migrieren und den Altbestand über ein Gateway weiterlaufen lassen, bis er überflüssig ist. Der Betrieb läuft dabei durchgehend weiter.
Situationen, in denen ein externer Architektur-Blick den größten Unterschied macht.
Jede Änderung erfordert einen vollständigen Release, Teams warten aufeinander, Tests laufen stundenlang. Wir prüfen, welche Teile sich mit vertretbarem Aufwand herauslösen lassen – und welche im Kern bleiben dürfen, weil eine Trennung dort mehr kostet als sie bringt.
Es gibt bereits viele Services, aber sie greifen gegenseitig auf Datenbanken zu und fallen gemeinsam aus. Hier geht es um das Nachziehen von Grenzen: eigene Datenhoheit je Dienst, saubere Verträge und asynchrone Kommunikation an den Stellen, die heute blockieren.
Ein Produkt oder eine Plattform soll entstehen und von Anfang an mitwachsen können. Wir legen den fachlichen Schnitt, die Schnittstellen und die Betriebsgrundlagen so fest, dass spätere Erweiterungen nicht am Fundament scheitern – ohne das erste Release zu verzögern.
Moderne Anwendungen müssen mit SAP, Datenbanken und Fachverfahren sprechen, die sich nicht ändern lassen. Eine Integrationsschicht kapselt diese Systeme, damit deren Eigenheiten nicht in jede neue Anwendung durchschlagen.
Architektur entsteht nicht im Elfenbeinturm. Dieser Ablauf hält den Aufwand klein und die Entscheidungen überprüfbar.
Ich sehe mir den Code, die Deployments und die Datenflüsse an und spreche mit den Menschen, die das System betreiben. Am Ende steht ein Bild der tatsächlichen Architektur – die weicht von der dokumentierten fast immer ab.
Gemeinsam mit Ihren Fachbereichen und Entwicklerinnen und Entwicklern arbeiten wir die Domänen heraus. Daraus ergibt sich, welche Teile zusammengehören, wo Schnittstellen sinnvoll sind und in welcher Reihenfolge sich etwas trennen lässt.
Ein Zielbild mit Schnittstellen, Datenhoheit, Kommunikationswegen und Betriebsanforderungen – bewusst so knapp wie möglich. Jede wesentliche Entscheidung wird als kurzer Architecture Decision Record festgehalten, mit Alternativen und Begründung.
Ich bleibe in der Umsetzung: erster Schnitt gemeinsam mit dem Team, Code-Reviews, Nachjustieren, wo die Praxis dem Entwurf widerspricht. Danach Übergabe mit Dokumentation, damit Ihr Team ohne mich weiterarbeiten kann.
Die Auswahl richtet sich nach dem, was bei Ihnen bereits läuft – nicht nach dem, was gerade neu ist.
Beschreiben Sie kurz, wo Ihr System heute bremst – bei Releases, im Betrieb oder bei neuen Anforderungen. Ich melde mich mit einer ehrlichen Ersteinschätzung.