I design architectures that fit your team and the landscape you already run – microservices where they pay off, clear boundaries and documented decisions everywhere else. As a freelancer, remote across Europe and on-site in North Rhine-Westphalia.
Architecture decides how expensive a change will be in two years. Cut the boundaries between services in the wrong place and you get a distributed monolith: many deployments, but every change reaches into five repositories. Distribute too early and a small team pays operational cost for complexity it does not need yet. So my goal is not the most elegant architecture, but the one your team can actually run and evolve.
I am a senior software engineer with architecture experience, not a certified enterprise architect – and that is exactly what changes the collaboration. My designs come out of building: at DVV Duisburg I was the software architect for a company-wide microservice architecture, and I have spent more than ten years inside grown systems built with Java, .NET, PHP, Python and TypeScript. What I propose, I have built and operated myself.
An architecture concept nobody reads helps nobody. So I keep decisions short and traceable – which options existed, why one was chosen and under which conditions it should be reconsidered. That way the knowledge stays in your company, even after I leave the project.
Four topics you can commission on their own or combine into a full architecture engagement.
Where do the boundaries between services run? Using domain-driven design and methods such as event storming, I work out the business contexts and derive the cut from them – including an honest recommendation when a well-structured modulith is the better choice.
Contracts that last: REST interfaces specified with OpenAPI, clear error and versioning strategies, idempotency and pagination. Plus connecting the systems you already run – business applications, databases and ERP or SAP landscapes via OData.
Asynchronous communication through RabbitMQ or Apache Kafka wherever synchronous calls chain systems together unnecessarily: event design, delivery guarantees, retries and dead-letter handling – and the question of which consistency your business rules actually require.
Untangling existing applications step by step instead of rewriting them: carving out one business area at a time, migrating data cleanly and keeping the legacy system running behind a gateway until it becomes redundant. Operations continue throughout.
Situations where an outside architectural view makes the biggest difference.
Every change needs a full release, teams wait for each other, test runs take hours. We assess which parts can be carved out at reasonable cost – and which may stay in the core, because separating them there costs more than it returns.
There are already many services, but they read each other's databases and fail together. This is about redrawing boundaries: data ownership per service, proper contracts and asynchronous communication exactly where things block today.
A product or platform is being built and has to grow with the business. We fix the domain boundaries, the interfaces and the operational groundwork so that later additions do not fail on the foundation – without delaying the first release.
Modern applications have to talk to SAP, databases and legacy processes that cannot be changed. An integration layer encapsulates those systems so their quirks do not leak into every new application.
Architecture does not happen in an ivory tower. This sequence keeps the effort small and the decisions reviewable.
I look at the code, the deployments and the data flows, and talk to the people who operate the system. The result is a picture of the architecture as it really is – which almost always differs from the documented one.
Together with your business people and developers we work out the domains. That tells us which parts belong together, where interfaces make sense and in which order things can be separated.
A target picture with interfaces, data ownership, communication paths and operational requirements – deliberately as short as possible. Every significant decision is captured as a brief architecture decision record, with alternatives and reasoning.
I stay involved in delivery: the first cut together with the team, code reviews, adjustments wherever practice contradicts the design. Then a handover with documentation, so your team can continue without me.
The selection follows what already runs in your company – not what happens to be new.
Describe briefly where your system slows you down today – in releases, in operations or with new requirements. I will come back with an honest first assessment.