In software development, writing clean code is only part of the equation. A software architect must rise above the code and think in terms of systems, evolution, constraints, and trade-offs. It’s not just how something should be built—but why, when, and to what extent.
A Good Architect Asks the Right Questions
Before designing or approving a feature, a thoughtful architect should assess it through a strategic lens. As Luca Mezzalira outlines in his talk, Thinking Like an Architect, these key questions help navigate design complexity:
-
What’s the rate of change of this feature?
Will it evolve rapidly or remain relatively stable over time? -
How will this feature evolve?
Think beyond the immediate version. Will this eventually need to support new user types, scale horizontally, or interact with new systems? -
How often have we changed it in the past 18 months?
Historical change frequency is a strong predictor of future volatility. -
What are the consequences of being too granular?
Over-engineering and microservices sprawl can introduce unnecessary complexity and maintenance overhead. -
What kind of traffic should this feature handle?
Estimating expected load—both average and peak—guides performance considerations and scalability design. -
Is this service latency-sensitive?
Does it sit on a user-critical path (e.g., checkout, sign-in), or can it tolerate delays (e.g., analytics pipelines)?
Strategic Depth: Additional Questions Architects Should Ask
Beyond the technical and evolutionary aspects, product and business alignment are crucial. Here are additional questions to deepen the context:
-
Where does this feature stand in our priority stack?
Is this a foundational requirement or an experimental nice-to-have? -
If priorities are unclear, how do we evaluate ROI?
Assess Return on Investment based on expected impact vs. implementation and operational cost.
These questions ground decisions in business value rather than technical excitement alone.
Product Alignment: Zooming into the “Why”
To anchor architecture into product goals, zoom in further with these guiding prompts:
-
Why is this feature important now?
Urgency should be justified by market demands, stakeholder needs, or technical imperatives. -
What KPIs are we aiming to improve?
Tying work to measurable outcomes (e.g., conversion rate, retention, system uptime) brings clarity and accountability. -
What is the MVP (Minimum Viable Product) for this feature?
Identify the smallest valuable version that can go to production and provide learning. -
What elements are absolutely mandatory vs. optional?
Distinguish between must-haves and nice-to-haves—a critical habit to avoid scope creep.
The Only Constants: Change and Trade-Offs
If there’s one principle architects should internalize, it’s this:
The only two constants in software architecture are change and trade-offs.
There is no perfect design. Only designs that are good enough—for now.
Adopt a Lean, Evolving Mindset
The best architectural decisions:
- Are made at the last responsible moment, not prematurely
- Balance risk vs. paralysis — don’t endlessly research or prototype when a timely decision is needed
- Favor high-level clarity early on (e.g., separation of domains, flow of data, boundaries of responsibility)
- Delay specific tooling decisions until real constraints emerge (e.g., use an abstraction before locking into Kafka or RabbitMQ)
Architecture is not a fixed blueprint; it’s a living organism. The art lies in knowing when to commit and how to evolve.
Final Thoughts
Software architecture is not just about scalability and reliability—it’s about contextual reasoning, product alignment, and adaptability. Thinking like an architect means becoming a system-level thinker, a translator between business and technology, and a strategist who thrives on trade-offs—not just a coder who structures classes.
Architecting is not a title. It’s a way of thinking.
Let me know if you’d like to convert this into a presentation, video script, or dev onboarding content.