The Hidden Problem in Discovery process

What I Learned About Business Truth After Years of Working With Multiple Stakeholders

After running many Discovery processes across different organizations, I noticed something that repeats almost every time:

Most companies do not have one shared business truth. They have several.

Every department has its own numbers, its own reports, its own interpretation of the same process. And when Discovery begins in this environment, the architecture quickly becomes a reflection of these contradictions.

It took me years to understand that the biggest Discovery challenge is not gathering requirements, documenting flows, or drawing diagrams. The biggest challenge is uncovering which version of the truth is actually the truth.

When there are multiple stakeholders, everyone brings a different reality

This is the part nobody mentions in textbooks.

In real projects:

• Sales shows their “pipeline truth”
• Finance shows their “revenue truth”
• Operations shows their “process truth”
• Customer Support shows their “case truth”
• Product brings “roadmap truth”
• Marketing brings “persona truth”

And each of these truths is internally consistent but mutually contradictory.

I’ve had Discovery workshops where five stakeholders described the same process in five completely different ways. All of them were “right” in their own context… but for the architecture, I could only choose one version to represent.

That’s where most project failures begin.

The real purpose of Discovery: find the shared version of reality

Over the years, I started to treat Discovery not as documentation work, but as alignment work.

Not: “What is the process?” but rather: “What is the authoritative version of this process that everyone agrees on?”

Not: “Where do you store the data?” but rather: “When numbers differ, which system wins?”

Not: “What does this role do?” but rather: “Who owns the decision when stakeholders disagree?”

When done well, Discovery becomes a truth-finding mission. When done poorly, it becomes a nicely formatted record of organizational chaos.

How I identify the business Single Source of Truth in complex environments

Below are the methods that proved most effective for me when working with multiple departments, conflicting stakeholders and unclear ownership.

1. Big Picture Event Storming with all stakeholders in the same room

Whenever possible, I put all key people in one session and map events together. It forces alignment because people are confronted with each other’s realities.

Two simple questions help uncover the truth:

• “Where is this event officially registered?”
• “Who needs to consider it true for the process to continue?”

Patterns emerge very quickly. You see who is aligned, who is not, and who actually owns the business reality.

2. The “tie-breaker interview”

When multiple systems or departments claim ownership, I always look for the “final authority.”

I ask:

• “If numbers differ, whose version is used in the board meeting?”
• “Which data source would you present during an audit?”
• “Which report finalizes the decision?”

In almost every project, there is one person or one system that becomes the ultimate reference. This is your real SSOT, even if nobody formally calls it that.

3. Observing how people work when nobody watches

Some of the most important truths do not appear in meetings. They appear in hallways, Excel files, personal notes, or shared drives.

If managers correct system data manually in a spreadsheet, then the spreadsheet is their source of truth — regardless of what the official process says.

Observation reveals these silent truths.

4. Following the reports that matter

In many projects, I trace back the data from:

• board reports,
• regulatory submissions,
• monthly performance reviews,
• financial statements,
• SLA compliance reports.

The system that supplies these is usually the authoritative one. It may not be modern or elegant, but it carries the highest responsibility, and responsibility always points to truth.

5. Mapping conflicts and asking “why”

Where KPIs differ, truth is missing.

I often collect examples:

• Revenue is X in CRM
• Revenue is Y in ERP
• Revenue is Z in BI

Then I ask each department to walk me through how their number is generated. Some truths are based on timing, others on rules, others on outdated processes.

When you break the conflict down, the actual authoritative logic becomes clear.

What happens when this alignment does not exist?

I have seen these symptoms in every organization that lacked a business SSOT:

• Meetings start with arguing about numbers instead of deciding what to do with them
• Development teams implement different interpretations of the same rule
• AI tools generate inconsistent logic because the input is inconsistent
• Products drift away from the business reality they were meant to support
• Architectural decisions become reversible because nobody agrees on the baseline •
• Velocity drops not because of code, but because of misalignment

A system built on conflicting truths becomes unmaintainable, regardless of technology.

The role of the architect: not a designer, but a facilitator of truth

After many years in architecture, I realized something important:

The architect’s job is not only to design systems. It is to reveal the truth hidden behind processes, data flows and stakeholder expectations.

An architect becomes:

• a translator between departments
• a mediator between competing truths
• a navigator through unclear ownership
• a challenger of assumptions
• a protector of clarity and consistency

This is the part of the job that no tool or framework can automate.

Responsible Software Architecture starts with responsible Discovery

Within our Responsible Software Architecture framework (https://responsiblesoftwarearchitecture.com/), this aligns with two pillars:

Responsible Organization - Clear processes and shared understanding.

Responsible Business - Value-driven decisions based on real data, not assumptions.

The Single Source of Truth is where these two meet. Without it, architecture becomes guesswork.

Final Thought

In Discovery, the biggest risk is not missing a requirement. The biggest risk is documenting a process that the organization wishes existed instead of the one that actually exists.

Finding the truth early prevents months or years of confusion later.

If there is one lesson I learned over the years, it is this:

Architecture cannot begin until the business agrees on a single version of reality.

Everything else grows from that point.

If your organization struggles with conflicting versions of processes or data, I can help run a Discovery that reveals the actual business truth and aligns all stakeholders around it.

Clear truth leads to clear architecture. And clear architecture leads to predictable outcomes.

Feel free to reach out if you want to explore this further.