Requirements Analysis for Architects: A Conversation with Sonya Natanzon

Introduction to AI in Production and Engineering Leadership

• Many engineering teams are currently navigating the gap between having AI running in a proof of concept and running it reliably in production, with QCon AI Boston bringing together senior engineers and technical leaders to share their experiences and patterns that have scaled 10s.
• The guest, Sonya Natanzon, is a seasoned engineering leader and software architect who experiments with various methodologies to improve building and operating software in the healthcare sector, and she became an architect by taking on progressively larger projects and realizing her work was more about understanding the big picture 2m6s.
• Sonya considers herself an "accidental architect," a term coined by Mark Richards, as she didn't set out to be an architect, but rather evolved into the role as she took on larger projects and realized the importance of understanding the whole system 2m6s.
• Two key revelations struck Sonya as she took on the architect role: first, technology is not as important as technologists think, and what matters most is creating something that works for the user, and second, understanding the business is crucial, as software engineers and architects need to comprehend how the business works and makes money 4m42s.

The Role and Evolution of an Engineering Architect

• Sonya emphasizes the importance of understanding the business and being able to explain technical things to business folks and business concepts to technical people, a concept also highlighted by Gregor Hohpe's statement about the elevator architect 6m15s.
• The process of requirements analysis is a challenging and continuous conversation, with no single meeting or time where all requirements can be elicited, and Sonya has found that it's essential to have ongoing discussions to understand what clients really want 10m10s.
• Requirements analysis is a constant process that involves not only soliciting requirements but also shaping behavior, and this process can be influenced by the malleable nature of software technology, which can shape user behavior and make them do things they want 10s.
• The process of requirements analysis requires trying many different things, listening, and drawing conclusions, as well as playing things back and representing what was said in different ways to ensure understanding, and words can be valuable but also ephemeral if not recorded or documented 2m6s.

Challenges in Requirements Analysis and Communication

• Language can be ambiguous and open to interpretation, which can be useful in human interaction but not in computer systems, and to address this, there needs to be a continual conversation to model out exactly what people mean by certain terms, such as "fast" or "organized" 42s.
• The concept of ubiquitous language in domain-driven design can help establish a shared language between technical and business teams, and this language can be influenced by the platforms used, and people tend to think better in relative terms rather than absolute terms 2m6s.
• Constraints can be beneficial in the design process, as they can help guide the design in a certain direction and prevent analysis paralysis, and constraints can be seen as a type of requirement that shapes the design, and having a completely open field with no constraints can be difficult to work with 2m6s.
• Working with constraints is beneficial as it helps shape the design of a system, and regulatory constraints can be particularly useful in defining the boundaries of a project, such as isolating certain algorithms to prevent them from affecting each other 10s.
• To identify constraints, it is essential to establish a ubiquitous language that allows business and technical people to communicate effectively, ensuring that technology people understand the business requirements and do not perceive them as arbitrary 1m2s.

Workshops and Ubiquitous Language in Domain-Driven Design

• Workshops can be an effective way to bring business and technical people together to find constraints and develop a ubiquitous language, and these workshops should be well-attended, even if some participants may be bored at times 2m6s.
• A well-crafted problem statement is crucial, and it should contain either good outcomes that are not happening or bad outcomes that are, and it is essential to distinguish between problem statements and solution statements, which often start with "we need" 3m15s.
• To convert a solution statement into a problem statement, it is necessary to ask questions like "What is the useful outcome that you're trying to accomplish?" to understand the underlying problem and identify the constraints and requirements 5m30s.
• Once a problem statement is established, it is possible to start identifying constraints and requirements, and this process can help to ensure that the solution is aligned with the business goals and outcomes 6m45s.

Problem Statements and Constraints in Design

• Having a clear problem statement also allows for the evaluation of whether the solution has achieved the desired outcome, and it provides the opportunity to consider alternative solutions and approaches 8m10s.
• The use of problem statements and constraints can sometimes conflict with "best practices" or established ways of doing things, and it is essential to balance the need for standardization with the reality of the current situation and the business goals 10m30s.
• Best practices are useful in assuming they exist, and can be applied by utilizing a reference architecture that has been proven to work, but it's essential to keep the context in mind and be willing to adjust or change them as needed, because every situation is unique 10s.
• The context of a problem is crucial, and even if a solution has worked before, it may not work in a new situation due to differences in technology, regulations, or other factors, requiring architects to think of new ways of doing things 42s.

Context and Domain-Driven Design in Practice

• Understanding the context comes from domain-driven design, which involves understanding the totality of the business and being able to draw pieces of it that need to be addressed, and having the capacity to zoom in and out of different levels of complexity 2m6s.
• Domain-driven design is a skill that allows architects to bound the context without losing the bigger picture, and it's a powerful idea that can be applied in practice, even if team members are not familiar with it 2m6s.
• When working with teams, it's not necessary to explicitly teach domain-driven design, but rather to facilitate the use of its concepts and techniques, such as event storming, and to encourage collaboration and communication between business and technical people 4m10s.
• Creating an ubiquitous language, or a glossary of terms, is an important part of domain-driven design, and can be done implicitly by getting people to talk to each other, or explicitly by writing a glossary and defining key terms 6m30s.
• Eric Evans's book is a resource that some team members may find useful in internalizing domain-driven design concepts, but it's not necessary to read it to apply the concepts in practice 5m40s.
• The idea of implementing domain-driven design without explicitly stating it can be beneficial, as presenting it directly to someone may result in resistance due to the perception of it being another methodology that gets in the way of coding, and this approach can help get both design and implementation going 10s.

Thinking Over Typing and the Role of AI in Engineering

• Engineers should spend more time thinking and less time typing, focusing on creating good designs and elegant solutions that do not require excessive code, and with the help of AI tools, there is now more space for engineers to think and figure out what they want to accomplish 2m6s.
• The introduction of agentic AI raises questions about the role of architecture and how to communicate with these AI systems, including defining agents and their place in the architecture, and assuming that the trust issue with AI-produced code can be overcome, the focus shifts to how to integrate AI coders into the development process 4m42s.
• As long as AI coding remains fundamentally for humans, the architecture will likely remain the same, with a focus on conceptual definitions, boundaries, and modularization, but if code is written entirely for machines, it could potentially be simplified to just machine code 8m15s.
• The use of AI tools for coding raises concerns about how to train junior developers, as the tasks that junior developers used to perform may now be automated, and senior developers may become more effective with the help of AI tools, but this could create a gap in the skills and experience of junior developers 12m10s.

Code Review, Intuition, and the Impact of AI on Development

• The use of tooling in development is constantly evolving, with bigger and better tools replacing older ones, such as punch cards, and junior developers can use these tools to perform more rote work as long as they can explain what was done 10s.
• Reviews of code, including agentic code, are still an essential part of the development process, and being able to explain why things were done in a certain way and making changes as needed will be a key skill for developers 42s.
• The development of intuition about how systems work is crucial, and this intuition is gained through experience and understanding where abstractions break down, which can be lost when working with agentic tools 2m6s.
• There is a concern that working with agentic tools could lead to deskilling, but when things don't work as expected, developers will have to find the right answers and explore different options, which can help them gain intuition and come back to best practices 4m30s.
• Personal experience and stories, such as the one about a project involving parsing a Google Sheet, illustrate the importance of finding the right level of skill and intuition to address specific problems, and how agentic tools can be used to assist but not replace human judgment and expertise 6m15s.

The Evolving Nature of Software and Architectural Specialization

• The nature of software is constantly evolving, with new problems being addressed using yesterday's tools, and this trend is likely to continue, requiring adaptability and innovation 10s.
• As software development advances, there will be a need for more narrow specializations, and architects will have to understand enough about various aspects, such as hardware, to build effective tools and interfaces 42s.
• Artificial intelligence will only be as good as the data it is trained on, and when tackling novel problems, humans will need to work through the issues themselves before training AI models 1m6s.

The Creative and Challenging Aspects of Being an Architect

• The favorite part of being an architect is seeing a solution emerge through conversations and collaboration, where all the requirements, problem statements, and opinions come together and people agree on a way forward 4m6s.
• The least favorite part of being an architect is trying to convince people to look at things from different perspectives, which can be challenging due to personal biases and experiences 5m30s.
• Being an architect can be a creatively fulfilling experience, as it involves coming up with innovative solutions and distilling complex problems into useful practices, making it a creative pursuit 7m30s.
• The misconception that software engineering is boring and uncreative is inaccurate, as it allows for the creation of new and innovative things, and architecture is a key part of this process 9m6s.
• Striking a balance between being high-level and technical enough can be challenging, and being in a middle zone can be isolating, as it can be difficult to align with either the technical or executive group 10s.

Community, Tooling, and the Architect's Influence Beyond Software

• Microsoft has been successful in keeping developers happy with their tooling, and their technologies have been well-regarded, although the landscape is constantly changing 2m6s.
• The community of practice in architecture is valued, as it provides a space for people to share knowledge, materials, and feedback, and to learn from one another, particularly in terms of breaking down complex problems and keeping the big picture in mind 4m30s.
• The overwhelming number of technology options can be exhausting, and selecting one option over another with slight differences can be a daunting task 6m15s.
• Outside of being an architect, applying skills to other areas such as gardening or working with high school students can be rewarding, and it is hopeful to see young people embarking on their career paths 8m45s.
• As long as one stays in engineering, the skills and knowledge of being an architect will always be expressed in some way, and it is essential to be mindful of this when leading teams and to allow them to make their own choices 11m10s.

The Ultimate Goal of Seamless Technology and Silent Success

• When a project is complete, the best feedback from clients or teams is often "nothing," meaning that the technology or solution is working seamlessly in the background, allowing people to accomplish their goals without issues 13m40s.
• The concept of "silence is praise" is agreed upon, implying that when technology is working correctly, it should not be noticeable, and that is the ultimate goal 15m0s.