Apiumhub team (https://apiumhub.com/) has interviewed Sonya Natanzon to know more about her software architecture Journey.
Software architecture is an intersection of understanding technology and business so you can synthesize a technology solution for a business problem.
Communication, communication, communication No, seriously, communication is THAT important, and architect communications to all levels – from C-suite and product to developers and testers. If I break it down, there are three areas of communication:
- Inquiry – ability to listen while directing conversation in order to elicit critical information
- Visualization – communicating your ideas, soliciting and incorporating feedback.
- Advocacy or influence – ability to lead constructive discussions that lead to a decision or outcome
A software architect is half product manager, half people manager and half technologist. Yes, that’s three halves – software architect does 1.5 jobs.
- Mentor and train new architects. It’s always good to have peers
- Keep up with technology trends and continuously learn. You want to have all the tools in your toolbox and know when to apply which.
- Share information across the organization. Architect is a hub of information that many will benefit from!
I am a big fan of pragmatism in software architecture, but I don’t think pragmatism is at odds with innovation. Pragmatism is a great check on those who want to go after every new shiny technology or buzzword, but pragmatism also drives innovation. For example, we evolved from using bare metal to virtual infrastructure to the cloud for a variety of pragmatic reasons, such as scalability (without capital expenditures), simplifying deployments, etc.
5. What are your expectations regarding software architecture events, do you think in 2021 everything will be online?
I hope not. There is no substitute for in-person communication and making connections. While I expect a good part of the year will be online, I hope we will see a return to in-person conferences in the second half of 2021.
No. There is never one thing that solves all problems. In software architecture, it’s all about tradeoffs – what is right for your company or project at the time of implementation with existing constraints and drivers. Constraints and drivers will change over time, and so should the architecture to support the business. There is a case to be made for building a monolith if it fits within constraints and drivers – microservices are not always the answer
Buzzwords are great, but make sure the pattern really fits your need, don’t just choose it because it’s popular. I am a big fan of event-driven architecture, but what I discovered some time ago is that in healthcare, order of events is critical. If events are consumed out of order, complex workflows can break down and have undesired consequences. In the world of event technologies, order of delivery is not guaranteed, especially if these are events of different types, and you need to heavily augment either the architecture or the toolset in order to truly utilize events, and that augmentation can negate benefits of event-driven architecture.
8. What recommendation would you give to big international companies in terms of software architecture?
Don’t make architecture too centralized and heavy-handed by instituting review boards and committees. Instead, create a forum for architects to exchange ideas, give them direction and let them figure out the best way of operating with each other.
Don’t ignore software architecture entirely. Startups’ main objective is to move fast and figure out a market niche they can fill, which usually means a lot of rapid development with a high rate of change in direction – think MVP. When your direction stabilizes and you are ready to take your MVP to scale, this is a good time to assess gaps and think about architecture holistically, before your product becomes a patchwork of unmaintainable code with heavy support burden.
It can be difficult to convince non-software engineers that it’s needed and explain the benefits that it brings. Typical questions that I get are “How hard can it be?” and “Why does it take so long?” Be prepared to address both in a language that business understands and not in a techno-speak we engineers use among ourselves.
Your architecture should always support the business and fulfill business needs, whatever they happen to be. If you find yourself unable to tie a particular architectural initiative to business value, think twice – you may be doing technology for the sake of technology.
“A problem well stated is a problem half solved” said Charles Kettering. Spend some time refining a problem statement before you dive into solutions. All architects should know how to elicit a problem statement and what a good problem statement looks like. A problem statement never starts with “We need” – that’s a solution statement, not a problem. A good problem statement will contain good outcomes that aren’t happening, or bad outcomes that are. It sounds simple, but it takes practice and it is really worth the effort.
My name is Sonya Natanzon. I am a software architect in healthcare, and my solutions help improve patients’ lives. I always enjoy meeting fellow architects, so please feel free to reach out via LinkedIn
The post Software Architecture Journey: Interview with Sonya Natanzon appeared first on Apiumhub.