Knowledge reveals complexity - and improves Architecture

You finally understand the domain (problem space) well. Yet somehow it does not guide you directly to the solution you should choose. Do not worry - you are not alone.

If it feels more difficult to make a decision now than it was before you delved into the problem space, it is a sign that you are on the right track.

Knowledge does not simplify decisions - it exposes reality. And reality is complex.

Why? Because knowledge does not make things simpler. Knowledge makes you more aware of complexities, challenges, and unknowns. A lack of knowledge creates a misleading perception that things are easy. What can we do with it? Do not let yourself become overwhelmed by complexity. Instead, learn how to make decisions - even knowing they will eventually need to change.

Complexity grows with understanding

Being familiar with the problem space makes you aware of its nuances and details. With that understanding also comes awareness of its complexity.

Discovery and learning are a two-step process:

1. You ask a question.
2. You receive a response that will:
   1. address your concerns
   2. be incomplete
   3. be based on assumptions
   4. admit that the answer is not known yet

In practice, every answer you get falls into one of these four categories - and your architectural decisions depend on which one you are dealing with.

Each response leads to follow-up questions (perhaps not always in scenario a). This creates a loop that, in theory, can continue indefinitely.

Instead of worrying about this, let’s look at each type of response and how it influences architectural decisions:

A) Reliable knowledge - we know and can trust it

This means we can use it as input to either challenge or support architectural decisions.

It would be ideal if every question ended with such clarity, but that is unrealistic (we already explored that in one of my previous articles).

B) Partial knowledge - we know something, but not everything

We gain useful input that can support decisions, but we must remain cautious. Future discoveries may still impact those decisions.

Every decision here is a trade-off between flexibility and cost.

Ideally, we want to keep options open. However, doing so introduces additional complexity, which translates into higher maintenance costs. That is why you should not keep all doors open.

How do you decide which options are worth preserving? Classify your domains into core, supporting, and generic. Focus on keeping options open for your core domains - because these areas evolve the most and have the highest business impact.

C) Assumptions - we do not know, but we have hypotheses

Here, we know we cannot rely fully on current knowledge. That is still valuable information.

In this situation:

• Encapsulate this part of the problem space. This makes it easier to change if needed. Encapsulation does not always mean a separate service - it can be a module, package, or even a folder with a single entry point.
• Keep the API small. This clarifies responsibilities and prevents the solution from becoming too large to change later.
• Validate assumptions as early as possible. Since these are assumptions, investing heavily in internal architectural qualities is risky - they may be discarded. Focus on building just enough to validate.
• Use production deliberately as a learning environment. Release small, controlled changes, collect feedback, and evolve the solution until it becomes either case A or B.

D) Unknowns - we simply do not know

At this point, the only reasonable architectural decision is not to build it. You do not even know what should be created.

However, the role of an architect, tech lead, or engineer should not end here. We should support business stakeholders by asking:

• Is this an essential part of the business? In most cases, the answer will be "no." A different answer would be concerning - domain experts not understanding a critical part of the business is a serious signal. If the answer is "yes," it is better to recommend waiting until the uncertainty is resolved.
• Can we proceed without it? Even if it is not a blocker, stakeholders may still prefer to pause further work until the uncertainty is reduced.
• Can we run an experiment? This question helps verify whether this is truly scenario C. If an experiment is possible, it means there is at least an assumption to validate.

Summary

The more you know, the better - it is hard to disagree with that. However, greater understanding also brings greater complexity.

The goal of an architect is not to remove uncertainty, but to navigate it deliberately.

This is not a problem. It is a signal that you see reality more clearly.

Better understanding leads to better decisions, lower long-term cost, and systems that can adapt to change.

And even if decisions become harder, they will be significantly better than those made without sufficient understanding.