Pitch & Stack

1. Introduction
2. Architectural Thinking
   2.1 The Relationship Between Architecture and Design, and Collaboration with the Development Team
       2.1.1 Traditional Approach: Separating Architecture and Design and Handing Them Down
       2.1.2 Making Architecture Work Through Bidirectional Collaboration
   2.2 The Relationship Between Technical Breadth and Depth
       2.2.1 From Developer Depth to Architect Breadth
           2.2.1.1 The Knowledge Pyramid
       2.2.2 Why Architects Need Technical Breadth
   2.3 Analyzing Trade-Offs Rather Than Chasing a Single Right Answer
       2.3.1 There Is No Single Correct Architecture, Only Trade-Offs
       2.3.2 Practicing Trade-Off Analysis: Clarifying What You Gain and What You Lose
   2.4 Understanding Business Drivers and Translating Them into Architectural Concerns
   2.5 Balancing Architecting and Coding
       2.5.1 How Architects Can Write Code Without Becoming a Bottleneck
3. Conclusion
4. TODO

1 Introduction

In the previous post, using Chapter 1 of Fundamentals of Software Architecture as a guide, I organized the following two questions:

• Question ①: What is software architecture?
• Question ②: What is the role of a software architect?

In that book, software architecture is defined through four dimensions, and the role of the software architect is explained as eight expectations.
On top of that, two “laws” are presented as common premises for architectural decisions: “Everything is a trade-off” and “Why is more important than How”.
In the previous article, I rearranged this framework into a form that made sense to me and answered Questions ① and ②.

Even after getting this far, however, another question still remains:

Question ③: What does it mean to “think like an architect”?
(= What kind of mindset and perspectives are needed to see things from an architectural point of view?)

If we line up these three questions in terms of abstraction, they look like this:

Question	Content	Abstraction
Question ①	What is software architecture?	Definition of the subject
Question ②	What is the role of a software architect?	Role of the actor
Question ③ (this post)	What does it mean to “think like an architect”?	Mindset and perspective

In this post, I read Chapter 2, “Architectural Thinking,” of Fundamentals of Software Architecture and tried to put my own understanding of Question ③ into words.

Here, I look at architectural thinking from the following four viewpoints:

• The relationship between architecture and design, and collaboration with the development team
• Technical breadth and depth
• Trade-off analysis
• Understanding business drivers and mapping them to architectural concerns

These are based on how Chapter 2 itself is structured. In this post, I’ll take those four viewpoints, unpack them in my own words, and use them to revisit how architects think and see the world.

2 Architectural Thinking

From here on, I’ll tackle Question ③: “What does it mean to think like an architect?”

As we saw last time, software architecture is defined through four dimensions,
and the role of the software architect is explained as eight expectations.
On top of that, the two laws—“Everything is a trade-off” and “Why is more important than How”―are presented as shared assumptions behind architectural decisions.

This framework is very useful for organizing “what we call architecture” and “what is expected of an architect.”
But in real decision-making situations, things often play out like this:

• Even for similar themes, the “reasonable answer” changes depending on the product phase, team skill set, and constraints.
• It’s rarely a clean “A or B” choice; more often, it’s about deciding “how far to lean toward A” and “how much to compromise on B.”

In other words, many architectural decisions are less about guessing a black-and-white right answer and more about choosing an acceptable trade-off point within the current context.

In other words, many architectural decisions are less about identifying a single correct solution and more about choosing a compromise point for trade-offs within the specific context of the moment.

In Chapter 2 of Fundamentals of Software Architecture, the theme is “architectural thinking”:
what it means to think like an architect and to see things from an architectural point of view. It presents four perspectives that support that way of thinking:

1. The relationship between architecture and design, and collaboration with the development team
2. Balancing technical breadth and depth
3. Analyzing trade-offs
4. Understanding business drivers and translating them into architectural concerns

Here, I’ll treat architectural thinking as:

Four capabilities that support how architects see the world and make decisions

1. The ability to understand the difference between architecture and design, and to make architecture work through collaboration with the development team
2. The ability to have both breadth and sufficient depth in technology, and to notice options and possibilities that others might miss
3. The ability to surface and analyze trade-offs across multiple options, and to reach workable compromises
4. The ability to understand business drivers and translate them into architectural concerns

Of these four capabilities, I’ll start with “the relationship between architecture and design” and “collaboration with the development team.”
That’s because where we draw the line between “architect” and “developer” changes the default assumptions behind everyday conversations and decisions in the first place.

2.1 The Relationship Between Architecture and Design, and Collaboration with the Development Team

Let’s start with the first capability: “the relationship between architecture and design, and collaboration with the development team.”
To make this relationship more concrete, I’ll first look at the common “upstream-to-downstream handoff” approach, and then contrast that with a more collaborative, bidirectional model.

2.1.1 Traditional Approach: Separating Architecture and Design and Handing Them Down

First, let’s look at the traditional model where architecture and design are neatly separated and “handed down” from upstream to downstream.

In this model, architects decide on architectural characteristics, patterns, and major components, package these decisions into deliverables, and hand them over to the development team. The development team then uses those deliverables as a foundation to proceed with detailed design and implementation.

In this approach, information tends to flow in a single direction—from architect to development team.
As a result:

• Gaps easily emerge between the architect’s intent and the actual code and design.
• Insights and constraints discovered during implementation don’t easily flow back into the architectural side.

A “wall” ends up forming between architecture and code, and over time they drift further apart. Once they start diverging, it becomes progressively harder to bring them back into alignment as things change.

2.1.2 Making Architecture Work Through Bidirectional Collaboration

In contrast to this traditional “top-down handoff” approach, making architecture actually work requires removing that wall between architects and the development team.
Instead of treating architecture as something “designed and handed over,” the premise needs to shift to: “we build it together as members of the same team.”

Architects and developers operate as a single team, continually exchanging decisions and feedback in both directions.
By doing so:

• You can continuously align architectural intent with the detailed design and code produced day to day.
• You can feed insights and constraints discovered during implementation back into architectural decisions.

When architecture and code evolve together as one, it becomes much easier to adapt to change.

Once architects and developers start interacting as a single team like this, the next question becomes: What kinds of options and perspectives do you actually bring into those conversations?
That’s where the next topic comes in: the “technical breadth and depth” expected of architects.

2.2 Balancing Technical Breadth and Depth

An architect’s strength isn’t just in their ability to “do the work” hands-on, but in their ability to say, “Given these goals and constraints, here are the viable options and what each is good at,” and present those options to the team.

To do that, it’s not enough to be deeply knowledgeable about one particular technology. You also need sufficient “breadth” to compare multiple technologies and patterns side by side.

So how should an architect balance technical breadth and depth?
Here, I’ll look at how the emphasis on “depth” and “breadth” shifts when you move from a developer role to an architect role.

2.2.1 From Developer Depth to Architect Breadth

Developers are expected to have technical depth: digging deeply into specific languages and frameworks.
Architects, on the other hand, are expected to have technical breadth: a cross-cutting understanding of a variety of technologies, frameworks, and tools.

To explain this difference, the book introduces the idea of a “knowledge pyramid” and explains that, depending on your career stage, the layers of knowledge (depth/breadth) you should emphasize change.
When your role shifts from developer to architect, the layers you thicken and where you consciously widen begin to change.

To get an intuition for that shift, let’s look more closely at this “knowledge pyramid.”

2.2.1.1 The Knowledge Pyramid

The knowledge pyramid is a simple map that helps you reflect on where your technical knowledge is concentrated.

You can think of all your knowledge as falling into one of three levels:

Three levels of knowledge in the knowledge triangle

1. Stuff you know
   • Technologies, frameworks, languages, and tools you actually use and are comfortable with in your day-to-day work.
   • Example: programming languages you write in regularly at work, or the frameworks you rely on all the time
     (the book gives examples like Java, .NET, DDD, Agile, etc.).
2. Stuff you know you don’t know
   • Technologies and concepts where you know the name, the general idea, and the use case, but you can’t really use or explain them yourself.
   • Example: you know the name and general use cases of “machine learning” as a field, but you’re not able to design or implement models yourself.
3. Stuff you don’t know you don’t know
   • Technologies, tools, frameworks, and languages you don’t even know exist, so they’re completely outside your awareness.
   • This is the largest section of the triangle, and it includes potential solutions that might actually be the best fit for your problem.
   • Example: a brand new middleware or database you’ve never even heard of (the book jokes that as soon as you give a concrete example, it moves into “things you know,” so it can only write “Example: Don’t know ;-)”).

For architects, technical breadth grows by expanding the layers of “stuff you can actually use (1)” and “stuff you at least know by name and purpose (2),” and by gradually shrinking the “stuff you don’t know you don’t know (3).”

So why go to so much trouble to broaden your technical “breadth” in the first place?
The next section summarizes the reasons for this.

2.2.2 Why Architects Need Technical Breadth

An architect’s job isn’t to master a single favorite technology; the real value lies in surveying diverse technologies, patterns, and platforms and combining options that best fit the given constraints and business needs.

Because of that, it’s more useful for an architect to know that:

“There are at least several ways to solve this problem, and here’s what each is good at,”

than to be a deep specialist in just one particular technology.

This means that, even at the cost of letting some of your previous specialization become a little shallower, you’re expected to intentionally broaden the layers of “stuff you know” and “stuff you know by name” (the upper and middle parts of the knowledge pyramid).

By broadening your technical breadth like this, you gain the ability to line up multiple options for a given problem and compare them.
This, in turn, becomes the foundation for the next topic: trade-off analysis.

2.3 Analyzing Trade-Offs

Once you have both breadth and depth, you can see many design options and technical choices for a given problem.
The next capability you need is the ability to decide which compromise best fits the current context.

In this section, I’ll clarify how trade-offs work in architecture and outline the basic steps for actually performing a trade-off analysis.

2.3.1 There Is No Single Correct Architecture, Only Trade-Offs

In software architecture, every option has both strengths and weaknesses.
An architect’s job is not to discover some timeless, universally correct design, but to compare trade-offs and choose what best fits the current context.

In other words, there is no eternally correct answer in architecture—only trade-offs.
So it’s no surprise that the answer to most architectural questions ends up being “it depends.” The best choice depends on factors like business goals, environment, budget, schedule, organizational culture, and team skills.

However, simply accepting the premise that “everything is a trade-off and the answer depends on the situation” doesn’t yet tell us how to behave in day-to-day design and review discussions.

In the next section, I’ll look at how to actually conduct trade-off analysis by writing down what you gain and what you lose with each option.

2.3.2 Practicing Trade-Off Analysis: Clarifying What You Gain and What You Lose

When you actually perform a trade-off analysis, the basic move is to write down, for each option:

• What do we gain?
• What do we lose?

Then, based on that, you choose which compromises are acceptable for “this system, in this environment, with these business goals.”

For example, imagine choosing between using a topic (Pub/Sub) or a queue (point-to-point) for communication between services in a bidding system:

Approach	What you gain	What you lose
Topic (Pub/Sub)	– High extensibility (you can easily add new services later)- Loose coupling between services (the publisher doesn’t need to know who will consume the messages)	– Anyone can subscribe to messages, increasing the risk of data access or security concerns- All services tend to be constrained to the same message format (contract)- It’s harder to do service-specific monitoring, programmatic load balancing, or autoscaling
Queue (Point-to-Point)	– Each consumer can have a different contract (each service can receive only the data it needs)- Security, monitoring, and scaling (like queue-level autoscaling) are easier	– The sender needs to know “which queue to send to,” increasing coupling between services- Adding new functionality or services often requires changes to queues and wiring

You could say that trade-off analysis is:

“The act of choosing which disadvantages you’re willing to accept, in order to gain the benefits you need within the constraints you have.”

What matters is that which gains/losses carry more weight can’t be decided by technology alone.
For the same option, one product might choose it because its scalability advantages are compelling, while another product might reject it because the cost or schedule-related downsides are fatal.

What prioritizes “what to pursue and what to give up” are the movements and decision criteria on the business side—business drivers.
The fourth capability of architectural thinking is about how to bring those business drivers into architectural decision-making.

2.4 Understanding Business Drivers and Translating Them into Architectural Concerns

In my notes, I summarized the fourth capability of architectural thinking like this:

Business drivers: mapping business motivations and goals to architectural characteristics.

I can see the label—“the ability to understand business drivers and translate them into architectural concerns”—but I’m not yet organized enough to explain this content in my own words.

The book treats this topic in detail in Chapters 4–6 (defining, identifying, and measuring architectural characteristics).
In this note, I’ll simply record the fact that “the ability to connect business drivers to architecture” is the fourth capability of architectural thinking, and leave organizing its concrete contents as future TODO work.

Once we include business drivers, and have taken a tour of all four capabilities of architectural thinking, another practical question arises:

How should architects actually relate to code in their day-to-day work?

That’s where the balance between “architecting” and “coding” comes in.

2.5 Balancing Architecting and Coding

To what extent should architects be involved in design and implementation?

Architects need to stay involved in code to some degree so they don’t lose their feel for the field and their technical depth.
At the same time, they must not become a bottleneck for the team.

If an architect stays completely away from code, their decisions lose the feel of what is actually happening on the ground.
But if they personally own the framework code or the implementation along the critical path, they themselves become the bottleneck for the team.

So what does a sustainable way of owning code look like for an architect in practice?
In the next section, I’ll look a bit more concretely at how to “write code without becoming a bottleneck.”

2.5.1 How Architects Can Write Code Without Becoming a Bottleneck

When architects get involved in implementation, what they want to avoid is the “bottleneck trap”—personally owning framework or critical-path code and becoming the bottleneck for the entire team.

To avoid that, it’s recommended that implementation along the critical path be handled by the development team, while the architect spends their coding time on “non-critical but still meaningful” work.
Concrete examples include:

• Small feature development that can be completed in 1–3 iterations
• Proof-of-concept (PoC) code
• Stories related to paying down technical debt or improving the architecture
• Bug fixes and small automation scripts
• Regular code reviews

By taking on work like this, architects can contribute to the codebase without holding the team back.
Working with real code helps them maintain technical depth, while steering clear of critical implementations gives them the space to maintain the “breadth” needed to watch over the overall structure and trade-offs.

5. Conclusion: My Current Answer to Question ③

In this post, I tried to organize my own answer to Question ③—“What does it mean to think like an architect?”—using Chapter 2 of Fundamentals of Software Architecture as a guide.

If I had to summarize my current answer in a single sentence, “thinking like an architect” means:

• Using the framework from Chapter 1 (four dimensions, eight expectations, two laws) as a foundation, and
• Applying the following four capabilities (+ a conscious balance with coding) to turn that framework into concrete design decisions.

As we’ve seen, those four capabilities can be summarized as:

1. The ability to understand the difference between architecture and design, and to make architecture work through collaboration with the development team (2.1)
   Rather than a one-way “upstream-to-downstream handoff,” architects and developers interact as one team, continually communicating in both directions to keep architecture and code aligned.
2. The ability to have both broad and sufficiently deep technical knowledge, and to notice multiple options and possibilities (2.2)
   Not just depth in a particular stack, but also breadth: by consciously expanding the upper and middle layers of the “knowledge pyramid” (“things you can actually use” and “things you at least know by name”), you become able to lay out multiple ways to solve a problem side by side.
3. The ability to surface, analyze, and reconcile trade-offs across multiple options (2.3)
   Instead of searching for a universal right answer, you list out what you gain and what you lose with each option and choose which compromises are acceptable for this system, in this environment, with these business goals.
4. The ability to understand business drivers and translate them into architectural concerns (2.4)
   The motivations and priorities on the business side influence which architectural characteristics should be emphasized. This “bridging ability” is positioned as the fourth capability, though at this point I’ve only clarified the label and haven’t fully organized the concrete contents in my own words yet.

Alongside these four capabilities, Chapter 2 also touches on balancing architecting and hands-on coding as a supporting premise (2.5).

• If you move too far away from code, you lose your feel for the field and your technical depth as an architect.
• But if you personally own framework or critical-path code, you risk becoming a bottleneck for the team.

By leaving critical implementations to the team, and instead staying in touch with the codebase through PoCs, small features, technical-debt work, bug fixes, and scripts—“non-critical but meaningful coding”—you can maintain “enough depth” while also preserving the “breadth” needed to see the whole.

At this point, I feel I’ve managed to connect, into one continuous picture:

• The framework from Chapter 1: four dimensions, eight expectations, and two laws, and
• The architectural thinking framework from Chapter 2: four capabilities + the distance from code.

On the other hand, there are still areas I haven’t fully organized in my own words, such as:

• How to derive concrete architectural characteristics from business drivers (the content of Chapters 4–6), and
• How to actually apply trade-off analysis and the knowledge pyramid in my own projects.

I’d like to dig into these in separate notes (TODOs) as I read further into the book and gain more practical experience.

TODO

• Organize and be able to explain in my own words “the ability to understand business drivers and translate them into architectural concerns.”
  • Defining, extracting, and measuring architectural characteristics
• Organize concrete examples from my own projects of:
  • How I’ve done trade-off analysis
  • How I’ve used the knowledge pyramid in practice