Choosing the Right Software Architecture: Mastering Trade‑offs with the 3 Ps (Problem, Plan, Program)

Introduction: There is no perfect architecture

In the session “Die Wahl der richtigen Software Architektur” by Alexander Knapp (Objectbay), one message stood out above all: there is no perfect architecture. The goal is not to pick whatever is fashionable, but to make good decisions. Or, as Knapp emphasized: Everything in software architecture is a trade-off. When teams choose architecture by gut feel—reflexively “Microservices, of course”—they risk baking future problems into the system by adopting patterns they don’t actually need.

From our DevJobs.at editorial vantage point, the session plays like a pragmatic field guide: it shows how to move from the fuzzy “Which architecture should we pick?” to the precise “How do we select architecture the right way for our context?” The backbone is the “3 Ps”: understand the Problem, Plan, and then Program. Surrounding those steps are proven Domain-Driven Design practices, purposeful documentation, and the constant reminder that “why beats how.”

From the marketplace of patterns to real needs

Knapp paints the picture of a virtual marketplace overflowing with architecture styles: monoliths, microservices, variations akin to serverless (“SecureOS” was mentioned in the talk), and many more. In this abundance, there is no single pattern that sits above the rest. The worst case is all too common: a team picks a familiar style, implements its standard building blocks, and only later realizes they don’t fit the actual problem. The root cause is the wrong order of questions: deciding on “how” before clarifying what characteristics the system truly requires.

The alternative is to bring the selection method center stage: not “Which architecture is right?”, but “How do we choose the right architecture for our problem, our context, and our goals?” Knapp answers that with a crisp, three-step approach.

The 3 Ps at a glance

• Problem: What is the actual problem? How often, by whom, and under what conditions is it solved? Which quality attributes must be met? What is the organizational context?
• Plan: Model with intent. Dive deep where necessary. Make the “ilities” concrete. Visualize the design. Record and justify decisions. Stress-test with what‑ifs. Lead with “why.”
• Program: Proof of concept, tight feedback loops, BDD/TDD. Iterative and “good enough”—but always purposeful.

Let’s break down each step and the concrete tools Alexander Knapp highlighted.

Step 1: Problem — ask the right questions before drawing boxes

The starting point is deceptively simple—and absolutely decisive. Before modules, services, and data flows take shape, the team must unfold the problem from multiple angles. As Knapp noted, only by probing with customers, stakeholders, and users do you surface aspects that can reframe what initially looked “trivial.”

Usage scenarios and load profile

• How often is the problem solved? A daily batch tool has radically different architecture needs than a 24/7 high-availability system.
• How many concurrent users are realistic? Is it a niche tool for a few specialists, or a platform with millions of daily users?
• Is the problem truly complex—or would a simple workstation script be enough?

These questions quickly bring the key quality attributes to the fore: scalability, observability, maintainability—and performance traits like throughput. A candid assessment of what’s really required enables deliberate trade-offs. One practical insight from the session: if you need high scalability, a one-off script is unlikely to cut it—you’ll need a sturdier architectural pattern.

Organizational context

• What does the customer’s current system landscape look like? A standalone startup app faces different constraints than an enterprise product that will integrate with many services over time.
• How big is the team? Four engineers, a ten-person squad, or hundreds of teams worldwide? Splitting into ten services with only four developers is often an endurance test. Conversely, many teams can benefit from decoupled services.
• How will the organization evolve? Will it stay small and steady, or scale rapidly? Architecture must anticipate this trajectory.

Business value over developer fun

Knapp calls out a common failure mode: choosing a “cool” architecture because it’s enjoyable to build. If it takes two years to reach the market—or sends development costs through the roof—the architecture misses the point. Architecture must serve the business goal, including time-to-market and cost.

Tools to understand the problem

• Business Model Canvas: A one-page management tool that the DDD community often uses for high-level orientation. It helps capture the current state and target picture.
• Event Storming: Post-its on a whiteboard for events, actors, and system parts; no technology choices yet—pure domain/process understanding.
• Domain Storytelling: Similar, often even more high-level. Capture human–system interaction as stories.
• User Story Mapping: Structure major use cases and their decomposition with the customer. This yields quick, shared understanding of scope, priorities, and initial cuts.

Our impression: Together, these techniques create a sturdy foundation for decisions that follow. They shift the discussion from “We could build X” to “We must be able to do Y.”

Step 2: Plan — model, document, and justify

With the problem space mapped, the architecture can take shape. Knapp structures this phase around three thrusts: make the ilities concrete, make the architecture visible, and record the rationale behind choices.

From gut feel to concrete ilities

• Scalability: What load peaks and horizontal/vertical scaling must we realistically support?
• Throughput: What transaction rates are critical? Where might bottlenecks arise?
• Maintainability: How do we keep change manageable over the lifecycle?
• Observability: How do we track behavior, failures, and performance?

The answers from Step 1 turn into a technical target curve. They guide modeling and put guardrails around unnecessary complexity.

Modeling with C4 — zoom like Google Maps

Knapp recommends the C4 notation because it supports multiple zoom levels—like Google Maps:

• Context view: Who interacts with the system? What external systems are involved?
• Containers and components: How do we split the system into manageable building blocks?
• Detailed views: Later, where appropriate, sequence-level flows down to code.

Crucially, not everything needs full depth from the start. C4 lets you show stakeholders the “why” behind the cuts, while giving the team the “how” needed for implementation.

UML or “boxes and arrows” — whatever helps

If UML is familiar, it can carry you deeper in this phase. If not, simple diagrams suffice. The rule: visualize what’s necessary to reason and to decide.

Documentation: arc42 and ADRs

• arc42: A proven template to document architecture in a structured way—context, quality goals, constraints.
• ADRs (Architectural Decision Records): Short, to the point. Capture the option chosen, the reason, and the consequences. The aim is not infallibility but transparency: decisions are based on current knowledge and can be superseded later.

“What if …?” — stress-testing the design

Knapp strengthens planning with deliberate questions aimed at the design:

• What if daily users jump from 100 to 10,000?
• What if the system must sell 20 products instead of just one?
• What if new tenants join and multi-tenancy becomes essential?

These scenarios expose weak spots in cuts, data flows, and coupling—before they harden into code.

Second Law of Software Architecture: why beats how

Teams often start with tools, patterns, and frameworks—the “how.” Planning must be led by the “why”: Why this boundary? Why this communication style? Why this quality attribute as a priority? The rationale is your guardrail against architecture as an end in itself.

From model toward code: aggregates, transactions, communication

From the DDD toolbox, Knapp mentions the Aggregate Canvas to clarify essential structures early:

• Which aggregates exist, and how are they bounded?
• How do components communicate?
• Which transactions occur, how often, and what happens after a write?

The goal isn’t perfection, but validating the robustness of the core structure before code crystallizes.

Step 3: Program — PoC, iteration, and “good enough”

Now we build—but still with a test mindset. Knapp recommends starting with a proof of concept (PoC).

Whirlpool approach: dip in, test, adjust

• Minimal start: module skeletons and first dummy implementations.
• Exercise them against the requirements and ilities: does the design hold?
• If it does, iterate with real functionality.
• Keep stakeholder feedback in the loop.

The guiding principle: good enough. Don’t try to think through everything up front; make the best decision based on what you know, implement, learn, and then adjust.

BDD + TDD + Gherkin: sharpen requirements, reduce risk

Knapp proposes coupling Behavior‑Driven Development with Test‑Driven Development:

• Capture high-level requirements in a Gherkin-like syntax.
• Derive tests from them.
• Implement iteratively.

This way, domain behavior and quality goals show up early in code, and uncertainty shrinks with each iteration. Overarchingly, architecture is not a one-off big bang—it’s a continuous loop from problem to plan to program, and back.

Frequent questions and misconceptions — addressed head-on

The session closes with clear positions on well-worn debates.

“Microservice or monolith?” — the wrong question

There’s more than these two poles—and mixtures are legitimate. Knapp cites the modular monolith (“modulith”) as an example: a single runtime unit with clean internal modularization. It blends microservice benefits (clear boundaries) with monolith simplicity. What matters is the fit for the team and the organization.

“Isn’t this overengineering?” — it may feel so early on, but it’s essential long-term

Especially for younger teams, disciplined architecture can feel like “too much.” Knapp counters: the purpose of architecture is to keep systems changeable. If after three months you can no longer adapt, the architecture was wrong. Resilience to change is not a luxury; it’s the goal.

“Which is the right architecture?” — it depends

There is no single right one. It’s about trade-offs: do we prioritize cost, speed, scale—or a particular balance? Knapp’s memorable metaphor: a farmer shouldn’t plough a field with a Formula 1 car. Some advantages don’t matter when the purpose is off.

“Architecture doesn’t change, right?” — it does, and that’s healthy

Architecture is iterative. A good architecture is one you can evolve. Regularly re-checking direction yields better decisions and allows retooling as context shifts.

“There’s just one pattern for the whole system.” — rarely true

Systems can be heterogeneous. You can extract services incrementally without going “full microservices.” Mixing patterns is normal—so long as the rationale is explicit.

A practical checklist: questions to answer before you choose

From the session, you can derive a compact set of questions teams should address before settling on an architecture:

• Usage and load
• How often is the system used (batch vs. 24/7 high availability)?
• How many concurrent users are realistic—today and in the near future?
• Which throughput requirements are critical?
• Problem complexity
• Would a script do, or do we need an architectural pattern?
• Which parts of the domain are truly complex?
• Organizational context
• Which existing systems/technologies must we integrate with?
• How big is the team, how distributed, with what experience?
• How will the organization grow (steady, moderate, rapid)?
• Business goals
• What time-to-market is required?
• What cost envelope is acceptable—development and operation?
• Which quality attributes are top priority (scalability, maintainability, observability)?
• Architecture validation
• Which what‑if scenarios threaten the design most?
• Which ADRs capture the crucial decisions—and their reasons?
• How does the “why” show up in C4/models and PoCs?

Make decision-making and documentation routine

A key learning from Knapp’s talk: good architecture emerges less from one-off brilliance than from a routine of justification and feedback.

• Visualize: use C4 for the right altitude, and UML or simple diagrams where helpful.
• Document: arc42 for structure, ADRs for concrete decisions.
• Probe: ask what‑if questions routinely, keep stakeholders actively involved.
• Iterate: build PoCs, apply BDD/TDD, embrace “good enough”—purposefully.

This routine makes decisions transparent—for the team and for stakeholders—and keeps changes lightweight.

Closing thoughts: from “how to build” to “why and for what”

“Die Wahl der richtigen Software Architektur” by Alexander Knapp (Objectbay) puts architecture where it belongs: at the intersection of business goals, team reality, and technology. The maxim “Everything in software architecture is a trade-off” becomes an operating principle: understand the problem, plan deliberately, program iteratively.

Three takeaways stood out to us at DevJobs.at:

• The “best” architecture is the one with reasons clearly understood and documented.
• Mixed patterns are normal—“Microservice or monolith?” is a false dichotomy.
• Evolvability is the target state. It’s not overengineering to enable change; it’s overengineering when you lose sight of purpose.

In short: don’t start by picking a pattern—decide systematically. The 3 Ps provide the scaffold; C4/arc42/ADRs make it visible; PoCs/BDD/TDD supply the feedback. That’s how architecture becomes a sturdy bridge from problem to product value, not an aesthetic choice detached from needs.

• 

  

  Serverless Applications with AWS Lambda

  Thomas Jäger von Objectbay geht in seinem devjobs.at TechTalk zu dem Thema Serverless Applications in die Tiefe und überprüft, ob die Marketing Slides von Amazon auch halten was sie versprechen.

  Watch now
• 

  

  Microservices for Front Ends

  Michael Eder von Objectbay spricht in seinem devjobs.at TechTalk über einen Ansatz, wie man die gängige Architektur der Microservices auch im Front End anwenden könnte.

  Watch now
• 

  

  Mutation Testing

  Alexander Knapp von Objectbay widmet sich in seinem devjobs.at TechTalk dem Thema Mutation Testing – was es ist und wie jedes Software Projekt davon profitieren kann.

  Watch now

• 

  

  Alexander Knapp, Full Stack Software Engineer bei Objectbay

  Alexander Knapp von Objectbay schildert im Interview seinen Werdegang bis hin zu seiner aktuellen Rolle im Full Stack Engineering und was seiner Meinung nach für Beginner wichtig ist.

  Watch now