Requirements Analysis for Architects: A Conversation with Sonya Natanzon

Transcript

Michael Stiefel: Welcome to the Architects Podcast, where we discuss what it means to be an architect and how architects actually do their job. Today's guest is Sonya Natanzon, who is a seasoned engineering leader and software architect, working at the intersection of social and technical aspects of software engineering. She experiments with various methodologies such as Domain-Driven Design, Team Topologies, Architecture Advice Process, and others to improve building and operating software in the healthcare sector.

She speaks about the outcomes at international software conferences and meetups. It's great to have you here on the podcast, and I'd like to start out by asking you, how did you become an architect? It's not something you decided one morning you woke up and said, "Today I'm going to be an architect".

Becoming an Architect [01:25]

Sonya Natanzon: No, not at all. And thank you for having me here. I am what they call an accidental architect. I think Mark Richards was the one who coined that term, and it really resonated with me. It's not something I set out to be. It's not something that was even a term or a role when I started out in software engineering. But what I observed is with my work as a software engineer, I took on progressively larger and larger projects. And at some point realized that my work is really more in putting pieces together, understanding the big picture, understanding how the whole thing is supposed to hang together. And there wasn't really a word for it. And when I heard software architect, I thought, "Yes, that really fits".

Michael Stiefel: When you started taking on this role, I imagine you sort of evolved into it. What struck you the most that people were not doing right? Was it technical? Was it political? Was it social? The intersection of all these things?

Prioritize the Business Over the Technology [02:44]

Sonya Natanzon: Two things struck me, and they were revelations in succession. First, technology really is not as important as we technologists seem to think. If I made something for the user that works with a bunch of hamsters in a wheel and they're happy, that really is all that matters. They don't see those hamsters, I get to feed them, things work, great. And that was revelation number one. I thought, "Ooh, I need to talk about technology less and talk about what I'm trying to accomplish more". And the second one really is how much we need to understand the business. And what I find very interesting about this is, time and time, role after role, I noticed that no one in the business really wants to understand how software is built, but we software engineers and architects really need to understand the business. So this relationship is definitely not a two-way street, but if we underestimate the importance of understanding what the business is, how it works, where it makes money, how do we get users, not lose users. We fail as architects because we can really direct things towards those business outcomes.

How to Get the Business Requirements [04:14]

Michael Stiefel: The well-known statement of Gregor Hohpe about the elevator architect, that you have the ability to explain the technical things to the business folks and the business stuff to the technical people. And it's amazing to me how difficult it is for people to express what they really want. I've said this over and over again during my software career. I've only done three things, trade off space and time, insert levels of indirection, and trying to get my clients to tell me what they really want, which introduces the interesting sort of topic that people don't talk about, which is requirements analysis. And how do we actually go about this process? And what are the ways that you have found that it's best to get people to tell you what they really want?

Sonya Natanzon: Oh, that's a tough question. I think it's a continuous conversation. There isn't a single time, a single meeting that you could have where you elicit that. It is a constant process. And I would argue at times that it's not just soliciting a requirement, soliciting behavior, but also shaping it in a way. We, by nature of this really malleable technology called software, can actually shape behavior and make users do things that they want. And there's some value in saying, "We're not just going to ask a question", because sometimes users will not know what they want, "But we're going to try and shape it a little bit by introducing new things, new form factors, other things". I'll give you just a tiny example of how my personal behavior is shaped. I was checking out at the store and there were a bunch of prompts that I needed to click answers to in the register, and I completely mechanically kept hitting the right button because I wanted it to be a yes and I wanted to get through it and the right button happened to be no.

My behavior is already shaped by somebody coming up with this form factor and saying, "Okay, the continue, the next should always be on the right side". So there's some value in not just asking the question, but also proposing things to do that can shape that behavior. But in terms of how, I would say try many different things and most importantly, listen. Don't just respond, but really, really listen and really try to draw conclusions out of it, play things back, make sure you're well understood and represent back in different ways what was said. I find words to be very valuable, but also very ephemeral. If they're not recorded in some way, if they're not documented in a way that people can gather around and talk about, they become very, very open for interpretation.

Dealing with Ambiguity [07:28]

Michael Stiefel: Well, that's certainly the case. I mean, from the point of view of human interaction, the fact that language is ambiguous is very useful. But from the point of view of a stupid dumb computer, it's not very useful. I mean, to pick a simple example, if I came to you and I said, "This program has to be fast". Well, what does fast mean? And it seems that what you're implying is that there has to be continual conversation where you actually have to model out exactly what people mean when you say, "Fast", when you say, "Organize", when you say, "Availability". These have to be modeled out.

Domain Driven Design [08:15]

Sonya Natanzon: Yes. And there is a concept in Domain-Driven Design called ubiquitous language. I will say I've tried to instill this in many different places. What is the ubiquitous language? How do we talk about this concept or that concept? It's been a very interesting experience because the technology language and business language is almost always different even in the core concepts. And you'd be surprised to find what things shape our language. The platforms we use, I find are exceedingly influential in shaping our language. And coming back to the question, how fast is something? I find people think much better in relative terms, not in absolute terms. So modeling it out in the world that they live in in their functional reality and saying, "We can get it to here, and these are the trade-offs that we're going to have to put in place in order to get it to that level of speed. Does this work for you?"

The Value of Constraints [09:24]

Michael Stiefel: Implicit in what you just said are two interesting things, and they're both, of course, part of Domain-Driven Design is, one, how do you get to this ubiquitous language? Because if you can get the technical people and the business people at least to understand each other, then you've made a major contribution. And the other one that comes out of this conversation is also the constraints. In other words, I personally feel, and you can tell me if you agree or disagree, I think constraints are a great thing because it actually helps you come to a conclusion or to lead the design in a certain direction.

Sonya Natanzon: You and I are in violent agreement. I think a completely open field with no constraints is really difficult to work in. There are too many directions. There's analysis paralysis, and it's just too easy to wander off in a place where you probably don't need to go. Constraints do really shape this, and you and I will call them constraints. Other people will call them requirements. I was just reflecting back on a system that I architected. And one of the constraints was certain algorithms had to be absolutely isolated. They couldn't affect each other. That was a regulatory constraint, but it helped us say, "Okay, there are certain things we already know we can't do, and it shapes the design of that system pretty nicely". So I really do like working with constraints because it just shapes the path much quicker.

Finding a Ubiquitous Language [11:12]

Michael Stiefel: But presumably to get to the constraints, you have to come up with that ubiquitous language so people can express those constraints in understandable ways. In other words, if the technology people don't understand what the business people are talking about, they think they're being arbitrary when they actually are not being arbitrary. So do you have any ideas how you get these business people and technical people together to find these constraints, to get this ubiquitous language? Because if you start out with ubiquitous language, then you're really ahead of the game.

Sonya Natanzon: Yes. Well, I personally love workshops and I like workshops to be fairly large and well-attended, even if some people are bored for some periods of time when everybody's in the room. It's just easier or in a virtual room, it's easier to pull people in to say, "Okay, what about this? What about that?" Get their attention. What I find is, and this is honestly on both sides of the aisle, what folks really need practice with is they don't put together problem statements very well. And I heard this absolutely brilliant definition of a problem statement that I took with me throughout my career. And that is a problem statement can contain one of two things, either good outcomes that are not happening or bad outcomes that are. And I thought, "My God, this is absolutely gold". And the corollary to that was if your problem statement starts with, "We need", it's going to be a solution statement. It's not going to be a problem statement anymore.

Problem Statements, Not Solution Statements [12:57]

And a lot of these things that masquerade as problem statements in reality are solution statements. "We need X. We need Y". Right now, we need AI, AI is in a lot of places. I find that it can be a solution in search of a problem at times, but really crisping up a problem statement and spending actually a lot of time on that helps with those conversations. Once you coalesce around a problem statement, you can start peeling the layers. This is how constraints emerge, this is how requirements elicit themselves, at least on a high to mid-level.

Michael Stiefel: What you seem to be saying is when someone comes to you and says, "We need X", a solution statement, it seems to me you really have to try to peel that back and ask them, why do they need X because you want to convert that into a problem statement because that you can work with.

Sonya Natanzon: I always find that if I need to redirect that, the question that I ask is, "What is the useful outcome that you're trying to accomplish?" And the keyword there is useful and also outcome. And then people start thinking about, "Why am I asking her to do this in microservices or something else that's very much a solution rather than a problem?" So that's been a really helpful tool in my tool belt is asking, "Give me the useful outcome and then let's give us some space to think about this useful outcome to see if there are multiple ways of approaching this". We get so anchored into a solution statement and sometimes it's right. Is this the solution to take to solve that problem? But without the problem statement, we can't really measure whether we achieved an outcome, whatever it is that we're decomposing a monolith into microservices for, did we accomplish it at the end? Maybe we got microservices, but the bigger goal is still not attained. And giving ourselves space to think about alternative solutions, sometimes people come up with better things, better options.

Michael Stiefel: So that raises another thing that I think I've heard you speak about, but certainly is implicit in this statement is when you have a problem statement and that problem statement has a business goal in it, you are dealing with the reality of the current situation. And that very often comes up against what people sometimes call best practices or this is the way you should do it. And maybe you could comment a little bit on that.

Sonya Natanzon: Honestly, I love best practices assuming that they exist. And when I think of best practices, I think of a use case like this, what would be a reference architecture that I can utilize? Has anybody put this together already? Has it worked for them? I don't want to reinvent the wheel if I can help it. Our work is already difficult and there is a lot of it.

Best Practices Must Be Put in the Context of Business Goals [16:05]

That said, you have to keep the context in mind. I spent a lot of years in healthcare and you would think that all the problems that I'm solving are the same problem over and over again, but the context is different enough that you can't necessarily forklift something that you've done before and implement it in a next place. There's always enough differences where your best practice needs to be adjusted, needs to be changed, needs to be shifted, and honestly, sometimes needs to be thrown away because there's, you name it, new technology, new regulation, a new boss who wants to do something exciting and innovative, lots of new things where you just need to go, "Okay, I know I've done it before like this, but let's think about a new way of doing things". That's best practices. I do like them. I will say if you approach them without dogma and contextualize them, they could be very helpful.

Michael Stiefel: Do you find an understanding of this context comes from Domain-Driven Design because there's a certain idea of a bounded context in Domain-Driven Design, or do you see that as something sort of different?

Sonya Natanzon: I think there is a lot of it there. And honestly, I think it's the desire to understand the totality of the business and then be able to draw pieces of it that you're going to address. It's really easy to get overwhelmed as an architect because there's just a lot. Businesses are surprisingly complex. And I've learned over time not to dismiss anything that might look simple on the surface because once you start looking at it closely, there's always nuance, details, things that just put on layers of complexity. So having that capacity is almost similar to the architect elevator to go up to 10,000 feet, 30,000 feet, and then come back down and say, "I am going to just take this piece at 5,000 feet and work through this, bound the context without completely losing the bigger picture around it". Yes, absolutely. It's a skill that comes from Domain-Driven Design.

Introducing Domain-Driven Design Without Methodology Dogma [18:34]

Michael Stiefel: When you work with teams, are they familiar with Domain-Driven Design or is this something they have to be taught or made to appreciate? Because I've always found it to be a very powerful idea.

Sonya Natanzon: In my career, I've only encountered a few people who were truly interested in it. But what I also learned is you don't have to root something in a particular methodology in order for people to utilize it. You could just say, "This is what we're doing and this is how we're going to do this". And by the way, it's a really fun trick. You could be trained in something, not train anybody else and just be that facilitator and see how far you could get. I hosted a workshop that was effectively Event Storming. Nobody knew the words Event Storming or what it's supposed to accomplish other than me. But we started the workshop with, "Here's what we're doing and here's how we're going to do this". And lo and behold, at the end of the day, there were a bunch of people who, without knowing that they participated in Event Storming, participated in Event Storming. So some of this is just training by doing without giving folks really big books. But I have had people who took this further, read Eric Evans' book and really tried to internalize a lot of these concepts.

Michael Stiefel: I can see doing that with Event Storming. But coming up with an ubiquitous language seems to be something you have to do a little more explicitly, or I guess you could do it, I just think out loud, implicitly by getting the business people and the technical people talking with each other and see how the concepts sort of emerge from the conversation.

Sonya Natanzon: Yes. And somebody has to sit there and say, "I am going to write a glossary". I've gotten a lot of mileage of saying glossary rather than ubiquitous language and say, "Here's the word that you use and this is how you define it. Do we all agree on this? Or is there something else that I should write in front of you on the screen that we know now that we're talking about the same thing?"

Michael Stiefel: This is interesting because I've certainly taught Domain-Driven Design and I participated in such efforts, but the idea of doing it without telling people you're doing it is sort of an interesting idea. And perhaps people should think about this because what I hear you saying is that if you present it to someone directly and say, "We're going to do Domain-Driven Design", you get a certain amount of resistance,

Because this is yet another methodology. This is yet another thing that's getting in the way because some managers have this idea of, "Why isn't Johnny coding?" Or, "Why isn't Joanne coding? Why are we doing all this talking? Why don't we get to this?" But if you can do this, I don't want to say surreptitiously, but if you can do it sort of obliquely, you can get both things going. Why aren't they starting to implement it yet? Well, we have to help them understand what they have to implement and in order to do that, we have to make sure that everybody understands this, that, and the other thing.

Sonya Natanzon: No. Why isn't Johnny coding sounds particularly funny now. I feel like we've done, I don't know, 180, 360. I can't tell how many degrees we've gone, but I always thought that engineers should be spending more time thinking and less time typing, meaning really good designs, really good work. It's simple. It's succinct. It's elegant. It shouldn't take miles and miles of code. I feel like we got back to the same place except now the coding is done for us. So there's that space for engineers to think and figure out exactly what they want to accomplish with now bigger, better tools.

Agentic AI and the Future of Architecture [22:40]

Michael Stiefel: Now you raised the almost irresistible question of the world of agentic AI. Let's assume for the moment that obviously there's a trust question about whether you can actually trust what the AI coders produce. I've spoken to quite a few engineers who say you always have to check what they do. You can't trust what they do. But let's assume for the moment we've gotten beyond that and these AI coders are just like any other coder you have to... I mean, when you have humans coding, you don't trust them completely. You have tests, you have things like that. So let's say we treat them the same way, but what does architecture look like? How do you communicate to these agentic AIs or how do you define the agents or where do the agents fit into the architecture?

Sonya Natanzon: I've stopped predicting... A year ago, I feel like we've gone such a long way. I do think that as long as AI coding remains fundamentally for humans, and let me unpack what that means. There's no reason why code needs to be written the way it is right now if it's written entirely for machines and by machines. It could just be machine code. Why do we even have all the in-between stuff of human-readable code that then needs to go through a four-pass compiler and become machine code and get deployed and all of this? It could just run on the machines. I think for as long as the coding happens to be for humans and we want to retain some modicum of control over it, meaning we want to be able to look over it and understand it and change it if need be and correct it or throw it away, the architecture is going to remain kind of the same way.

We will define things conceptually. We will lay out boundaries. We will modularize things in the way that couples things more or less depending on trade-offs. I think all of that will remain the same for the time being. And again, I will caveat this that a year from now, things may be vastly different.

Michael Stiefel: For better or worse.

Sonya Natanzon: Yes.

How to Train Junior Devs If AI Does the Beginner Tasks [25:09]

Michael Stiefel: What always bothers me when I think about this scenario is not at the senior developer or the architect level, but at the junior developer level, how are we going to train junior developers if all these AI tools are doing the coding? I mean, it's one thing for a senior engineer to say, "Oh yes, because I use Claude. I'm 10 times or 5 times more effective because I can get it to do the easy work". But that's the work that the junior developer used to do. So how do people become senior developers if the junior developers are these agents?

Sonya Natanzon: Tooling is an interesting thing, and there's this constant compaction that takes place of bigger and better tools. We, again, don't use punch cards, don't use any of the ancient tooling before because we've gotten better, but we haven't lost our ability to build and design things. I think using the tooling to do more rote work and having the junior developer, somebody who used to write it by hand, write it with the tool is totally fine as long as that junior developer is then able to explain what was done. And I think that that's the key. Reviews are still a thing. It's a big thing. People look at agentic code or agent produced code before it goes to production, assuming of course they're doing anything of material value and there's customers on the other end that might get angry that things went wrong. So being able to explain why things were done the way they were done, what can change and being able to, if change is needed, send off an agent to change it in a way that was requested, I think is going to be the skill that we're going to shift to.

Training Junior Developers with New Tooling [27:10]

Michael Stiefel: First of all, I remember punch cards. I've been doing this for a long time. I remember, for example, working on IBM 1130 where there was no file system and you had to load your program into a particular disk block and then you had to load the linker there and the loader and you had to tell all these things that people today have no idea. They don't realize, as you said, compilers, debuggers, linkers, loaders, operating systems, file systems, these were all invented at some point in time.

Sonya Natanzon: And you had to do those things exactly right. If you don't do it exactly right, like first try, no warmup, that's it.

Michael Stiefel: Yes. For one course I took, I got one run of the punch cards a night, and if I had misspelled something, that ruined the whole thing. But my point in bringing this up is one of the things that I kept as I made this technology transfer is I developed an intuition about how systems work. And the most important thing about this intuition was to understand where the abstractions broke down. I once was programming a personalization system. And normally to scale things in those days, you put them in the database because databases, they know how to scale. Turned out, for various internal reasons which are not important, the database was not scaling and I had to put the scaling in the middle tier, in the object layer. I could only do that because I had an intuition about how the database worked, how the middle tier worked, how things scaled. And what I'm afraid of is that working with these agentic tools, people will lose that intuition to understand where things are not going to work because the abstractions break down.

Sonya Natanzon: Yes. I think it's a totally valid concern. There is some level of deskilling, if you will, that's going to take place. But in my experience, and I think in your experience that you describe, that only happens until things don't work. I'll give you a tiny story in response, and that one is a lot more contemporaneous where my son was working on a project where he had to parse a Google Sheet for his bioinformatics work. And as everybody does these days, went to ChatGPT or whatever help he got, it gave him some code, he ran the code and things were working except he kept getting this error and he was updating cells on this Google Sheet and the API was basically throttling him because he was making too many updates and he was Googling or using AI to get answers to this error message. And the suggestions were, "Well, you can up your subscription and get more API".

Michael Stiefel: More tokens or whatever.

Sonya Natanzon: Yes, exactly. And I looked at it and I said, "Well, you could just load your sheet into memory, do all updates at once and save it rather than doing it cell by cell". So little things like that where at some point they have to find the right answer to this. And there will be other options that they're going to have to explore rather than the first thing that AI gives us. And then they'll have to find the right level of that skill to gain that intuition, come back to best practices or some sort of a known pathway to address a particular problem. I don't think that's ever fully going away.

Michael Stiefel: Well, let's hope so because the interesting thing about software is we're always pushing the edge. In other words, it's possible for somebody who is a mechanical engineer or somebody who builds bridges - You can build the same bridge over and over again if you have to. But usually in software, if we do something, it's because it was doing something new and therefore we're pushing the tools. We have yesterday's tools being pushed for tomorrow's problems. I think if you don't really understand what's going on, you're going to get yourself into trouble.

Sonya Natanzon: I think you're right, but I think we're going to just evolve into more narrow specializations at a certain level. For example, I'm not a hardware specialist and people who do hardware to me do black magic. And I don't see that going away anytime soon, they're continuing to do Black magic. We still need to interface with that. So we have to understand enough to build the tools. So AI is going to be as good as what we trained it on. If we're trying to do something novel, by definition, we're going to have to work through this ourselves before we're able to train the next model on it.

The Architect's Questionnaire [32:41]

Michael Stiefel: Well, let's end on that semi-hopeful note. And I'd like to ask you my architect's questionnaire, which I like to ask all the people who appear on the podcast because I think it gives us a little human element to this practice, which ultimately is practiced by humans, at least for the moment. I don't know if I was interviewing a bot, what kind of answer it would give me, but I'm not worried about that.

Sonya Natanzon: Probably a lot more polished one.

Michael Stiefel: Maybe like some LLM answers, a little too polished with a little too much made up as it goes. Anyway, what is your favorite part of being an architect?

Sonya Natanzon: Seeing something come together. Honestly, this is always my favorite part is seeing a solution emerge through ephemeral things like conversation and people going, "Okay, that's going to work. Let's try this". I love that part of it. It's not the beginning of the road. It's not even necessarily the end of the road is when it goes to production, but when all of the requirements, all of the fuzzy problem statements, all of the technology opinions, all of the egos finally coalesce into something that people agree on and can move forward, that's my favorite part.

Michael Stiefel: What's your least favorite part of being an architect?

Sonya Natanzon: I think trying to convince people to look at things from different lenses. That is such a hard thing to do. It's hard for me at times. I fully recognize that I am a product of my own experiences. I have biases around how things work. But trying to tell folks, "Hey, just look at it from this direction. Just think about this in a different way". I worked with a product manager one time who told me, "If you can think of one solution, you definitely can think of more than one. So go and try". And I apply that to other people in a much more gentle fashion, but I always think it's a good way of... Think about it. It may not be something you end up going with, but it's a good mental exercise to get you out of those biases and try to adopt a different lens.

Michael Stiefel: Is there anything creatively, spiritually, or emotionally about architecture or being an architect?

Sonya Natanzon: I'll say creatively. It is an oddly creative work and odd is an interesting word here. I don't necessarily hands-on do everything soup to nuts. So can I call myself creative? No, but coming up with solutions, really distilling things, to me, it's a creative pursuit that ends up in useful things that I can talk about and practices that I can extrapolate. So it is a creative alley. And just kind of on the broader level, people who think that software engineering is just this boring thing of sitting in front of the computer and clacking away on the keyboard, I think really missed the big point of it's actually really creative. It's work where you get to do some super net new things and architecture is just that at maybe somewhat higher level.

Michael Stiefel: What turns you off about architecture being an architect?

Sonya Natanzon: I think it's a hard one to strike a right balance sometimes of being high level enough and technical enough. You can get into a space where rather than riding the elevator, you're stuck in it and you are neither on the ground floor nor at the C-suite. And the perception is very interesting, I think, and can be challenging for a lot of people. They're kind of in this zone where they can't align themselves with either group. So that can be a little isolating at times.

Michael Stiefel: Do you have any favorite technologies?

Sonya Natanzon: I do, but I think I'm going to hold back because I always get very interesting flame wars when I talk about technology. I'll say this. I think Microsoft has always been really good at keeping developers happy with their tooling. And I've been very partial to Microsoft technologies. Again, things are changing now. Maybe those IDEs will never get open anymore, but I've been partial to a lot of Microsoft tech.

Michael Stiefel: What about architecture do you love?

Sonya Natanzon: I love the community of practice. I really, really do. And this is one of the reasons why I go to a lot of these architecture conferences is because I can encounter people who do the same things that I do, who are solving not the same problems in necessarily the technical sense or even a business sense, but in a global sense. How do you break something down or coalesce something together? How do you keep the big picture in mind while solving for details? How do you have the right teams in place to do the work? And that community, it's one of those rare communities where I see people want to produce these materials for each other and consume them and give each other good information and good feedback to keep moving forward.

Michael Stiefel: What about architecture do you hate?

Sonya Natanzon: That's a strong word. I don't know. Drowning in a lot of technology options. Honestly, if I have to start selecting one, I don't know, database against another one with slight differences in the tech, that gets exhausting. There are a lot of options out there these days.

Michael Stiefel: What profession, other than being an architect, would you like to attempt?

Sonya Natanzon: It's something that I've had a little bit of time to think about these days, and the answer as a profession honestly doesn't come to mind. I think it's more, what can I do outside of this and apply my skills to? I've been practicing my gardening skills and I really enjoy that. I do some work with high school students as they're about to go to college or embark on a career path, and I really enjoy that too. I'll say, kids these days are so smart, I am very, very hopeful, but I don't know what other profession I would attempt, to be honest.

Michael Stiefel: Do you ever see yourself not being an architect anymore?

Sonya Natanzon: I think for as long as I stay in engineering, that particular gene is always going to get expressed in some way, shape, or form. I'm mindful about this, don't get me wrong. When I lead teams, I want to make sure that I don't just steamroll them with my experience and with my knowledge of these practices and let them make their own choices. But I think it's always in there. It's like, "Ooh, let me help you. I know how to do this".

Michael Stiefel: When a project is done, what do you like to hear from the clients or your team?

Sonya Natanzon: Honestly, I think maybe the best thing is nothing. And the nothing here means the technology, the solution is working the way it should, and it's faded into the background. It's letting people accomplish what they came here to accomplish. It's not front and center. It's not annoying. It's not broken. So I think nothing is really a good option there.

Michael Stiefel: Silence is praise.

Sonya Natanzon: Yes.

Michael Stiefel: I think we touched on some very, very important points about how to get people on the same page, how we think about problems. I enjoyed doing this very, very much, and I think our listeners will get a lot out of it.

Sonya Natanzon: Thank you so much for having me. I had a lot of fun.

Michael Stiefel: It was my pleasure.

Mentioned:

• Domain-Driven Design
• "Elevator Architect"
• Event Storming
• IBM 1130