SOFTWARE ARCHITECTURE

Good software architecture is not a stylistic device. It is a working tool.

It reduces complexity instead of disguising it. It explains a system without having to explain it. At first glance, you can see what was built and why – not which technology is currently in vogue.

I don’t design architectures out of enthusiasm for patterns, not to stroke my ego, not to show what is technically possible, but out of respect for the domain.

The focus is not on the database.

Not the cloud.

Not Docker.

But rather the business model that thrives on it – or dies if it is suffocated by accidental complexity.

WHAT MATTERS TO ME

I have been working for many years in large, mature system landscapes – and currently (as of 2026) as a technical manager and architect in several ongoing projects, including:

• at GÖRG, a large law firm, in two AI-driven projects to relieve the workload of lawyers, in collaboration with the Fraunhofer Institute

• at GIZ (German Society for International Cooperation) in requirements analysis and architecture of complex systems

• as a cloud solution architect at the German branch of Fujitsu

I know how enterprise architectures work.

And I know why many fail.

The most common reason is not the technology.

It is misguided ambition and/or missing or unclear requirements. Once these have been structured and collected, contradictions, misconceptions, and a lack of focus on business value quickly become apparent.

NO ARCHITECTURE THEATER

I am not a dogmatist. And I am not an architect who puts his ego above business value.

If an old, ugly PHP application has been reliably generating 90% of your revenue for years, then it’s not a problem—it’s an asset.

I’m not going to explain to you why it “actually” needs to be rewritten. I’ll explain to you when it’s worth it—and when it’s not.

Complexity is not a sign of quality.

Elegance comes from omission.

WHAT I DO SPECIFICALLY

SOLUTION AND ENTERPRISE ARCHITECTURE

• Design of robust target architectures for existing and new systems

• Clear separation of domain, technology, and infrastructure

• Decision-making bases instead of tool recommendations

• Architecture that remains explainable, maintainable, and expandable

I think about architecture across the entire life cycle: from requirements to implementation and operation to further development and controlled shutdown. It’s an advantage to have gone through all the relevant roles yourself.

ARCHITECTURE UNDER THE INFLUENCE OF AI

AI is changing not only the product, but also the entire development process.

Those who ignore this are building systems today that will be unmanageable tomorrow.

I know the typical pitfalls from practical experience – not from white papers:

• RAG pitfalls Retrieval is not a magical context spell. Incorrect chunking produces semantic chainsaw massacres.

• Prompt and model pitfalls

  Models sound consistent, but become dangerously predictable. Nice does not equal reliable.

• Architecture lie

Models are not microservices. They are stochastic systems. They need fences, rules, and clear responsibilities.

• Testing problem

How do you test systems that don’t deliver the same output twice? With architecture – not with hope.

• DevOps friction Deterministic pipelines collide with probabilistic outputs. This is not a bug, but a structural problem.

I deliver solutions for this. No excuses.

PRAGMATISM INSTEAD OF HYPE

My broad experience – technical, legal, and organizational – allows me to quickly distinguish between hype and substance.

I have seen enough systems fail to develop any infatuation with complexity.

I also know what side effects decisions have:

• Security versus usability

• Governance versus developer satisfaction

• Speed versus maintainability

There is no perfect solution. But there are honest considerations.

CONTEXT THAT OTHERS OFTEN IGNORE

I don’t work in a vacuum.

In addition to computer science, I bring experience in law, economics, psychology, and leadership. I know how architectural decisions affect organizations—technically, humanly, and politically.

This is especially true for AI:

Those who only see technology overlook half the problem.

The same goes for those who only see risks.

I consciously work in the middle. As is so often the case in life, this is usually where you find the point closest to the truth. And as my law philosophy professor said back then: Always follow those who seek the truth and avoid those who claim to have found it set in stone.

IN SHORT

I build software architecture for people who bear responsibility.

For systems that don’t have to impress – but work.

And for decisions that will still be justifiable in three years’ time.

If you’re looking for someone to tell you what makes sense – and also what you should avoid – then we’re probably a good fit.