Interview with Sonya Natanzon
This week, we’re diving into a thought-provoking conversation with Sonya Natanzon, a seasoned engineering leader and software architect. Over the course of her career, Sonya has worked at the intersection of social and technical aspects of software engineering, experimenting with methodologies like Domain-Driven Design, Team Topologies, and the Architecture Advice Process to improve the way software is built and operated in the healthcare sector.
In this interview, Sonya shares insights from her journey, including the challenges and rewarding moments she’s experienced along the way. We discuss her unique approach to solving complex problems, her thoughts on the future of architecture, and how she balances creativity with the practical demands of large-scale systems. Plus, Sonya opens up about what inspires her work and offers some valuable advice for aspiring architects looking to make an impact in the field.
I'm excited to share this interview with you—it's filled with lessons, inspiration, and a fresh perspective on the role of architecture in today's rapidly evolving tech landscape. I can’t wait to hear what you think about Sonya’s insights, and as always, feel free to let me know if there’s someone you’d love to see interviewed next.
Where to find her:
What inspired you to become an architect?
I’m what they call an "accidental architect." As a software engineer, I often found myself responsible for building business-critical systems and had to figure things out on my own. This was before "software architecture" was a formal discipline. Over time, I realized I enjoyed solving problems that spanned multiple systems and business processes. When architecture became an official role, I naturally gravitated toward it.
Was there a defining moment or project early in your career that shaped your approach?
Early in my career, I worked on an online ordering system with a tight deadline. A colleague and I built it together, but after launch, he moved on while I continued maintaining the system. When I revisited his code to fix an issue, I found it challenging to traverse. Code was overly complex—layered with unnecessary abstractions, interfaces, and patterns. Eventually, I refactored it, reducing the codebase by 75% without losing any functionality. That experience taught me a crucial lesson: simplicity is more valuable than blindly following best practices. As long as code solves the problem and remains maintainable, excessive design patterns and abstractions often do more harm than good.
How would you describe your architectural philosophy in a sentence?
Keep it simple and pragmatic. I strive for the most straightforward solution with the fewest moving parts, focusing on solving the problem at hand rather than designing for hypothetical future use cases. I also remain skeptical of hype cycles to avoid solutions in search of a problem.
Can you walk us through how you approach a new design project, from concept to completion?
I start by clearly defining the problem, adding context, and validating it with stakeholders. Then, I create a high-level business process map and a high-level component map—each step or component may represent a complex process or system. These two perspectives are blended into a workflow view, which we refine iteratively. As we detail business processes and refine components, domain boundaries start to emerge, leading to a rough cut of component responsibilities and an initial vertical slice of functionality. From there, implementation and further iteration go hand in hand until we reach a complete solution. The key is ensuring business processes and technical design evolve together, validating each other, while keeping domain boundaries as wide as possible.
What’s the biggest challenge you’ve faced in a project, and how did you overcome it?
One of the biggest challenges is the bias toward solving a problem too quickly—jumping to solutions before fully understanding the problem. This is often compounded by personal biases toward specific solutions, whether it's something familiar ("to a hammer, everything looks like a nail") or something trendy ("resume-driven development"). Overcoming this requires skilled facilitation: guiding teams to first sharpen the problem statement, contextualize it, identify constraints, and then evaluate solutions with a clear focus on the actual need.
How do you balance creativity with practicality in large-scale projects?
Creativity is inherent to problem-solving, but every project operates within constraints—maintainability, security, budget, scalability, and so on. The best solutions emerge when creativity is channeled through these constraints. Rather than stifling innovation, constraints often lead to more elegant and practical designs.
What inspires you most in your work as an architect?
At my core, I love solving problems. Creating something that meets a need, works well, and is fun to use is deeply fulfilling. If I can solve a complex problem with a simple, elegant solution, even better. In the past decade, I’ve drawn inspiration from communities of practice where professionals share their experiences—it’s energizing to exchange ideas and continuously refine my approach.
Who or what has had the biggest influence on your thinking and approach to architecture?
Early in my career, I encountered well-known architects who developed their own methodologies. While their ideas were valuable, they presented them as rigid frameworks—"my way or the highway." That experience taught me two key lessons:
Form matters as much as function. Even great ideas won’t land if they’re delivered poorly.
No methodology is absolute. I don’t need to adopt any framework wholesale—I can extract what’s useful and apply it contextually. This shaped my "No Dogma" approach to architecture.
Later, I explored early software engineering books and realized that while technology evolves, fundamental challenges remain unchanged. Fred Brooks' The Mythical Man-Month and No Silver Bullet captured problems we still face today—reading these classics gives you a head start on tackling today’s real-world issues.
What trends do you think will define the next decade in architecture?
"Vibe coding"—where AI-assisted development enables rapid prototyping—will have a dual effect. In the early stages, it will reduce the need for engineers to build prototypes or even MVPs, where architectural decisions are less critical. However, as these applications grow, engineers will become even more essential for scaling, maintaining, and evolving them—precisely where strong architectural foundations matter most. Turning a vibe-coded prototype into a production-ready system may even become a specialized skill set in itself.
How AI is shaping modern architectural design?
AI is prompting a lot of discussion about the future of architecture, but it hasn’t fundamentally reshaped the field—yet. I see two areas where AI could have a major impact:
Design Validation: Imagine being able to ask AI, "Here’s a business problem. If I design a system like this, will it solve the problem? Will it scale? Will it meet quality attributes? What am I overlooking?" AI could act as a peer architect, helping validate designs before implementation or aiding in ideation before bringing it to human peers.
Production Insights: AI could analyze running systems to determine if they’re solving the intended problem efficiently, identify optimization opportunities, and detect early warning signs of failure. It might even surface new product opportunities.
For AI to truly enhance architecture, we need to structure our designs in ways that allow AI to provide meaningful insights.
What advice would you give to young architects just starting their careers?
Be curious beyond your immediate work. Balance technical expertise with business domain knowledge—the intersection of the two is where you can provide the most value.
If you could go back and give your younger self one piece of advice, what would it be?
Join or build a community of peers. You don’t have to learn everything alone—engaging with a community accelerates growth by exposing you to diverse experiences and perspectives.
What do you think about Dear Architects?
Curating amazing content weekly! Every issue I’ve read has contained something valuable.
What should Dear Architects improve?
Honestly, not much—maybe sprinkle in some engineering humor?
Sonya is a strategic engineering leader and software architect with extensive experience in healthcare and passion for helping patients through software. She is a decomplexifier. Her unique blend of business and technology knowledge helps her lead teams that deal with complex problems to simple an elegant solutions.
Sonya build and lead software development teams that specialize in medical device software, order-to-cash processes, laboratory solutions, system integrations and EMR/EHR interoperability.