Strategic Thinking and Wardley Mapping with Susanne Kaiser

Below is a summarised transcript of the conversation between Gien Verschatse and Susanne Kaiser on Satisfying Software.

Why is it hard to align software architecture with business needs?

Gien: Why do you think people struggle so much with creating a software architecture that actually aligns with business needs?

Susanne: It's a multifaceted answer. One tendency we have is that we jump right into the solution space without truly understanding the problem space. The problem space is about aligning our solutions to business and user needs — not only being able to generate value for customers, but also being able to deliver that value.

To enable a fast flow of change, we need a holistic perspective — from business strategy, to software design and architecture, to team organisation. Each of these influences the architecture we decide on. As one quote from Continuous Architecture in Practice puts it, we have to "architect for change and leverage the power of small."

That also means reflecting Conway's Law — the communication structure of your organisation mirrors your software system design. Everything influences everything else, so it's not just a matter of going with it. You have to align every perspective in order to ultimately fulfil business needs.

Wardley Mapping vs. other discovery tools

Gien: I use the Business Model Canvas quite a lot to get a holistic view. You seem to favour Wardley Mapping. Why?

Susanne: It's not mutually exclusive — use whatever tools you're comfortable with. But I personally like Wardley Mapping because it starts from the user need perspective. Users and their needs are the anchor of the map.

It complements jobs-to-be-done theory really well too. Clayton Christensen stated that people buy products or services to get a job done. We can start with a core functional job, identify desired outcomes as user needs, and work from there. It recalibrates our thinking — early in my career I was reaching for the shiniest technology without anchoring it to any user need.

Wardley Maps also help create a shared understanding of the business landscape: Are we custom-building components that aren't part of our core domain? Could those be off-the-shelf products or cloud-hosted services instead? You can overlay different maps and spot synergies, challenge your own assumptions, and envision the future landscape you want to move toward.

Gien: A lot of the developers I work with can't really articulate how the company makes money or what value it's trying to deliver. They're there for the technology and the fun of it.

Susanne: But somehow you have to make money. You need to understand what problem you're solving and who your customers are. And we often over-engineer solutions with features users will never use, simply because we didn't start with user research or service design. The problem space usually stays the same — users generally don't care whether you use the latest AI technology, as long as you fulfil their needs efficiently and effectively.

Tips to discover user needs

Gien: If you go into a company where all of this is unknown, how do you surface user needs?

Susanne: I run collaborative workshop sessions with people from product, software engineering, and design — similar to the mix you'd want for event storming sessions. It's often revealing: teams start with one assumed user type and, through conversation, discover many more.

Some useful heuristics: follow a user journey if one exists, or identify needs task by task. The key is that user needs are technology-agnostic and expressed in language users themselves understand — not "save item in database." That's similar to the principle behind event storming's domain events, which are expressed in the ubiquitous language.

For a practical example: take an online school. The teacher's core functional job might be "facilitate remote learning." From there you can ask: what are the desired outcomes? Prepare learning material, assess student understanding, track progress, communicate with students — those become the user needs.

Connecting Wardley Maps to Domain-Driven Design

Gien: I mostly use event storming to identify bounded contexts, then classify them as core, supporting, or generic. Do you see a link between those subdomain types and the Wardley evolution stages — genesis, custom, product, commodity?

Susanne: Yes, that's one of the key heuristics. Core domain bounded contexts tend to land in genesis and custom build, where differentiation advantage is highest. Generic subdomain bounded contexts — non-differentiating and non-specialised — are candidates for product/rental or commodity stages, where cost advantage rises as more competitors offer the same solution.

Supporting subdomains are more nuanced. They don't provide competitive advantage, so they're non-differentiating, but they are specialised in supporting your core. The question is whether existing market solutions fit well enough, or whether the use case is too specific to rely on off-the-shelf options.

That said, it's not a perfect mapping. A component being in the commodity stage doesn't necessarily mean it shouldn't be custom-built — competitive advantage according to Michael Porter includes cost advantage as well as differentiation. A cloud provider's own infrastructure might sit in what consumers see as commodity, but internally it's still custom-built and strategically guarded.

Gien: I also look at future potential. Core domains lose business value over time as competitors catch up. A supporting subdomain with genuine potential might be worth building in-house now, rather than buying off the shelf.

Susanne: Exactly. And what Wardley Maps are good at is making those decisions explicit — not just "we've always done it this way," but surfacing the why and challenging it. I've encountered teams custom-building their task management, or running infrastructure in a basement, and asking "is this how you differentiate from your competitors?" is enough to start a productive conversation.

Climatic patterns and evolving landscapes

Gien: What are climatic patterns in Wardley Mapping?

Susanne: Climatic patterns are external forces that act on your landscape regardless of your specific context. They can accelerate or decelerate how your components evolve. For example: components evolve along evolution stages due to supply and demand competition — you know it'll happen, but not exactly when. And there's inertia to change: Nokia built one of the first smartphones in 2005, two years before Apple, but their past success made them reluctant to fully transition. They underestimated software and got overtaken.

Another pattern is "efficiency enables innovation" — when a component commoditises and standardises, new components can be built on top of it. That's how cloud computing enabled a whole generation of startups.

Understanding these patterns is a competitive advantage, because most of your competitors don't think about them. It feeds into what Wardley calls doctrinal principles — universal good practices that enable you to respond to change early and fast — and ultimately into leadership decisions about where you want to move strategically.

Gien: Every market has its own cadence — aerospace is a decade, LLMs are months. But the underlying patterns show up across all of them.

Susanne: Yes, and the more regulated or consolidated the market, the more some patterns dominate over others. But being aware of what's acting on your landscape makes it much easier to decide when to reassess your architecture — not just "set it and forget it."

Frustrations in Current Software Culture

Gien: What things still frustrate you in this space?

Susanne: We still tend to jump to solutions before understanding the problem. Right now there are a lot of AI initiatives focused on the technology itself, rather than asking: does this help us deliver value to our customers faster and more sustainably? We look for shortcuts, and in complex domains there often aren't any.

The DORA AI report actually found that AI amplifies what's already there — good processes get better, bad processes get worse. So if anything, having solid architectural practices in place has become more important, not less.

What does satisfying software mean to you?

Susanne: Software isn't a goal — it's a means to a goal. Satisfying software helps users accomplish their job effectively and efficiently. It means building the right thing, right, not just focusing on the technology.

That includes internal customers too — teams that can deliver their work in a self-sufficient manner, enabled by self-service capabilities, perhaps through platform teams as described in Team Topologies. A network of autonomous value streams, flowing without bottlenecks, serving both external customers and the people building the product.