NDC Conferences · Published 2025-03-04

Thinking Like an Architect - Gregor Hohpe - NDC London 2025

Open on YouTube ↗

Summary

Overview

  • Speaker: Gregor Hohpe
  • Channel: NDC Conferences
  • Main topic: Software architecture, thinking patterns, and organizational impact
  • Purpose: To redefine the role of software architects away from ivory-tower decision makers toward enablers of organizational alignment, trade-off evaluation, and structured thinking. Gregor Hohpe explores what it means to think like an architect, debunking the myth that architects are simply the smartest people making all the decisions in isolation. Instead, architects act as multipliers who make everyone else in the organization smarter. The presentation covers connecting levels (from penthouse to engine room), using effective metaphors, seeing multiple dimensions beyond binary trade-offs, selling options rather than rigid answers, and leveraging appropriate models.

Topic Map

Misconceptions of Architecture and Architects

  • Explanation: Addressing the misconception that architects are isolated sages who dictate decisions top-down, and reframing them as facilitators who empower development teams.
  • Key claims:
    • Architects are not the smartest people in the room making all decisions.
    • Team members living with the consequences are better equipped to make local decisions.
    • Architects make everyone else smarter by acting as multipliers.
  • Examples:
    • Comparing isolated oracle decision-making to team-driven execution.
  • Terminology:
    • Architect
    • Oracle
    • Multiplier
  • Why it matters: Shifts the organizational perception of architects from bottlenecks to enablers.

Connecting Levels: Penthouse to Engine Room

  • Explanation: Architects work across different organizational levels, connecting high-level business strategy (penthouse) with low-level technical execution (engine room).
  • Key claims:
    • The value of a modern architect is measured by how many floors they can connect.
    • If tunnels (organizational levels) don't meet, digging faster won't help.
    • Architects must ensure organizational alignment between strategy and technology.
  • Examples:
    • Skyscraper analogy separating penthouse management from engine room developers.
  • Terminology:
    • Penthouse
    • Engine room
    • Tunnel
    • De-layering
  • Why it matters: Prevents organizational disconnects between upper management and engineering teams.

The Power of Metaphors

  • Explanation: Using domain-familiar metaphors to translate complex technical constraints and trade-offs into concepts understandable by non-technical stakeholders.
  • Key claims:
    • Metaphors invite your audience into the thought process.
    • Not inviting your audience into the thought process is an underutilization of mental resources.
    • Car and train metaphors help explain friction, acceleration, and guard rails.
  • Examples:
    • Using car pedals and train wheels as metaphors for software acceleration and guard rails.
  • Terminology:
    • Metaphor
    • Accelerator
    • Guard rail
    • Lane assist
  • Why it matters: Bridges the communication gap between technical architects and executive stakeholders.

Seeing More Dimensions

  • Explanation: Moving away from binary trade-offs (e.g., speed vs. quality) into multi-dimensional analysis to make more productive decisions.
  • Key claims:
    • Architects see more dimensions than other people.
    • Time and quality are not opposites; they represent separate dimensions.
    • Multi-dimensional analysis prevents false dilemmas.
  • Examples:
    • Cylinder drawing perceived as a circle or rectangle depending on viewing angle.
  • Terminology:
    • Dimensionality
    • Granularity
    • Decoupling
    • Lock-in
  • Why it matters: Helps organizations resolve false dichotomies and find optimal solutions.

Selling Options and Real Options

  • Explanation: Treating architectural decisions as financial options that defer commitment until uncertainty is reduced, using Black-Scholes principles.
  • Key claims:
    • Architects sell options, not fixed answers.
    • Options have positive value because they allow deferring decisions into the future.
    • The higher the uncertainty, the more valuable the options.
  • Examples:
    • Choosing programming languages or cloud providers as purchasing options.
  • Terminology:
    • Options
    • Switching cost
    • Black-Scholes formula
    • Uncertainty
  • Why it matters: Provides a mathematical and economic justification for architectural flexibility.

The Role of Models

  • Explanation: Understanding that models are simplifications of reality meant to sharpen thinking and aid decision-making, not replicate reality perfectly.
  • Key claims:
    • All models are wrong, some are useful.
    • Simple models are the most useful because they abstract away unnecessary complexity.
    • The best model depends entirely on the question you are trying to answer.
  • Examples:
    • Heliocentrism vs. geocentrism models of the solar system.
  • Terminology:
    • Model
    • Abstraction
    • Heliocentrism
    • Geocentrism
  • Why it matters: Prevents over-engineering and keeps models focused on solving specific problems.

Key Points

Architects as Multipliers

  • Explanation: Architects elevate everyone around them rather than dictating solutions from above.
  • Evidence: Team members who live with consequences are better equipped to make informed choices.
  • Practical implication: Focus architectural work on enablement, frameworks, and decision-making guidance.

The Architect Boomerang

  • Explanation: When stakeholders ask for something, architects should back up to understand the underlying goal before moving forward with options.
  • Evidence: Requests like 'we need cloud-native' often mask deeper operational goals like resilience.
  • Practical implication: Ask 'Why?' and 'What's the real goal?' before committing to technical directions.

Real Options and Uncertainty

  • Explanation: Deferring decisions adds value in high-uncertainty environments.
  • Evidence: Black-Scholes option pricing principles apply to software architecture decisions.
  • Practical implication: Design systems to preserve future choices rather than locking into premature constraints.

Frameworks, Models & Processes

The Architect Elevator

  • How it works: Moving between organizational floors to connect business strategy (penthouse) with technical execution (engine room).
  • Components:
    • Penthouse (management/strategy)
    • Middle management (isolation layer)
    • Engine room (developers/IT)
  • When to use: When bridging communication gaps across organizational hierarchies.

The Logic Hourglass

  • How it works: Balancing high-level needs and low-level budgets through principled evaluation.
  • Components:
    • Needs and desirables
    • FUD, best practices, and metaphors
    • Budget and headcount
  • When to use: When structuring architectural proposals for executive review.

Examples & Case Studies

Starbucks managing order throughput vs. strict two-phase commit ordering.

  • Illustrates: Optimizing for the happy path and throughput over strict latency and blocking order.
  • Lesson: Learn from real-world systems to design resilient distributed architectures.

Geocentric vs. heliocentric models of the solar system.

  • Illustrates: How the right model makes complex reality comprehensible.
  • Lesson: Choose models based on the specific question you need to answer.

Actionable Takeaways

  • Immediate:
    • Use metaphors familiar to your audience to explain complex technical constraints.
    • Frame architectural decisions as options with associated switching costs.
    • Keep models simple and focused on specific questions.
  • Strategic:
    • Connect executive strategy with engineering execution.
    • Embrace uncertainty and use architecture to preserve options.
    • Change underlying beliefs rather than just arguing about behaviors.
  • Questions to investigate:
    • What are the underlying beliefs driving technical resistance in your organization?
    • Which architectural decisions are prematurely locking in high switching costs?

Claims Worth Verifying

  • The Black-Scholes option pricing model can be metaphorically applied to software architecture choices. (Conceptual analogy)

Notable Quotes

"Architects aren't the smartest people in the room. They make everyone else smarter." (at 2:34) "If the tunnels don't meet, digging faster won't help." (at 7:16) "All Models are Wrong, Some are Useful." (at 75:31)

Compressed Summary

  • Architects act as organizational multipliers, making teams smarter.
  • Connecting technical execution with business strategy is vital.
  • Metaphors bridge the gap between technical and executive communication.
  • Architecture creates valuable options that defer decisions under uncertainty.
  • Simple models are superior to over-elaborate representations.
  • Keywords: architecture, options, metaphors, models, uncertainty
  • Core insight: Software architecture is not about dictating answers, but about connecting organizational levels, using metaphors and models, and selling valuable options to navigate uncertainty.

Core insights

7
Mental Modelhigh noveltymoderate evidence

Architectural decisions should be framed as real options: their value comes from deferring commitment until uncertainty is reduced, and that value increases monotonically with uncertainty — an economic (Black-Scholes-derived) rather than aesthetic justification for flexibility.

Why it matters

Provides a quantifiable rationale for when to preserve optionality (abstraction layers, provider-agnostic interfaces, pluggable models/tools) versus when to commit; directly informs build-vs-abstract decisions in agent runtimes and tool layers.

Generalization

Any system built under high environmental uncertainty (model providers, tool APIs, agent frameworks) should price its abstractions as options, and the more volatile the underlying choice, the higher the option premium worth paying.

Architects sell options, not fixed answers.
Open source video
Options have positive value because they allow deferring decisions into the future.
Open source video
The higher the uncertainty, the more valuable the options.
Open source video
Architecturemedium noveltystrong evidence

Decision rights should sit with the actors who live with the consequences, with architects acting as multipliers who make others smarter rather than as centralized oracles issuing top-down decisions.

Why it matters

Changes where orchestration authority belongs: central controllers are a bottleneck, while local decision-making plus enablement (frameworks, guardrails, guidance) scales better and produces better-informed choices.

Generalization

In multi-agent and distributed systems, push decision authority toward the component holding the relevant context and bearing the failure cost; central layers should provide constraints and shared tooling, not per-action verdicts.

Architects are not the smartest people in the room making all decisions.
Open source video
Team members living with the consequences are better equipped to make local decisions.
Open source video
Architects make everyone else smarter by acting as multipliers.
Open source video
Mental Modelmedium noveltymoderate evidence

Treating trade-offs as binary (speed vs quality, latency vs throughput) is a modeling error; they are independent dimensions, and multi-dimensional analysis dissolves false dilemmas.

Why it matters

Prevents premature sacrifice of one property for another when both can be co-optimized, and forces explicit enumeration of the actual axes of a design decision.

Generalization

Design and evaluation spaces should be decomposed into orthogonal dimensions (granularity, coupling, lock-in, latency, cost) rather than collapsed into a single opposing pair; benchmarks should report vectors, not scalars.

Architects see more dimensions than other people.
Open source video
Time and quality are not opposites; they represent separate dimensions.
Open source video
Multi-dimensional analysis prevents false dilemmas.
Open source video
Mental Modelmedium noveltystrong evidence

A model's value is determined by the question it answers, not by its fidelity to reality; simple models that abstract away unnecessary complexity are the most useful.

Why it matters

Justifies deliberately coarse abstractions (reduced-fidelity world models, simplified context representations, small evaluators) when they sharpen the specific decision at hand, and warns against over-engineering models to mirror reality.

Generalization

Abstraction layers and internal representations in agent systems should be selected per task/query class; a model that is 'wrong' but decision-relevant outperforms one that is faithful but unusable.

All models are wrong, some are useful.
Open source video
Simple models are the most useful because they abstract away unnecessary complexity.
Open source video
The best model depends entirely on the question you are trying to answer.
Open source video
Practicemedium noveltymoderate evidence

Requests should be backed up to the underlying goal before any technical direction is chosen — stated solutions (e.g., 'we need cloud-native') often mask the actual operational objective (e.g., resilience).

Why it matters

Reduces the cost of building the wrong thing; a cheap clarification step at the front replaces expensive rework later, and surfaces the real evaluation criterion.

Generalization

Agent and tool pipelines should include an explicit goal-inference/clarification step that maps a requested action to an intended outcome before executing irreversible or costly operations.

Requests like 'we need cloud-native' often mask deeper operational goals like resilience.
Open source video
Ask 'Why?' and 'What's the real goal?' before committing to technical directions.
Open source video
Mechanismmedium noveltymoderate evidence

Metaphors are a mechanism for inviting the audience into the reasoning process; withholding that invitation underutilizes the audience's own cognitive resources.

Why it matters

Reframes explanation as participatory reasoning rather than broadcasting conclusions — a concrete mechanism for alignment between technical and non-technical decision-makers, and by analogy for making agent decisions auditable by operators.

Generalization

Use domain-familiar mappings to let the receiving party reconstruct the trade-off themselves; interpretability artifacts should be designed for shared reasoning, not just post-hoc justification.

Metaphors invite your audience into the thought process.
Open source video
Not inviting your audience into the thought process is an underutilization of mental resources.
Open source video
Failure Modemedium noveltymoderate evidence

Organizational misalignment is a failure that speed cannot fix: if independently dug tunnels don't meet, digging faster is wasted effort.

Why it matters

Identifies a class of failure where performance optimization on both sides of an interface amplifies rather than resolves a structural mismatch — a key risk in layered or multi-team agent infrastructure.

Generalization

Before optimizing throughput or latency on either side of a boundary, verify the interface/contract actually converges; misaligned interfaces make scaling counterproductive.

If tunnels (organizational levels) don't meet, digging faster won't help.
Open source video
The value of a modern architect is measured by how many floors they can connect.
Open source video

Deep dives

4

Quantitative option pricing for architectural abstractions in AI/agent systems

Research question

Can the value of specific architectural options (e.g., provider-agnostic interfaces, pluggable models) be quantitatively estimated using an adaptation of financial option pricing, and does this estimate predict actual usage or benefit?

Why

Provides a falsifiable method to price flexibility, moving architectural decisions from aesthetic arguments to economic calculation; directly informs build-vs-abstract decisions under uncertainty.

Options have positive value because they allow deferring decisions into the future.
Open source video
The higher the uncertainty, the more valuable the options.
Open source video
Source video

Boundary conditions for centralized vs. delegated decision authority in multi-agent systems

Research question

Under what conditions (context locality, coordination cost, failure impact) does centralized decision-making outperform delegation to consequence-bearing actors, and vice versa?

Why

Defines when central controllers are appropriate versus when local autonomy scales better; prevents both bottleneck centralization and chaotic divergence.

Team members living with the consequences are better equipped to make local decisions.
Open source video
Architects are not the smartest people in the room making all decisions.
Open source video
Source video

Goal inference protocol for converting stated technical requests into underlying objectives

Research question

Is there a repeatable elicitation procedure that reliably extracts the underlying operational goal from a stated technical request, and how accurate can it be?

Why

Reduces costly rework by catching mismatches between requested solutions and actual objectives before implementation; directly applicable as a clarification step in agent pipelines.

Requests like 'we need cloud-native' often mask deeper operational goals like resilience.
Open source video
Ask 'Why?' and 'What's the real goal?' before committing to technical directions.
Open source video
Source video

Empirical impact of vector versus binary trade-off framing on design decisions

Research question

Does presenting trade-offs as multiple independent dimensions rather than a binary opposition change the designs practitioners choose and improve measured outcomes?

Why

Tests whether multi-dimensional analysis actually dissolves false dilemmas or is merely rhetorical; could change how benchmarks and design reviews are structured.

Architects see more dimensions than other people.
Open source video
Time and quality are not opposites; they represent separate dimensions.
Open source video
Multi-dimensional analysis prevents false dilemmas.
Open source video
Source video

Article ideas

3

Your Abstractions Are Options: Pricing Flexibility in Agent Architectures

Architectural abstractions in AI systems should be evaluated as real options, with their value proportional to environmental uncertainty and switching costs; teams should therefore invest in flexibility only where volatility is high, and strip it where uncertainty is low.

Angle

Economic framing applied to concrete engineering decisions: provider-agnostic interfaces, pluggable models, and tool layers. Use examples from model provider churn and API instability.

Source video

The Central Oracle Is a Bottleneck: Why Agent Architectures Should Push Decisions to the Edge

Centralized decision-making in multi-agent systems fails to scale and often produces worse decisions than delegating authority to context-bearing components, provided central layers supply shared constraints and tooling rather than per-action verdicts.

Angle

Map organizational design principles (architects as multipliers) to agent orchestration; contrast central oracle with local authority plus guardrails.

Source video

Beyond Binary Trade-offs: Vector Evaluation for AI Systems

Treating trade-offs such as speed vs. quality or latency vs. throughput as opposing ends of a single axis is a modeling error that leads to false dilemmas; multi-dimensional vector evaluation enables co-optimization and better design decisions.

Angle

From scalar benchmarks to vector-based evaluation. Show how decomposing into orthogonal dimensions (granularity, coupling, lock-in, latency, cost, quality) changes choices.

Source video

Project ideas

3

OptionScorer

new

Scoring architectural abstractions by estimated switching cost and probability distribution of future change predicts which abstractions teams actually exercise or extend in practice, and correlates with perceived value.

Proof of concept

Build a lightweight tool that takes a set of architectural decisions (e.g., provider-agnostic interface, abstraction layer) and outputs an option value score based on a survey of switching costs and uncertainty estimates; validate against git history or decision logs of actual abstraction usage in open-source projects.

Measurement

Correlation between predicted option value and observed frequency of abstraction use/extension; qualitative validation via developer interviews.

Source video

DecisionDelegationBench

movement-lab

Delegating decisions to consequence-bearing actors improves decision quality over centralized expert decisions when context locality is high and coordination costs are low, but centralization wins when coordination costs exceed a threshold.

Proof of concept

Simulate a multi-agent system with a decision task (e.g., resource allocation) under two conditions: centralized oracle vs. local agents. Vary communication costs and context locality. Measure outcome quality and latency.

Measurement

Decision quality score, latency, coordination overhead as a function of context locality and communication cost; identify crossover point.

Source video

GoalBoomerang

gatehouse

An explicit goal-inference step that maps requested actions to intended outcomes reduces the frequency of building wrong solutions and improves alignment with the requester's actual criterion.

Proof of concept

Implement a prompt-based module in an agent pipeline that, before executing a technical request (e.g., 'we need cloud-native'), asks clarifying questions to infer underlying goals (e.g., resilience). Evaluate on a set of synthetic requests with known hidden goals.

Measurement

Accuracy of inferred goal vs. true hidden goal; reduction in rework in a simulated task; user-rated alignment.

Source video

Architectural implications

3

Centralized decision-making is replaced by enablement plus local authority.

Before

A central 'oracle' component inspects each case and issues the decision; the rest of the system executes.

After

Local components holding context make decisions within shared constraints, frameworks, and guardrails provided by a central enablement layer.

Consequence

Scales better and improves decision quality, but requires investment in guardrails, shared tooling, and observability of local decisions.

Source video

Abstractions are justified by the option value they preserve, not by purity.

Before

Abstraction layers are added or rejected on stylistic grounds or expected-but-unspecified future change.

After

Each indirection is priced as an option whose value rises with underlying volatility (provider churn, API instability, cost swings).

Consequence

Rationalizes some indirections and removes others, but introduces the need to estimate switching costs and uncertainty levels.

Source video

Model/representation choice is bound to a question class rather than to a system-wide standard.

Before

One canonical model of the domain is maintained and defended for completeness.

After

Multiple simplified models coexist, each selected per question to be answered.

Consequence

Reduces over-engineering and improves decision sharpness, but increases the burden of keeping models consistent where they must interoperate.

Source video

Tradeoffs and failure modes

5

Optionality vs. switching cost

Benefit

Deferring commitment preserves value under uncertainty and avoids premature lock-in.

Cost or risk

Flexibility has a price; options are only worth holding when uncertainty is high and switching costs are material — otherwise the abstraction is pure overhead.

The higher the uncertainty, the more valuable the options.
Open source video
Source video

Happy-path throughput vs. strict ordering

Benefit

Optimizing for the happy path improves throughput and responsiveness in distributed systems.

Cost or risk

Weakens strict transactional guarantees such as globally consistent two-phase commit ordering, shifting complexity to reconciliation and edge-case handling.

Optimizing for the happy path and throughput over strict latency and blocking order.
Open source video
Source video

Speed without alignment

Benefit

Faster execution on each side of a boundary appears productive.

Cost or risk

If the interfaces between levels never converge, additional speed amplifies waste and does not deliver the intended outcome.

If tunnels (organizational levels) don't meet, digging faster won't help.
Open source video
Source video

Persuasion via FUD and metaphor in proposals

Benefit

Framing proposals with needs, best practices, and metaphors makes them legible and persuasive to non-technical reviewers.

Cost or risk

The same framing can substitute rhetoric for evidence, biasing decisions toward emotionally salient rather than technically justified options.

FUD, best practices, and metaphors
Open source video
Source video

Local decision authority vs. central control

Benefit

Actors bearing the consequences make better-informed local decisions.

Cost or risk

Distributed authority creates divergence and coordination cost unless enablement, guidance, and shared constraints are deliberately maintained.

Team members living with the consequences are better equipped to make local decisions.
Open source video
Source video

Open questions

5

Can the value of specific architectural options be quantitatively estimated rather than argued qualitatively?

Why unresolved

The summary asserts that financial option pricing principles (Black-Scholes) apply to architectural decisions but provides no method, inputs, or calibration for that transfer.

Research direction

Build a model that scores an abstraction by estimated switching cost and probability distribution of future change, then test whether the scores predict which abstractions teams actually exercise.

Source video

When does centralizing a decision outperform delegating it to the actor with local context?

Why unresolved

The summary argues for local decision authority and against the central oracle but gives no boundary condition for when centralization remains correct.

Research direction

Compare centralized versus delegated decision architectures on the same workload, measuring decision quality, latency, and coordination overhead as a function of context locality.

Source video

Is there a repeatable procedure for extracting the underlying goal from a stated technical request?

Why unresolved

The 'boomerang' is described as a practice (ask Why?, What's the real goal?) without a specified elicitation protocol or accuracy measure.

Research direction

Design and evaluate a goal-inference step that converts requested solutions into candidate underlying objectives, measuring how often the inferred objective matches the requester's actual criterion.

Source video

Does multi-dimensional (vector) trade-off evaluation change decisions compared with scalar or binary framing?

Why unresolved

The claim that false dilemmas disappear under multi-dimensional analysis is asserted without any experiment demonstrating a decision change or better outcome.

Research direction

Present the same design scenario to practitioners under binary versus dimensional framing and compare the chosen designs and their measured properties.

Source video

How should model simplicity be selected when the target question changes over time?

Why unresolved

The summary states the best model depends on the question but offers no method for maintaining or switching between models as questions shift.

Research direction

Prototype a model registry keyed by question class and measure the accuracy/effort trade-off of swapping simplified models versus maintaining one high-fidelity model.

Source video

Key claims

8
causalVerification needed

Deferring a decision into the future has positive value, and that value increases with uncertainty.

Evidence

Options have positive value because they allow deferring decisions into the future.

Question

Can deferral value be measured in a software or agent-system setting, and does it increase monotonically with measured uncertainty?

Source video
comparativeVerification needed

Financial option pricing principles (Black-Scholes) apply to software architecture decisions.

Evidence

Black-Scholes option pricing principles apply to software architecture decisions.

Question

Which inputs of the Black-Scholes formulation have defensible analogues in architectural decisions, and does the analogy yield better decisions than simple heuristics?

Source video
comparativeVerification needed

Time and quality are separate dimensions rather than opposing ends of one axis.

Evidence

Time and quality are not opposites; they represent separate dimensions.

Question

Do real projects exhibit quality gains and schedule reductions independently, contradicting the assumed time-quality trade-off?

Source video
causalVerification needed

Simple models are more useful than complex ones because they abstract away unnecessary complexity.

Evidence

Simple models are the most useful because they abstract away unnecessary complexity.

Question

Does model simplicity improve decision quality versus higher-fidelity models on matched tasks?

Source video
causalVerification needed

The best model depends entirely on the question being answered.

Evidence

The best model depends entirely on the question you are trying to answer.

Question

Can a mapping from question class to optimal model abstraction be established empirically?

Source video
causalVerification needed

Actors who live with the consequences make better-informed local decisions than a centralized decision maker.

Evidence

Team members living with the consequences are better equipped to make local decisions.

Question

Does delegating decisions to consequence-bearing actors improve outcomes compared with centralized expert decisions, controlling for information availability?

Source video
causalVerification needed

If independently constructed interfaces between organizational levels do not meet, increasing execution speed does not help.

Evidence

If tunnels (organizational levels) don't meet, digging faster won't help.

Question

In systems with mismatched interfaces, does local performance optimization fail to improve end-to-end outcomes?

Source video
factualVerification needed

Stated technical requests can mask different, deeper operational goals.

Evidence

Requests like 'we need cloud-native' often mask deeper operational goals like resilience.

Question

How frequently do stated solution requests diverge from the requester's actual operational objective?

Source video

Connections

5