Why I Start Architecture With the Business Model Canvas

One thing I do every time I face a new organisation, a new client, or a new product as a software architect: I start from the Business Model Canvas. 💡

Most people know it from the startup world. Founders use it to explain their idea and to look for funding. I use it for something else. It is the first step in my architecture workflow. It helps me ask the right questions before I write a single line of code, understand the product, and find the core areas that actually matter.

What the canvas is

The Business Model Canvas was created by Alexander Osterwalder and Yves Pigneur. It is one page with nine blocks. You fill it in during a meeting, usually with sticky notes, and when you step back you can see the whole business at a glance. No long document, no training, no special tool.

These are the questions I walk through with the client:

Value Propositions. What is it that distinguishes you from the competition?
Channels. How do you reach your customers?
Customer Segments. Who are your customers? Describe them in a couple of words.
Key Activities. What are the key steps to move closer to your customers?
Customer Relationships. How often will you interact with your customers?
Key Resources. What do you need to make the idea work?
Key Partners. Who are your partners to get a competitive advantage?
Cost Structure and Revenue Streams. What do you spend, and where does the money come from?

Pretty important questions. And none of them are about technology.

The question behind the questions

We build software for businesses. So we have to know the business well. That sounds obvious, but it is where a lot of projects quietly go wrong.

So here is the uncomfortable part. Do we really know the business we are building software for? Are we speaking the language of the business, or only the language of technology? Are we at risk of building the wrong thing? 🤔

A perfectly engineered system that solves the wrong problem is still a failure. The canvas is the cheapest way I know to find out what the right problem is.

Every block is also an architecture hint

Here is the part founders do not think about, but architects should. Once you start reading the canvas as an architect, every block stops being a business note and turns into the first draft of your architecture. The business is telling you where to put your effort, you just have to listen.

This is how I read each block:

Customer Segments: Different segments often mean different bounded contexts, different access rules, sometimes multi-tenancy. If one product serves three very different audiences, that is a signal about how I split the system.
Value Propositions: This is the thing the product cannot be bad at. It points straight to the quality attribute I have to protect. If the value is "fastest in the market", that is performance. If it is "we never lose your data", that is durability and consistency. I design around it instead of guessing later.
Channels: How customers reach the product tells me the integration points and the clients I have to support. Web, mobile, public API, partner systems. Each one is an entry point I have to design and protect.
Customer Relationships: How often and how closely the business talks to customers tells me whether I need real time or batch, what the SLAs feel like, and how much the system has to react to events as they happen.
Revenue Streams: This is the part of the system that must never quietly fail. It usually means billing, metering, and strong transactional integrity. Money flows are where "good enough" is not good enough.
Key Activities: These point to the core domain, the part where the company actually wins. That is where the best modelling and the most care should go. Everything else is supporting work that can stay simpler, or be bought instead of built.
Key Resources: The data and systems the business depends on. These are usually the systems of record I have to treat as the source of truth and design carefully around.
Key Partners: Every partner is an external dependency. That is where I think about anti-corruption layers, what happens when the partner is slow or down, and how I keep their model from leaking into mine.
Cost Structure: This grounds the technical decisions in reality. It shapes build versus buy, how much cloud cost the model can carry, and where it is worth spending engineering time at all.

Fill it during the conversation, then keep it

You can fill the whole canvas during a normal conversation with the client. No homework, no separate workshop. And once it is done it is a great artifact, something you and the team come back to later. One rule though: always double check your assumptions. If you are not sure a block is right, ask again. A wrong sticky note that everyone trusts is worse than an empty one.

How I run it in practice

Most of the time I am sitting with a C-Level person. The CEO, the CTO, the product owner, whoever holds the vision for the product. They are the ones who can answer the questions on the canvas, because the answers are the business, and the business is theirs.

I open a blank canvas in Miro and share my screen. The board looks like this before anyone has said a word:

An empty Business Model Canvas in Miro, with the nine blocks: Key Partners, Key Activities, Key Resources, Value Propositions, Customer Relationships, Channels, Customer Segments, Cost Structure, and Revenue Streams. — My starting point: an empty canvas in Miro, ready to fill in with the client during the meeting.

Then I go category by category. I ask a question about one block, they talk, and I fill the sticky notes in real time while they watch. Sometimes I do not fill it live at all. I just keep the conversation flowing, record it, and build the canvas afterwards from the transcription. Both work. The point is the same: ask, listen, capture.

What surprises people is how engaging it is. A C-Level person can talk about their business for hours. You are not interrogating them, you are giving them a clean structure to explain the thing they care about most. They lean in. And while they talk, you are quietly learning the product, the priorities, and the words they use.

A few things I have learned that make the session work:

I do not start at Key Partners. I start with Customer Segments and Value Propositions, because every other block hangs off those two. Get them wrong and the rest of the canvas is noise.
One sticky note, one idea. A few words each. If a note needs a paragraph, it is hiding two ideas that should be split.
I write what they say, not what I think. My job in the room is to ask the question and listen. The moment I start filling in my own assumptions, I stop learning.
I time-box it. Sixty to ninety minutes, sometimes two short sessions. I am not chasing a perfect canvas, I am chasing a shared understanding.
Disagreements are the best part. When two people fill the same block differently, I stop and dig in. That gap is usually where the real complexity, and the real risk, is hiding.

And I keep the board. It does not get thrown away after the meeting. I come back to it during discovery and again when I shape the architecture. When a new question comes up months later, the canvas is still there, telling me what the business cares about.

There is one more thing this does, and it might be the most valuable. When I step into a new product, I am a stranger. The first session sets the tone for everything that follows. Sitting down with a C-Level person, asking good questions, and showing that I care about their business before I care about my tech stack, that builds trust fast. By the end of the meeting I am not "the new architect" anymore. I am someone who gets it. That relationship between the company and the architect is worth as much as the canvas itself.

It is the first step, not the only step

The canvas is where I start. It is not where I finish. It gives me a shared picture of the business and the first rough shape of the system, and that is exactly what I need to begin. After that the work gets more detailed, one step at a time.

This is the workflow I follow:

Business Model Canvas. Understand the business, agree on what matters, and find the core areas. This is step one, and the whole point is to do it fast.
Discovery. Go deeper into the core areas the canvas surfaced. Talk to domain experts, walk through real scenarios, and learn the language the business actually uses.
Architecture. Turn that understanding into structure. Bounded contexts, the quality attributes I have to protect, the big decisions about how the parts fit together.
System design. Get concrete. Services, data, integrations, and the details that make the architecture real.

Each step builds on the one before it. If the canvas is wrong, everything downstream is built on sand. That is why I refuse to skip it, and why I keep it cheap and quick.

Why I keep coming back to it

The canvas is lightweight. You can introduce it in a single meeting, with no tooling and no preparation from the client. People who run startups already know it, and people who do not pick it up in minutes.

It is a great starting point for the architecture. And just as important, it is a great starting point for building relationships with stakeholders. 🤝 You sit on the same side of the table, looking at the same picture, asking the same questions. That is how trust starts.

PS. I fill the canvas in Miro during the meeting with the client. 📐