I don't sell an architecture. I find the one your domain needs.

The business describes its work one way; the software is structured another. Every requirement crosses that gap, and the crossing is where the cost lives: studies attribute half or more of all defects and the majority of rework not to bad code, but to software that doesn't match how the business actually works. This is also the part AI tools don't fix. Coding agents accelerate code, and Gartner expects 80% of technical debt to be architectural by 2027. The gap is structural, and from inside, it's invisible.

Why this happens

Many systems are designed and modeled from the wrong starting point. Teams begin with data structures: tables, entities, a snapshot of things. The business doesn't work in snapshots. Business people think in flows: things that happen in real business processes, such as "an order is placed" or "a contract is terminated". These are decisions and their consequences. When the software is structured around static data models and technical layers while the business runs on behavior, the mismatch is built in from the first minute.

I call what follows domain drift. Every new requirement arrives in the language of behavior and has to be translated into a structure that doesn't speak it. The translation happens in developers' heads, is never written down, and gets a little harder each time. Inside the team, nobody notices, because everyone has learned to translate. What they notice is the estimates getting worse.

My work starts on the other side. Before any technical question, I analyze what actually happens in the business: the events, and the decisions behind them. The analysis is always the same. The architecture that comes out of it is not. I don't recommend Event Sourcing because it's trending, and I don't sell it as dogma. It has to be justified by the domain.

The architecture is the output of the diagnosis, not the input.

Why me

Domain drift is hard to see from inside a team and easy to see from outside, if you've watched it happen often enough. I have built software for more than 30 years, in many industries, and the same patterns repeat everywhere: the shortcut that looks harmless, the abstraction that quietly becomes a dependency, the model that stopped matching the business two years ago. I recognize them early because I've seen how each one ends.

I'm not an advisor who left the code behind. I still design and build systems myself, from domain models to distributed architectures and high-volume data pipelines, and I've worked with Domain-Driven Design long enough to know what holds up in practice and what only works in books. That depth matters for one reason: my recommendations have to survive contact with real code, real data, and a real team under deadline. Advice that can't is worse than no advice.

What you get from me is a diagnosis you can act on, in plain language, with the reasoning laid open so your own people can carry it forward.

Where my thinking is public

I don't ask you to take the diagnosis on trust. My reasoning is published and you can check it before we ever speak.

I write regularly about software architecture at ricofritzsche.me, where I work through real design problems in the open: consistency boundaries, domain modeling, distributed systems, the trade-offs behind event-driven designs. Together with Ralf Westphal, I developed Command Context Consistency, an approach that scopes consistency to the facts a business decision actually needs. I'm also building FACTSTR, an event store, because I hold my own ideas to the standard of running software.

Read a few articles. If the way I reason about systems doesn't convince you, no call will.

Most systems are modeled from the wrong starting point. Teams begin with data: tables, entities, a snapshot of things. The business doesn't work in snapshots. But business works different. Business people think different. They think in flows of things that happens in the real world business processes, i.e. "an order is placed", or "a contract is terminated". These are decisions and their consequences. When the software is structured around static data models and technical layers while the business runs on behavior, the mismatch is built in from the first minute.

I call what follows domain drift. Every new requirement arrives in the language of behavior and has to be translated into a structure that doesn't speak it. The translation happens in developers' heads, is never written down, and gets a little harder each time. Inside the team, nobody notices, because everyone has learned to translate. What they notice is the estimates getting worse.

My work starts on the other side. Before any technical question, I analyze what actually happens in the business: the events, and the decisions behind them. The analysis is always the same but the architecture that comes out of it is not. I do not provide Event Sourcing as a dogma and because it's trending currently. It must be justified with for a good reason. The architecture is the output of the diagnosis, not the input.

Complex software rarely fails because one pattern is missing. It fails because important decisions stay unclear for too long: what belongs together, what should be separated, where critical business state is protected, how teams can change the system safely, and what really happens when processes fail, retry, overlap, or run for days.

These problems are easy to miss in demos, prototypes, and early delivery. They become expensive in production.

I help CTOs, engineering leaders, and developer teams challenge architectural assumptions before they turn into operational risk. With more than 30 years in software development and architecture, I bring an external view focused on clarity, consequences, and practical decisions — not methodology for its own sake.

The goal: make the architecture easier to reason about, expose hidden risks, and give your team a clearer basis for the next decision.

Ready to get an independent perspective before committing to a major path?

Book a Free 20-Minute Architecture Discovery Call

When This Helps

Bring me in when an architectural decision is important enough that guessing is too expensive.

Typical situations:

• Moving from prototype, PoC, or early delivery into real production
• The system works, but it is becoming harder to change safely
• Teams disagree about boundaries, ownership, data, or responsibilities
• A modernization effort risks adding another layer of complexity
• AI-assisted development is increasing delivery speed, but also the need for clear architectural direction
• Leadership needs an independent senior perspective before committing to a major technical path

I do not replace your team’s judgment. I help sharpen it.

What I Review

I focus on the parts of the architecture where mistakes become expensive — not whether the diagram looks clean or follows a fashionable pattern.

The questions that matter:

• Are system boundaries clear enough?
• Does each part have a clear responsibility?
• Is critical business data owned and protected in the right place?
• Can teams change important parts without creating hidden side effects?
• What happens when processes fail, retry, overlap, or run longer than expected?
• Where is the architecture adding unnecessary complexity?
• Which decisions are reversible, and which will be expensive to change later?
• Does the architecture fit the organization that has to build and operate it?

The goal is to expose the few decisions that really determine whether a system stays understandable, adaptable, and safe to operate over time.

How the Review Works

A useful architecture review does not require weeks of preparation. It needs the right context, the right people, and a clear question: What decision are you about to make, and what could go wrong if the architecture is not strong enough?

The process is simple:

1. Discovery Call — Short free call to understand your situation, the importance of the decision, and whether I can add value.
2. Context — You share existing material: diagrams, short descriptions, decision notes, or problem areas. No polished architecture document required.
3. Review — We review the architecture together with the people responsible. I challenge assumptions and focus on risks that are easy to miss from inside the project.
4. Outcome — You leave with a clearer view of architectural risks, trade-offs, and next decisions — so your team can move forward with more confidence.

Ways to Work Together

Every engagement starts with a free discovery call to clarify the situation and decide whether an external review is the right next step.

Focused Architecture Review

Best when you already have a system, proposal, prototype, or direction and want to challenge it before going further.

• Remote session
• Prepared from existing material
• Focused discussion with the responsible people
• Clear feedback on risks, trade-offs, and next decisions

Architecture Review Workshop

Best for larger or mission-critical decisions where the architecture needs review with the senior team.

• Half-day or full-day workshop (online or in person)
• Review of current architecture and key assumptions
• Discussion of risks, alternatives, and consequences

Ongoing Architecture Advisory

Best when architectural decisions are continuous and the team benefits from regular external input.

• Regular advisory sessions
• Review of important decisions
• Feedback on emerging risks
• Support for keeping the architecture understandable and changeable

Written summaries or follow-up sessions can be added when useful.

Why Work With Me

I have spent more than 30 years building, designing, reviewing, and challenging software systems. My strength is not a specific framework or technology stack — it is helping teams see the architectural consequences of their decisions more clearly:

• What will become hard to change?
• Where will complexity accumulate?
• Which assumptions are risky?
• Which boundaries are unclear?
• Where does the system depend on coordination, discipline, or luck?
• What will fail first when scale, time, or organizational pressure increases?

I bring an independent senior perspective to systems where the cost of being wrong is high. The goal is not to impress your team with theory. The goal is to help your team make better decisions.

Ready to challenge your architecture before it becomes expensive to change?

Book a free 20-minute Architecture Discovery Call. We’ll clarify your situation, the decision or risk you’re facing, and whether an external review would be useful.

This call is a focused conversation to understand what you’re building, why the decision matters now, what concerns you already see, and what kind of review format would make sense.

If there’s a good fit, we define the scope and next step.