You don’t need to be an architect to think like one – and doing so makes you a better developer, produces more effective systems, and accelerates your career.
Architectural thinking is a learnable skill composed of three competencies:
- translating business drivers into architecture characteristics,
- expanding your technical breadth,
- and rigorously analyzing trade-offs.
Mastering these three areas lets you see problems through an architect’s lens and make fundamentally better decisions, regardless of your title.
Laws & Principles (Quick Reference)
| Principle | Implication |
|---|---|
| Everything in software architecture is a trade-off | No solution is universally “best” |
| If you find something that isn’t a trade-off, you haven’t looked hard enough | The First Law has no exceptions |
| No structural best practices exist | Every decision is contextual |
| Process best practices DO exist | Collaborate, use ADRs, document decisions (but to find it, you need to increase technical breadths) |
| The Out of Context Trap | Never evaluate trade-offs without your specific context |
| The Triangle of Knowledge | Career growth = expanding “stuff you know you don’t know” |
| The Maintenance Tax | Skills you don’t maintain decay — be deliberate about what you keep |
Translating Business Drivers
Every business concern maps to specific architecture characteristics. These characteristics are the driving forces behind all structural decisions.
- User Satisfaction translates to: performance, scalability, availability, security, testability, recoverability, agility. Users don’t say “we need fault tolerance” — they say “the app should never go down.” The architect hears the underlying characteristic.
- Time to Market translates to: maintainability, testability, deployability. Speed of delivery isn’t just about coding faster — it requires easy-to-change code, complete test coverage, and low-ceremony deployments. All three must work together; removing testing to go faster will destroy your company.
- Mergers & Acquisitions translates to: interoperability, standards compliance, scalability, openness. When your company acquires another, you may instantly double your user base. Can your connection pools, VMs, and databases handle it?
These characteristics can come from several sources — and the most valuable is simply listening
- The domain itself — A stock trading system obviously needs high performance and data integrity. No deep analysis required.
- Requirements & user stories — But they’re never explicit. “Support 20 to 200,000 concurrent users” is an elasticity requirement in disguise. You must interpret it.
- Listening to the business — The most valuable source. When stakeholders articulate their priorities in plain language, the architect’s mental translation engine converts those words into the specific characteristics the system must support.
Fundamentals of Software Architecture have an evaluation tool of 8 architectural styles against characteristics like scalability, performance, etc. This is a nice practical chart to evaluate options. Although the characteristics are provided, they may not be equally important in real world scenarios. An example, if you’re a cost-conscious startup needing simplicity, a monolith is the correct starting point.
Architects have Wide Technical Breadths
Expanding your technical breadth — not just depth — lets you see more and better solutions.
Fundamentally architectural decisions is about evaluating options. The limiting factor of the amount of options you see is YOU. You can only choose from solutions you know exist. If you only know one caching technology, one messaging pattern, one architecture style, you’ll apply it everywhere — even when it’s the wrong fit. Broadening your awareness of what’s out there is what separates senior developers from architects and enables better problem-solving at every level.
The Triangle of Knowledge defines three layers, and your career strategy should target the middle layer.
- Layer 1 – Top (smallest): “Stuff you know” — Technologies you use daily and could teach. This is your technical depth.
- Layer 2 – Middle: “Stuff you know you don’t know” — Technologies you’re aware of but can’t use. You’ve heard of Clojure and know it’s functional, but you can’t write a Clojure program.
- Layer 3 – Bottom (largest): “Stuff you don’t know you don’t know” — The vast ocean of tools, patterns, and products that would be a perfect fit for your problem, and you’ve never even heard of them. This is the most dangerous layer.
There’s a trade off in keeping layer 1 (the stuff you know) in engineering. And that is you need to maintain them. Transitioning from Senior Developer to Junior Architect, requires sacrificing some of the layer 1 technical depth and increasing layer 2 technical breadth. (Unless you don’t have family, relationships, pets, and have all the time in the world)
Everything Is a Trade-Off — Analyze Them Rigorously
There are no general “best practices” in the structural dimension of software architecture. Every choice has pros and cons. Developers tend to see only the benefits; architects are trained to see both sides. Without rigorous trade-off analysis, you’ll make decisions based on enthusiasm or incomplete information.
Anti Pattern 1 – The “Out of Context Trap” is the most dangerous anti-pattern in trade-off analysis.
Shared library vs. shared service comparison.
On a generic scorecard, shared library “wins” 5-to-2 across five criteria (versioning, change risk, and performance favor it). But when surfacing the context — polyglot environment (4 languages), frequently changing shared code, performance not a concern — the only criteria that matter favor shared service, flipping the score to 0-to-2.
The lesson: Never make decisions using generic scorecards without filtering through your specific context. If a criterion doesn’t matter to your situation, weight it at zero. A criterion you don’t care about should have no bearing on your decision, regardless of which option it favors.
Anti Pattern 2 – Avoid over-evangelizing technology — it hides trade-offs.
“Developers know the benefits of everything and the trade-offs of nothing.” When someone gets excited about a technology (“gRPC gives 10x performance!”), they inadvertently bury the downsides. The First Law guarantees those trade-offs exist — enthusiasm just makes them invisible. Before recommending any technology, force yourself to articulate its downsides. This is why architects are always “grumpy” — they can’t get excited about anything because everything has a trade-off.
Action Items:
- Spend 20 minutes everyday focusing only on yourself before work or emails. Check the latest tech news
- Visit below resources that highlights interesting radar technologies
- Next time your interested in a technology, list 3 down sides of it.
References:
Coffee Break 
Leave a comment