Sonya Natanzon
Solution architect at Guardant Health
San Francisco, California, United States
Actions
Sonya is a solutions architect at Guardant Health. Her passion is helping patients by building excellent software.
She has worked in a number of different industries, but she always returns to healthcare. In addition to building software, she enjoys building effective software teams and driving improvement in software development processes in this highly regulated industry.
Area of Expertise
Topics
So You Think You Might Be a Software Architect
We all hear title “Software Architect”. It consistently makes the list of the most highly paid technical jobs. But what does it mean to be a software architect? What does a software architect do? And how do you become one? Perhaps someone gave you the title, but you are not sure what’s expected of you. Or perhaps you suspect you might already be doing a job of a software architect, but can’t quite pinpoint how you made the leap or explain it to others.
In this talk, I will define what a software architect does, and what skills you need to go from a senior developer to an architect.
Pragmatic Approach to Architecture Metrics
A question we have all heard is: “How do you measure success?” Those metrics can look different for different industries or professions, but they are rooted in hard measurable outcomes: larger revenue for a bank, bigger market share for an automaker, reduced readmission rate for a hospital chain. Those numbers are easy to put on a chart in an executive presentation. But what about software architecture? Measuring success of software architecture is difficult because software architecture is all about long-term effects, positive or negative. Software architecture metrics are hard to define and even harder to evaluate objectively. As soon as a metric becomes a goal, it ceases to be a good metric (think “number of lines of code”). And we know all too well that software architecture is subject to frequent changes - no other industry moves as fast. However, we still need to be able to set goal posts, measure outcomes and present them to executives - in a practical way.
As Eliyahu Goldratt famously said, “Tell me how you measure me, and I will tell you how I will behave”. Focusing on low-level metrics can do more harm than good. A metric’s value becomes the end goal, rather than achieving the desired business outcomes. To fix this, let’s reverse the process. We are going to start by defining the business outcomes we want to achieve. The outcomes we are going to focus on are the ability to run a cost-effective system and ability to evolve it quickly and easily. Foundational to those objectives is the capacity to manage the complexity of the system. In this talk, we are going to explore several simple and pragmatic approaches to architectural metrics that support the required business outcomes.
Architect’s Survival Guide to Healthcare
Healthcare is a multi-trillion dollar industry, with a complex ecosystem of patients, providers and payers, entwined by diverse systems and a shifting regulatory landscape.
Healthcare is no longer local; laboratory tests cross borders and radiology reading is outsourced offshore. While overwhelmingly complex, healthcare is also one of the most rewarding industries to work in, making direct impact to the lives of patients. Sonya will dive into the complexities that an architect in healthcare faces and ways to address them to create robust solutions and improve patients’ experience.
Understanding typical challenges of the healthcare industry
Using techniques of Domain Driven Design to shape solutions
Managing cross-cutting concerns, such as patient safety, data security and regulatory compliance
Supporting ancillary business functions, such as audits
It’s a Feature, Not a Bug: A Step-by-step Guide to Architectural Decisions
Have you ever had this argument about existing code, when someone is trying to prove to you that you have a bug, you are arguing that it is a feature, and both sides realize (after extensive archeological dig through existing documentation) that the reasons behind this code’s functionality have been lost to time?
The better question is not “have you ever”, but “how often have you had this argument”. All architects experience this at one time or another, wondering what were the motivations for a decision, what were the assumptions or constraints at the time, and was there an explicit decision to begin with. While we all recognize how important decisions are in software architecture, we don’t often have a framework for identifying and making architectural decisions.
In this talk, I will introduce a step-by-step guide that will help you identify, frame and make decisions about your software architecture that will leave no room for “it’s a feature, not a bug” arguments.
KanDDDinsky 2023 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top