For business leaders, CTOs, and data and AI leads

I’ll design how your company’s data, metrics, and AI work together.

Planning a data platform, an AI application built on company data, or a major change to your current setup? I help connect the business goal with data sources, metrics, and AI components in a design your team can review, sequence, and implement. We start with the decision the system needs to support.

Discuss architecture design

Technical choices should follow what the system needs to make possible.

For more than ten years, I have worked across data, technology, and business decisions. When designing an architecture, I look at where data comes from, what it means to the people using it, and what work AI needs to handle. Only then does it make sense to choose specific tools.

10+ years: across data, BI, automation, and product technology
From BI to AI: public talks and articles on metrics, context, and AI agents

Architecture matters when one choice starts affecting the whole system.

That is where leadership expectations meet the data team’s capabilities and the needs of the people who will use the result.

Owner / CEO We are planning an investment, and I need to understand the options and trade-offs.
The design connects the expected business value with costs, risks, and dependencies, so the decision is grounded in more than a vendor presentation.
CTO / data lead Reporting works, but AI needs more context to use our data.
We examine how sources, data models, metric definitions, a semantic layer, and the AI interface should work together.
AI initiative owner We have a prototype and need to know what must be true before developing it further.
The design considers permissions, answer quality, evaluation, operational ownership, and how the system connects to actual business workflows.

Connect the business goal, the data, and the way the system will run.

An architecture is more than a diagram of boxes. It should explain why each part exists, how work passes between them, and what decisions remain.

What work should the system support?

We clarify the decision or process behind the proposed change, who will use the result, and what a dependable outcome means to them.

Business goal and success conditions

How will data and AI pass work between them?

We map relevant sources, data flows, transformations, metrics, semantic context, and where an AI agent or another AI capability fits.

Target components and their interfaces

What needs to work in day-to-day operations?

We account for access, human oversight, quality evaluation, cost, ownership, and how each component can change safely.

Operations, risk, and future development

A design your team can use to decide what to build and validate.

You get a basis for a specific decision, not a catalog of every available technology. We agree on the depth of the design around the question you need to answer.

A view of the target setup: A clear description of the main architecture components, data flows, and system dependencies.
Decisions and trade-offs: Recommended options, assumptions that remain open, constraints, and risks that affect investment.
A sequence for next steps: What to validate or prepare first, who should be involved, and which decision the work should support next.

A slide from Radek Duha’s talk on metric definitions for AI agents

A public talk and a team project example

AI needs to understand what company data means.

In my Measure Club talk, I explained why an agent needs business context, metric definitions, and a sound data model. QuantumSpring’s public case study describes a team effort to build a semantic layer and evaluations; I attribute its results to the work of the full team.

Read From ETL to AI agents

QuantumSpring case study — shared team outcome

Start with a decision the business actually needs to make.

First, we define the question and involve the people who know the work. Then I review the materials needed for the design and prepare options for discussion.

01

Clarify the goal and boundaries

We agree on what the system needs to make possible, which parts belong in the design, and who needs to be involved.
02

Review the relevant context

We work through the relevant sources, metrics, processes, current tools, and operational requirements.
03

Present the design for a decision

We review the target setup, options, risks, and first steps. Any follow-up work is agreed separately.

A good fit if

You are planning a meaningful change to your data environment or an AI system that uses company data.
People from leadership, the business, and the technical team can contribute to the design.
You want an independent view of the options before investing or commissioning implementation.

Not a good fit if

You only need implementation capacity for a solution that has already been chosen.
You want a specific tool confirmed without comparing it with your business needs and constraints.
No one can provide the context or make a decision about what happens next.

What to know before we start.

The scope follows the decision the design needs to support. We agree on deliverables and working conditions before the engagement begins.

What will we agree on before starting?

The goal and scope, the people involved, the materials or access needed, the deliverable, timing, price, and any follow-up work that would be a separate engagement. We start only when we have a shared understanding of all of these.

How will we handle nonpublic data?

Before working with nonpublic data, we will agree in writing on which sources may be used, where they may be processed, who has access, and whether external AI tools are allowed. I do not work with nonpublic data without that agreement.

How is architecture design different from a data audit?

A data audit reviews the current state and helps identify what needs attention. Architecture design describes the target setup and the decisions that lead to it. Depending on the information available, starting with an audit may make sense.

Explore the data audit.

Do we need to choose tools first?

No. We start with the goal, current environment, and constraints. Specific technologies are assessed according to the role they need to play.

Does the engagement include implementation?

Not automatically. The design describes the target setup and next steps. Technical delivery, migration, or AI implementation would be agreed separately based on your needs and capacity.

Can you review our vendor’s architecture proposal?

Yes, if we have enough material and clear questions to assess. Before we start, we agree which parts I will review and what you need from the review.

How long does the design take, and what does it cost?

It depends on the system’s scope, the material available, and the people who need to be involved. After an initial conversation, I will propose the scope, deliverable, timing, and price. We start only once those are agreed.

Planning a new data or AI architecture?

Tell me what decision you need to make and which systems are involved. We can work out whether architecture design, a data audit, or another first step makes sense.

Prefer writing from your own inbox? jsem@radekduha.cz