Fireside chat with Udi Dahan

🔗Transcription

00:00:00 Udi Dahan

-ship type of thing and being able to go deeper into those elements. Don't remember, time wise, if that was actually before I created NServiceBus or after. NServiceBus, for those of you who don't know, it was built originally as a messaging library for .NET, originally on top of MSNQ, and then it expanded to include RabbitMQ and other on-prem messaging technologies, as well as now cloud environments like Amazon SQS, and Azure Service Bus, et cetera.

00:00:40 Udi Dahan

I wouldn't say that there's an extremely strong connection between most of what people interpret as domain driven design, and NServiceBus, we're messaging in general. It's only when you get to sort of the later bits of the book where Eric starts talking about bounded contexts and the idea that you're going to want a fairly strong degree of separation, and yet some amount of integration and connection between these bounded contexts. While he doesn't explicitly call it out in the book, messaging patterns are a very good way to deal with those things.

00:01:24 Udi Dahan

The other element where messaging patterns and therefore NServiceBus connect to topics that are nowadays commonly associated with domain driven design, is when people talk about command courier responsibility segregation, [SecureRS 00:01:41].

00:01:41 Udi Dahan

So on the command side, discerning a command from the client and then processing that widely on the server is something that historically people have done over HCTP in various ways, for quite some time. And then they encounter a lot of technical infrastructural issues around those types of things, and that's where messaging can help.

00:02:09 Udi Dahan

And then, again, if you choose to do CPRS in the form where you actually have a different data store for the query side than you do for the command side, then you'll usually have some sort of event mechanisms take data from one side to the other. And again, messaging patterns are a reasonably good way to transfer and reliably process those events on the other side.

00:02:37 Udi Dahan

So that's sort of a brief bit of background for people that are newish to DTC, bounded context, Secure RS messaging to kind of give them a lay of the land, and subsequently connect to all the other things that we'll be talking about today.

00:02:53 Kenny

Yeah. Thanks. And that really connects the messaging you were talking about to the first question that got the most likes on Twitter, right? And it was like, it would be valuable to see real life examples when [SOA 00:03:06] event driven CQRS were a bad fit for a problem and elaborate on why.

00:03:11 Kenny

It seems like most discussions end with, "It was done the wrong way." Yeah, it seems a bit superficial.

00:03:20 Udi Dahan

That was Veronica's question. Good question and a common endpoint for people in these environments. On Twitter, I gave sort of one sneak peek answer, which is, I said, the start of context is usually a place where it is less suitable. I know that that kicked up a little bit of a storm. The primary reason is that most startups, they still haven't validated that the business problem that they're solving is actually viable.

00:03:58 Udi Dahan

What do I mean by viable? That they can actually make enough money or have some kind of business model that results in them eventually making enough money, which is why we often see startups, the term that's used is called 'pivot' which is a fancy way of saying, "Go and solve a very different business problem than the original one that they started with."

00:04:20 Udi Dahan

Now, historically, when I've talked to startups ... early stage startups, I'm talking about, where they haven't validated that hypothesis yet, a lot of times the technical folks on there will be asking questions like how do we find our service boundaries? Or how much data do we put into events? And lots of very technical architectural type questions. My response to them invariably is you're going about this the wrong way. You need to write the minimum amount of software to be able to validate the next business viability hypothesis.

00:05:03 Udi Dahan

The successful outcome is that you actually uncover a business domain that is able to generate enough demand revenue, whatever, that you're previous software solution is barely keeping up, and then you have to throw a bunch of money at it to stand up more servers, or what have you. That the startup success stories that people hear about is, "Well, Twitter had to rewrite their text deck three or four times. Ebay had to do that six or seven times." And the belief is that we can do better than that and get it right the first time.

00:05:43 Udi Dahan

In my experience, it's the other way around; the people that try to get it right the first time end up spending a whole lot of time and money solving the wrong business problem, and then when we find out that it's actually not viable, they don't have any money left to do a meaningful pivot, or a second pivot after that, and essentially the business folds.

00:06:03 Udi Dahan

So the idea of needing to rewrite your software over time is something that, at least in the startup context, needs to be reframed as, "Yes, that's how it's supposed to be," and not to be considered as, "We failed, we didn't predict things in advance, we should've built it more scaled from the beginning," et cetera, et cetera.

00:06:26 Udi Dahan

So I think that a lot of these SOA CQRS Event Sourcing, all of these types of things, they're premature in the early startup contexts. Because, in many ways, it's putting emphasis on the wrong thing.

00:06:41 Christina

That's a good-

00:06:45 Udi Dahan

Christina, you had something you wanted to add?

00:06:46 Christina

People forget that Google [inaudible] the first time.

00:06:51 Udi Dahan

Mm-hmm (affirmative).

00:06:52 Christina

It was a success when, of course, you have to leave work. Jeff Edwards said once about StackOverflow, or maybe it was you, I don't know. You're always up before the next day, and before the next issue, performance issue. It is always the case. The question is when.

00:07:14 Udi Dahan

So that's one category. There's another category that I can talk about, that is less like that. Kenny, do you wanted to ask about that first category?

00:07:24 Kenny

Yeah, because this goes into another question I now see running, and it says, "In which cases should you use, in this case ... what I usually see in businesses where they start to over-engineer it, we need some Kafka already because with event driven architecture and because we need to communicate service to service with events, right?

00:07:48 Kenny

That's actually what you're saying, you ain't going to need it now, so maybe just direct communication is fine at this moment. So if I get you correctly, if you're in the startup position?

00:07:58 Udi Dahan

Correct. So, in the startup mode, it's ... and I see this most commonly when the founders are themselves engineers, especially coming from big software backgrounds, having built big complex systems, it is that there isn't a sufficient either understanding or appreciation for the business side of things and how to incubate something from scratch. And I'd say that a lot more focus needs to be on those sides of things.

00:08:37 Udi Dahan

So remember, one startup brought me and they were asking all of these types of SOA CPRS types of questions. I said, "Well, hold on a second. How much load do you have right now?" And their answer was, "Well, none yet. We haven't launched." I said, "Well, okay. Then we're having the wrong conversation because you don't even know that you're solving the right problem. What you need to do is you need to set up some landing page and see whether you can get any traffic." So find out whether anybody is actually interested in this thing that you're doing.

00:09:09 Udi Dahan

I don't know, we need to be in stealth mode. For whatever reason, stealth mode sounds cool and everybody wants to do it. It's a very dumb idea in, I'd say, a vast majority of the cases. People tend to overestimate the benefit that a big fancy launch will give them, and that's a product of Steve Jobs, who was the absolute king of launches and of preparing things in a really slick ... but Apple's had billions and billions of dollars to perfect that launching type of thing. Startups that don't have that DNA and those muscles yet should not try to emulate those practices.

00:10:01 Udi Dahan

So there's a lot of basics of business and management, and marketing and sales, and all those things to get the basics down first. Launching, that's when you're a lot more mature and you actually have figured enough things out.

00:10:21 Udi Dahan

But this isn't meant to be a how to start up a new startup type of talk. There are lots of talks out there that talk specifically about this. So, for those of you that are interested in those things, there's the Lean Startup Camp, and then there's the Business Model Canvas and lots of stuff out there. Go read that stuff before going to the startup side of things.

00:10:45 Udi Dahan

So, second category, and that was Veronica's question, is very much in that area of the ... in what cases or what example is there where SOA event driven Secure RS are a bad fit for a problem?

00:11:03 Udi Dahan

So one of the examples that I've seen, and there's a number of variations on this theme, but it usually comes from a certain technical assumption of, "Well, we're going to be using a certain technology stack, so we already have this idea of CQRS looks like this. We're going to be using a sequel server on the command side and MongoDB on the query side, or we ... They have this sort of template of how they're going to address this problem in their head.

00:11:40 Udi Dahan

So, one category of that is ... and it's a fairly well known one, which is why we use it. It's the product catalog in a retail type of setting. So many people have either seen a demo product catalog piece of software that says, "Look, you've got a product table, and a product has a bunch of attributes on it. It's got a name and it's got a price, and it's got all of these types of things."

00:12:07 Udi Dahan

And then there are categories, right? You can have a category that's listed in another category. Great, what's the problem, right? Simple, easy, and off you go. Now, what makes this problem domain interesting is that MD in the business world, it's a domain that often has a high degree of requirements, I wouldn't necessarily use the word 'volatility' but evolution. The business often comes to us frequently and says, "We want another attribute on a product."

00:12:43 Udi Dahan

So a product has a shipping weight, and we're like, "Okay, great." Add another column to the product table. And then you get some more information about the category, saying, "I want to be able not only to search based on price and based on category, but certain types of products, for example, once we get into different products it's a ... Well, if we're talking about clothing or apparel, a product can come in different colors. They'll say, "Okay, we want to have a color attribute for products." Developers say, "Great. We're going to add the colors available attribute to the product table."

00:13:27 Udi Dahan

But then you have ... what does that mean for books? Because books don't come in different colors, right? You can't say, "I want the domain driven design blue book, only in red." Well, that's Vaughn's book, but it's a different book at that point, right? So you get this sort of trickle of requirements of the, "Now, I want this. Now, I want that." And we keep kind of adding another attribute to the product table as we go along.

00:13:57 Udi Dahan

Now, when trying to do SOA CQRS, all of those types of things, of insourcing as well, a lot of times, sort of in the early days, what we're doing is, especially on the events between the command side and the query side, we fit every single attribute that is added to the command side is subsequently added to the events, and then is subsequently added to the query side.

00:14:23 Udi Dahan

So essentially, we're having to make the change in more places, but because these changes are happening frequently then, especially for the folks that do the event sourcing with a kind of replay of history behavior in it, then things get more and more complicated over time because essentially, for a giving running system, that's the thing, you tend to get this sort of trickle of new requirements when the system is running. It's not that you get all of these things before you launch the system, and then you launch the system and things are mostly stable.

00:15:05 Udi Dahan

It's this sort of stream of ongoing changes to requirements. Happens all the time. So you're having to make these changes to the running systems to their data models, and then when you're replaying events, you end up having to replay lots of old versions of events. So long as you're only adding columns, that's mostly okay, but at some point in time, your D day is going to tell you, "Hey, guess what! There's a limit in SQL Server on how many columns you can have in a table." And then you're like, "Oh, crap. What do I do about that?"

00:15:41 Udi Dahan

You have that problem both on the command side and on the query side. And then people want to do all sorts of queries in sort of weird ways, but when I'm searching for apparel, then I want to be able to search by color. When I'm searching for things that are not apparel, then I don't want to have the color search to be available.

00:16:04 Udi Dahan

When people start trying to say, "Okay, we're going to put categories and we're going to subdivide, we're going to have them in different tables," it starts to get quite complex fairly quickly. And then the problem is that there's really nothing in, let's call it the CQRS event sourcing, that make any of that any easier. In many ways, it actually ... the technical design choices exacerbate the pain of those types of changes.

00:16:36 Udi Dahan

And also, the underlying data technologies, usually when people choose them, they're saying, "Okay, I need a SQL Server for this and I'm going to use EventStore for that. I'm going to use MongoDB for this other thing. The understanding of the volatility of the data model and how big, how many fields you're going to have to deal with. And the real painful thing, if you're doing CQRS, it's on the query side, but even if you're not, it's still on the same database, is essentially users want to be able to query by every attribute you've got.

00:17:13 Udi Dahan

So I would like to see all shirts that come in blue. I would like to see all books that are on the topic of SOA. I would like to see all watches by this manufacturer. I would like to see all children's toys for children between seven and nine. Almost any attribute in the product table is something that somebody's going to say, "I want a query based on that." Which means, essentially, you need to index every single column that you have there.

00:17:45 Udi Dahan

So I can go on and on about this domain. I've been talking for about five minutes or so to kind of give you the lay of the land, but it's one of those things that when people look at the problem they underestimate its future volatility and complexity, and how their technical choices are going to potentially hinder their ability to continue to evolve the design to handle all of those things.

00:18:19 Udi Dahan

So that problem domain is one of the reasons why, initially, columnar data stores were created. So the better known one out in the wild today is [Cassandra 00:18:35]. But before that, there were a whole bunch of columnar data stores that were created, that were more enterprise targeted at major retailers that were building these types of product catalog. Vertica was one of the better known ones, where essentially the idea being that we don't want to have to use the term 'row.' Not all rows actually require the same columns, right? When you're talking about a book, there are certain attributes that are relevant to books that aren't relevant to shirts, and certain attributes relative to shirts that aren't relevant to books.

00:19:11 Udi Dahan

So the tabular, sort of the relational database model, where all rows have the same number of columns is something that is not a good fit for this domain. So, similarly, when you're choosing your persistence technology, those are things to evaluate. The, "How is this domain going to change?" And one of the common mistakes that software developers and architects make, and the reason it's common is because we're trained for this. We're trained to look for things that are similar, right? It's the behavior of find an abstraction, pull out a base class, basic object orientation, all of those things.

00:19:57 Udi Dahan

So we seek out things that are similar, and we make those things the pillars of our design. We don't nearly enough seek out what is different and how those things may evolve in different trajectories from each other to be able to say, "Actually, those things are not similar enough to be put in the same place, to be modeled using the same domain model, to then be put in the same column. The context, et cetera, et cetera."

00:20:27 Udi Dahan

So I'd say those are the common mistakes. Veronica, it's your question. Hopefully that gives you a real life example where these types of CQRS, SOA event driven type of things, when they are approached from a more technical first approach, which often I see in the DTD community that they are. That's where people get into trouble. And not really starting from the domain side, and spending enough time to understand how this thing can evolve, and the fact that we're not the first people building a product catalog. Instead of spending hours and hours reading up about CQRS and those things, maybe we could spend some time reading up on the product catalog domain and that there are patterns in the business domain side of things that we can learn a lot from and help us in our model.

00:21:28 Udi Dahan

So that comes to about 10 minutes on that topic. Followup questions on that?

00:21:34 Kenny

No, no. There was another question here, and maybe that goes into the heuristic you have here. The other question is why is it a bad idea to duplicate volatile data? And I think you covered it quite well here, right? If something is volatile, be careful with using things like CQRS because you're actually duplicating that volatile data. If the change rate is high, similar to if you extract like the rest level side and the entity framework model side from your domain model, there's translations going on there and it's also essentially a bit of coupling where you need to change places, or change things that has ... Well, a business change leads to multiple changes in your technology.

00:22:20 Udi Dahan

Right. We need to differentiate the duplication versus replication terminology. Because a lot of times we use them interchangeably. Duplication is where essentially we're creating logical structures that are essentially overlapping in logical structures of other places. Now, usually that means that we're also physically replicating the data from one place to another, but the most important thing is to distinguish that logical versus the physical.

00:22:58 Udi Dahan

So if, for example, the most basic one is database level replication that we're all familiar with, right? You've got your primary that you're writing to, and then that gets replicated to the replicas. And that is often done for scaling out the reads. So essentially, it's the same table structure that is in your primary database and in all of the replicas. So there's no logical overlap. Logically, it's the same definition, but you create multiple physical copies of that.

00:23:33 Udi Dahan

So that type of physical replication is often done for technical load reasons. Often done for high availability reasons, right? And we can take a replica offline and we can put another replica in its place. For geographic redundancy, so if we're building a worldwide available type of solution, then we don't want everything having to traverse the entire imminence to get to a specific server in one specific location, so we replicate the data multiple places, but essentially it's the same code base, it's the same logical structures. That's replication.

00:24:13 Udi Dahan

Duplication is when we start saying, "No, it's not the same logical structure." These are different bounded context business domains, where essentially the same fields are put in either place. That's where things start to become tricky because, first of all, and this is the other part about volatility, when people talk about volatility, volatility there is the rate it which the data itself changes at a physical level. So the customer record, the product record, how quickly is the data itself changing.

00:24:52 Udi Dahan

So you have that data level volatility. And then we have the above logical level of volatility that I was talking about before, the definitional. So how we define a product now has another attribute, right? So that is definitional volatility versus the data volatility. Logical versus physical.

00:25:14 Kenny

I know Paul Reiner calls that one the connaissance of names.

00:25:16 Kenny

So the naming there, the attribute has a name, which has a meaning in your domain, so there's a connaissance if I want to change one, I need to change the others as well.

00:25:32 Udi Dahan

Right. So the other part that's related to that is that once you've created a logical duplication, the first question is, is it really meant to be the same? Or is it meant to be different? So once you've created the separate definition, that creates the opportunity for forgetting, if you will, that one team changed one bit of code and they forgot, or it was the responsibility of another team to change another bit of code, in definition.

00:26:04 Udi Dahan

So it often opens up the opportunity for a divergence of definitions, and then that creates subsequent problems down the road. So if things are supposed to be the same, duplicating the definition makes it harder to maintain that logical sameness over time.

00:26:22 Udi Dahan

Now, if they're different then, at that point, it's not really duplication anymore. You're defining a new different term, and there might be some relationship between then. But I think the most important thing when people get into these questions, or into these situations, is to be specific, what exactly are we talking about? When we say 'volatility' are we talking about data volatility or logical, definitional volatility? The example that I gave if a product catalog illustrated a bunch of logical volatility. Additional changes to the definition of what products needs, right?

00:27:00 Udi Dahan

Versus the, "Oh, I want to keep the data that is shown to people in search results fresh, whether that's based on prices or anything else, so that when they click through from the search results to the actual product page, they don't see two different things," right? So that is a case where having a copy of the data for search, which is optimized for search purposes, is a physical form of duplication and reorganization for technical reasons.

00:27:37 Udi Dahan

But logically, the terms are meant to mean the same things. So in all of those areas, it's back to the question of why should we be careful with volatility and duplication? It's the point A that I mentioned before, the if you're duplicating the definitions, they can divert when they shouldn't, right?

00:28:06 Udi Dahan

The flip side being, if it's the same thing you're doing, replication, there is no problem with it. Just be aware that you're doing it for technical reasons and that those technical reasons are justified. So if you think you're doing physical replication, but you have two different teams that construct changing the definitions of those structures, then the thing that was meant to be logically the same might end up diverging as well and turning into that sort of definitional duplication without any real clear ownership around it.

00:28:42 Udi Dahan

And then the other case is when it's actually supposed to be different but it looks the same. So, I don't know, we use the term 'customer.' Say, "Oh, we've got a customer here and we've got a customer there, and we've got a customer there." But in different environments, it's the support people, when they're talking about customer, what they actually mean is user. They're talking to a user.

00:29:08 Udi Dahan

So in a given customer account, there may be a large number of users, each of them having different questions that need to be tracked and different ... make sure that the response times are being met. So if we use the term 'customer' in the support context, it's actually ... it muddies the waters.

00:29:27 Udi Dahan

And if we talk in the accounting context then, again, it's a question of does one customer in the sales context mean the same thing as one customer in the accounting context?

00:29:40 Udi Dahan

So even there, it's just terminology. Make sure that we're talking about things correctly. And that's where techniques like SOA and starting to partition things and be more specific about things can help. But that requires me to spend a lot more about SOA and I want to be cognizant of all the other questions we need to get to.

00:30:03 Kenny

Yeah. Yeah, thanks. And to go on, on that, because we were talking a bit about coupling, right? One question that was there, if we do use a communication by integration and doing events between the balanced contexts, what would be some pointers or some heuristics you have to avoid coupling between these contexts, right? Because that's what we eventually try to do with a valid context, is try to let the system be more tolerant. Be more decoupled, which you can't, but as no one says possible.

00:30:38 Udi Dahan

Right. So, first of all, we need to have certain assumptions that both the software, the business, the organization, is actually mature enough in order to be able to find good boundaries and then maintain and execute on them long term, because a lot of times those pre-conditions don't exist, like I mentioned in the startup context. So we need to make sure that the overall context that we're in is such that supports those things.

00:31:12 Udi Dahan

Now, assuming that those contexts are there, then there's a number of supporting patterns that need to be in place and, let's call them metaphors. The first one being that a lot of tines when people talk about bounded context, which is a logical term, they connect that to a physical or, let's say, to a code base, first of all, so you have ... Maybe I'll start at the beginning.

00:31:46 Udi Dahan

You've got sub-domain in DTD terminology, which is, let's call it, more on the business domain side of things. Then, in Eric Evans terminology, bounded context can mean a number of things, and I don't want to get too much into that, but I'd say the guideline that I recommend, and that has a fair bit of history in the software architectural world is that you want to try to have a good mapping between your solution domain to the problem domain side of things. Okay?

00:32:32 Udi Dahan

So that means your code base to the sub-domain, all right? Now, so I'm skipping over the DTD bounded context term to use the more clear code base statement as the first part of the solution context. Now, the other part is to say, "Well, the sub-domain, how broad do I take it? Again, one of the common mistakes that occurs is a management one where things are coupled too broadly. So the project management part of the business world says, "I have a problem to solve," so that's business domain type of thing. I'm going to, in my head, not even realizing I'm essentially doing design, I'm going to choose which team is going to do that. And by proxy, which system that's going to be implemented in.

00:33:40 Udi Dahan

Now, system is a unit of deployment. Team is a unit of personnel organization. And then you've got the code base itself, and then you've got the data underneath it. So there's a whole bunch of things here that are decisions unto themselves. It usually, even before any work is started, all of those decisions are established and essentially coupled to each other. Where this business problem is mapped to the team, which is mapped to a system, which is unit of deployment, which is mapped to a code base, which is mapped to a database, and whatever level of overlap there is between other teams, other code bases, other databases, et cetera, is just sort of very briefly glossed over.

00:34:29 Udi Dahan

And, team, this is your job, and then it's a, "Should that really be our job? Should we really own all parts of it? Maybe we should own this part and that other team in that other code base and in that other database should own this other part, and essentially, we should be collaborating with each other in solving this bigger problem."

00:34:51 Udi Dahan

So a lot of the mistakes of the situation that you're describing are mistakes that happen even before the team is sort of made aware that there is work to do. And then when they're given the work to do, then you end up finding out, later on, things that we did overlap with things that other teams have done in the past or are doing now. And part of the reason why those things occur is politics and business managers, folks are fighting over responsibility between each other and going behind each other's backs. It's a whole mess.

00:35:29 Udi Dahan

So when we say, "Oh, we've got a mess in software. What should we do to fix it?" A lot of times, the mess that we have in software is essentially a reflection of the mess that occurs in the business and the management side of things. So a lot of times people say, "Our problem in software is we're not well enough aligned with the business." I'd say that, in many cases, the problem is that the business world is too chaotic and not really well organized. We could be perfectly aligned with the business and we'd still have all of these problems.

00:35:58 Udi Dahan

So a lot of times the solution is for us to try to compensate for the lack of good boundaries in the business and in the management, and the project management sides of things, which is really difficult for technical people to do because now we're not only doing our job, we're doing a whole bunch of other people's jobs along the way.

00:36:18 Udi Dahan

Now, given all of that, getting to the point of saying ... that's why I said organizational context needs to be mature enough when going to engage in these types of practices. When all of those pieces are in place, then you can say, "All right, the sub-domain is best divided up into these chunks where the only bits that need to connect them are an identifier here and an identifier there." And then this code base and the database underneath it deals with this ID and those five attributes. That code base over there deals with same ID but four other attributes, and has its database and my database, and then we have some sort of composite UI that stitches those things together so that the end user sees just one thing when they're looking at a customer account, an employee record, a product details page, what have you.

00:37:18 Udi Dahan

But to your question, which you started from, it's the events that connect between these two things. When you do that exercise well, of all of those up strength things that I said, what you'll find is that the events that occur usually don't contain a whole lot of data in them because, essentially, we've teased apart all of the sub-domain level things to say, "Well, I don't need those attributes on my side," so when you make a change over there, you don't need to issue a domain event or an integration event saying, "I changed XYZ," but the idea is still the same, right? It's like, "Well, yes." You're like, "Well, I don't care because I don't store those fields on my side of things."

00:38:09 Udi Dahan

And that's that whole duplication story of saying, "If we don't duplicate, if I don't have the same definitions on my side that you have on your side, then we don't need to include those fields and the events, and in some cases, we don't need to events at all to propagate changes from one place to another."

00:38:32 Udi Dahan

So the nature of the events starts to change and become more reflective of the business. So instead of something like product name changed or product price changed, or all sorts of varied data oriented events, you often end up with things that are higher level things. The product is no longer for sale. So all that event needs to include is the product identifier, but then you have different business capabilities and/or code base that say, "Oh, product's not for sale anymore. Okay."

00:39:12 Udi Dahan

In the search context, that means we need to stop including it in the search results. So that behavior is demoed through there. In the shopping cart context, say, well, people that already have this item in their shopping cart, well, they can finish their checkout if they're online right now, but if they don't and if their shopping cart goes to sleep then when they come back we will have removed that item from the dormant shopping cart. So that's a behavior in the shopping domain when a product is no longer available for sale. So you might have a manufacturing recall or something. It's not safe to sell that product anymore.

00:39:51 Udi Dahan

Then you have, in the inventory side of things, which is, well, we stopped the automatic inventory replenishment for products that are not for sale anymore. So here are examples of different domains, likely holding different information, different fields about products, where each of them is behaving differently off of the back of an event; product no longer for sale, that all it contains is the ID.

00:40:21 Udi Dahan

So those are the types of things that you'll see as more common archetypes of both events and the behavior of processing the events. So a lot slimmer events and the kind of thing you'd say, "Well, you know, it isn't clear why exactly the shopping cart world would need to overlap very much with the inventory replenishment world."

00:40:50 Kenny

So would that be a risk you're using if there's too many fat events, maybe my boundaries are incorrect during communication. Maybe there's something wrong of the way that maybe this is communicating to a project. At least there's a smell here.

00:41:06 Udi Dahan

Yes. Indeed. So, fat events are either an indication that what you're doing is essentially a form of data replication, but then essentially you're saying it's not integration events at that time, they're replication events. It's a mechanism that I'm doing to keep in sync multiple copies of the same logical thing.

00:41:34 Udi Dahan

So, so long as you say, "All right, these are not distinct separate logical things, they are physical replicas of the same logical thing that are within the same logical boundary, then fact events are how you do data synchronization replication."That's fine.

00:41:55 Udi Dahan

It's when you intend to be in the logical world, and having different things at a business level, then there I'd say, yes, fat events are a smell that the boundaries there aren't good.

00:42:14 Kenny

Yeah. Interesting. And what interested me, as you started about not naming out of context but naming these sub-domains, right? The problem space, solution space. And there's been a lot of debate and questions as well, is this useful, especially ... Well, I know Trent was asking this question of you on the current discussion regarding solution and problem space, as well the need to define some more concrete building blocks in DTD and like on that side, like sub-domain, core domain, and for people, it's too ambiguous, what do we mean with a sub-domain? What are these building blocks?

00:42:54 Kenny

What are your perspectives on that? And what's your perspective on these building blocks on the problem space side, perhaps

00:43:03 Udi Dahan

Right. Well, I'd say that the field of software design and architecture, with the introduction of patterns, I don't know, 30 years ago ... ish. 25 years ago, I think, was it The Gang of Four that came out, the first time saying, "There are these things that are patterns, that are replicable types of things." And then the pattern community around that essentially created certain templates for how we define patterns. And one of the main criteria that was set in the pattern community, in those early days, was a crisp, clear, unambiguous definitions. We should try to minimize the overlap between things.

00:43:54 Udi Dahan

So if we use a certain term, we should use that term consistently and have its meaning be clear and unambiguously different from a different term. And seek to do that across essentially a number of dimensions.

00:44:12 Udi Dahan

So, for example, that element of saying, "There is a problem domain and a solution domain, a certain discrimination of dimensions. So that we don't use the same terms across these different spaces, we're actually going to name those spaces and say there are ... Martin Fowler wrote a book a while ago of analysis patterns, and say the terms that are used there are sought to be distinct from patterns that are subsequently called a design patterns side of things.

00:44:52 Udi Dahan

So I'd say that seeking out clear unambiguous terms where we can also relate patterns to each other and say, "There is this pattern and there is that pattern, and each of them solves a distinct problem," is helpful.

00:45:08 Udi Dahan

So one of the things that I think, in The Domain Driven Design, in the original book, the in the beginning of the book was quite pattern oriented in terms of entities, value objects, repositories, et cetera. So it's kind of connected back to that pattern of community where clear, crisp definitions, they're very distinct from each other, you know you use this for this, use that for that, and there's a very low probability that somebody's going to mistake a value object for a repository or a repository for an entity, or an entity for a value object.

00:45:48 Udi Dahan

So those bits were quite good. It's when we got towards the latter areas and the sort of strategic design where I found that things were not nearly as crisply defined. There was a lot more ambiguity and overlapping. Say, bounded context, what does that mean? Is it purely linguistic? Does that include code bases? Does that include deployment environments? And the answer that I got from Eric when I asked him that was, "Yes, it can include each and all of those things."

00:46:26 Udi Dahan

And I think that that overlap actually creates ambiguity because when I say the term bounded context, you would need to subsequently ask me, "Wait a minute. Are we talking code bases? Are we talking linguistically? Are we talking ... What do you mean when you say X?" The whole point of having a pattern language is so that I don't have to say five sentences when I can say two words. Right?

00:46:57 Udi Dahan

And I think that bit was missed in some parts of DTD. And in order for us, as a community, to resolve those issues, we essentially need to stop using those terms and use terms that already exist in the pattern literature, and/or come up with new terms so that when we talk about a certain code base, and people ask me this a lot, and I said, "Okay, so when you say SOA service, what does that look like in code?" I said, "That's a source control repository." When I say the term 'source control repository,' that is an unambiguous thing. You know exactly what I mean.

00:47:47 Udi Dahan

This field of source control is well defined, and the thing that is in there is source code, right? It's not executable unto itself. When I tell you source control repository, there's no way you can mistake that with a running system. Right?

00:48:04 Udi Dahan

So I think that we, as a community, in terms of moving ourselves forward, we need to find and make more use of existing terminology, source control repository. Packages, for example, it's when you compile and package code in a source control repository, what comes out of that is not a running system, you get a bunch of packages, right? MPM packages, jars, wires, .NET assemblies, et cetera, et cetera.

00:48:35 Udi Dahan

Then those assemblies, those packages, get pulled through various types of mechanisms and put together into executable environments, right? But there is a set of transformations that occur on one or more source control repositories that ultimately results in an executable process. Right? And again, we want to distinguish the executable process, meaning all of the packages are there, all of the configuration is there. This thing now can run. Versus an actual running instance of that thing on one or more servers.

00:49:19 Udi Dahan

So all of these things, they have names in the software world. We don't use that nearly enough. And then that creates ... Or essentially we lose degrees of freedom in our solution space because essentially we interpret the running system with the code, essentially ignoring the fact that there is a whole field of transformation that can be done, and a certain number of degrees of freedom to say, "Actually, there's nothing preventing a running system, an executable process from having code that's coming from multiple source control repositories." Right?

00:50:06 Udi Dahan

But naturally, we ... I don't want to say naturally. It's quite common that the assumption that an executable process equals one source control repository. That's often how teams go about designing software. Because multiple source control repositories, that's too heavy, weight, whatever, that's too hard.

00:50:28 Udi Dahan

The other thing that we presume is source control repository equals team. And again, that question or that decision is something that needs to be validated. So there's a whole bunch of things that happen in our world of software development, maintenance, operations, deployments, all of those things that unfortunately we've been ignoring and throwing out degrees of freedom, which then essentially, challenges that we end up dealing with, we have fewer tools at our disposal.

00:51:08 Udi Dahan

So, if all you have is a hammer then you end up not being able to build very elegant furniture, right?

00:51:17 Kenny

Yeah. So what's-

00:51:19 Udi Dahan

I'm talking about degrees of freedom, essentially it's tools that are at our disposal.

00:51:23 Kenny

Yeah. So what you're saying, and I know the community's doing so is trying to ... well, and Rebecca constantly says as patterns evolving, make sure to like new ones, they might evolve, rename them, rethink about them. That's something that you're going into as well. And I know some members of the committee is already doing that, right?

00:51:47 Udi Dahan

Being more precise.

00:51:50 Kenny

Yeah, more precise.

00:51:51 Udi Dahan

And being able to say that is a deployment concern, which is distinct. There can be deployment patterns, those are distinct from the source control patterns. A lot of times, when we talk about ... I'm going to use the term 'coupling' or decoupling. It's how do we couple or how do we design things? First question is, in which domain are we talking about? Is this a code in the same source control repository? Or in different source control repositories? We often don't even start with asking those questions, we presume a whole bunch of things, and then it's a, "How do we couple or how do we share, or how do we ...

00:52:35 Udi Dahan

So it's a realize that there are those things and have rigorous definitions, and be aware of those tools. And yes, it would be good for there to be more rigorous definitions, more precise definitions, broader sharing of those definitions, and use of them, whether it's in conference talks or in broad posts or papers that are online, Twitter, just sort of the general conversation that we make our language more precise because that will allow us, as a whole, sort of lift the quality of the discourse.

00:53:14 Christina

We have a question here from John. Do you think that this ambiguity was intentional?

00:53:22 Udi Dahan

Do I think that the ambiguity was intentional? I don't think so, in the sense that after spending many hours and many days with various members of the community, as well as with Eric Evans, specifically, people just have different natures, a different sort of inclination for specificity or generality, and certain ways of thinking. I'm sort of more of a ... I like things that fit into neat boxes and I like to find relationships between things because that's what natural to my brain.

00:54:10 Udi Dahan

Somebody else, whose brain does not naturally think that way, to them, what is right and good, and should be emulated, is things that are more free flowing, and not nearly as rigid. So they might look at the thing and say, "The domain of software is constantly evolving, requirements are changing, teams are relearning all the time." The fluidity of that environment should be represented in a more fluid and less rigid form of talking about things. And that is an absolutely valid interpretation and recommendation from someone who thinks in those terms.

00:54:51 Udi Dahan

I don't think there was any intention to obscure or to take things that could have been, that were viewed as clear by a certain person, and then to make those things intentionally ambiguous for others. That's not my interpretation of what happened.

00:55:12 Christina

I didn't talk with Eric about this, but I can imagine that 15 years ago it just wasn't the time yet. The time didn't came, how did we work at that time? We didn't have the question about teams, or organization, or autonomy. All these things appeared later. That, yes, one repository needs one team maybe. This bounding organization, it wasn't the time. Or maybe he just-

00:55:45 Udi Dahan

So-

00:55:47 Christina

Specialized everything that he was sure, and freedom in innovation for the rest.

00:55:57 Udi Dahan

My interpretation of it is that it's largely rooted in the fact that this field has just been growing so incredibly rapidly for so long, saying you got double the number of programmers in the industry every five years. Meaning that it's almost impossible to be aware of prior art because new art comes out at ever expanding phases.

00:56:24 Udi Dahan

So the idea of different team structures and matrixed organizations, and source control systems, people are using the tool set from rational ... the rational unified process and rational rows for modeling things. I worked on a number of projects that had multiple teams, and have had gone through a lot of these same sorts of questions. The term 'domain driven' did not occur at the time because it was not actually in the literature. It was pre Evans' book. But to say ... I'm not sure I'd say that it wasn't the time because a lot of these things were questions that were discussed in various places.

00:57:11 Udi Dahan

However, again, just the field grows so rapidly that people sort of grow in an area that is far enough away from all of those other things, and it's impossible to find out everything that exists. You'd never get any work done. That doesn't mean that you shouldn't share your insights and that other people who find those insights valuable shouldn't make use of those things.

00:57:36 Udi Dahan

But that's part of why it's helpful to have a more diverse and inclusive community, and people coming from different backgrounds and saying, "Well, actually, we've dealt with those things over there for 20-30 years, and this is what we've been doing. This is how we've been solving it and, I don't know, it seemed to work fine over there. Maybe we bring that over here."

00:57:56 Udi Dahan

But for that, you want more of that cross pollination and, let's call it, less of sort of internal focus of what did Eric mean, what's the one true scripture that we should all follow as it was handed down from the elders of DTD. There's always prior art. There's always different understandings in different places. And I think that the solution is rooted in sort of going broader and including more and learning from more sources. Incorporating, linking, and then also sharing our insights back to those environments.

00:58:38 Udi Dahan

So I think that's one of the things I find a little bit worrisome, is that we continue to put an emphasis on identity around the DTD elements of it, which may promote a more internal looking focus, and not enough of a, "Let's look outwards at other fields that don't call themselves domain driven and don't use that type of terminology, but still may have a lot of good stuff for us to learn from."

00:59:11 Christina

Sure. And this is changing, we had this discussion last year. We finished the year with a huge discussion about what DTD means, and I think not many people said the book. Most of us, me, for example, for me, it's the book, is only implementation detail, all the stuff, all around, it's so much bigger and it begins before and not by the book.

00:59:38 Christina

The book, if I am at a place to think about software, I've solved a lot of problems already. So don't take time.

00:59:48 Kenny

Let's go, because we were talking about the ambiguity and being precise, and that's the next question from the Q&A novel, right?

00:59:56 Christina

Yeah.

00:59:57 Kenny

So you have a great definition for the term service. It's a technical alternative for specific discs capability. Do you also have that short definition for Saga and aggregates? In my naïve understanding now, sagas are aggregates consuming and producing events. That's the question.

01:00:18 Udi Dahan

So there is the term saga, in the context of software, was originally coined in a 1987 paper, that was rooted in the database community, that talked about a solution approach for long lived transactions. So, that is the historical context of when that original term was used.

01:00:49 Udi Dahan

The idea of long lived transactions, as it was represented over there, was a product of the times. Now, what do I mean by that? In those times, what you had was largely single user applications that were getting more and more widely spread across organizations, and organizations realizing that sharing data between users is important and helpful so that you actually have coordination and people are not doing different things. You want to have the left hand knowing what the right hand is doing.

01:01:31 Udi Dahan

There were two competing architectural schools of thought as to how that should be handled. So you had the messaging folks. The, what was known as, enterprise application integration, EAI, which essentially said, "We're going to pass messages. We're going to, essentially, the applications, the idea is we don't want to or we can't change them much or at all. So essentially, we're going to have this thing in the middle, the EAI broker, that is going to pass along things between all of these apps. That was essentially school of thought number one.

01:02:09 Udi Dahan

Now, school of thought number two, which was the relational database community, that said the solution is, essentially, put all of those applications on top of one big database. Because once all of the data is in one place, then you've solved the problem, right? You don't have the problem of enterprise application integration anymore because essentially you have one view of customer, one view of product, one view of everything.

01:02:34 Udi Dahan

Now, defying the ointment of the central database that all of the applications are sitting on top of is that the programmers that were building these single user applications, even if you were using a database driver that could then point to a central database, was that you could be lazy, right? So when the user clicked Edit to go in to edit a field or a record, programmers at the time issued a Begin Transaction statement. And then as the user modified things, they issued update commands and whatever, and when the user clicked Save then they would commit the transaction.

01:03:16 Udi Dahan

And if you're building a single user application, that is a perfectly valid way of managing data. However, when you are now having hundreds of applications all doing that on top of a big central database. Now, what you have is this problem called long lived transactions, which we know nowadays leaving transactions open for long periods of time creates problems. It doesn't scale, right? You lock out other users.

01:03:45 Udi Dahan

So that was the problem context of why long lived transactions were an issue and why a pattern was even sought to be created to solve that problem. All right? That's the historical context of the original and production of the term sagas into the software world.

01:04:07 Udi Dahan

Now, the thing that is not discussed nearly enough is that even though we're now in a different context, realistically, you don't hardly ever see anybody doing those same categories of long lived transactions, right? People don't leave transactions open for long periods of time, they know not to do that, right? It doesn't scale.

01:04:34 Udi Dahan

But the issue is the business side of things that the examples that are given for sagas are, in many cases, the same examples that were given, whatever it is, 25-30 years ago, when the paper was written. And still taught in universities, which is terrible.

01:04:58 Udi Dahan

So, for example, the transfer in money between different bank accounts is described as a kind of transaction, so when you decrement the balance of one, you increment the balance of the other, but that requires you essentially to walk both of the account balances while you're doing that.

01:05:19 Udi Dahan

Luckily, the financial system doesn't work that way because otherwise it would run into a halt because everybody's locking everybody else's databases and just nothing will happen.

01:05:29 Udi Dahan

So essentially the thing that is described as a long lived transaction is broken up into a series of smaller transactions, and that's essentially the saga pattern. Now, the thing about the saga pattern, again, as it was originally written, is that it talks about compensating actions that essentially bring you back to the original state. Why? Because there's the assumption or the definition of transaction is that they're ACID, right? Atomic, consistent, isolated, and durable.

01:06:03 Udi Dahan

Now, once you split the transaction into multiple different technical transactions, first of all, it's not really atomic anymore, right? It's not either all done or not done, you're actually exposing the interim state. As a result of that, you're not I either. You're not isolated, right? So when you transfer money from Account A to Account B, there will be a period of time where the money is neither in Account A nor in Account B.

01:06:30 Udi Dahan

So those elements of saying, "We're going to take a business activity," I'm going to use the more general term of the thing that we're trying to do, and modeling that as series of steps, that business analysis is something that needs to be analyzed, first and foremost, at the business level before we run ahead and start saying, "How are we going to knock that to technical levels?"

01:06:56 Udi Dahan

The reason for that is that a lot of times the business folks are not really good at thinking about failure situations, they just sort of give us, "Build this functionality, implement this business activity," what have you. The area where this becomes complicated is, again, because you have multiple users that are all working at the same time, doing different business activities, but on sort of a larger shared set of data that the collaboration between them is usually not something that is deeply enough analyzed.

01:07:34 Udi Dahan

So this comes back to some of my comments around commands in the context of CQRS saying risk conditions don't exist. So the problem is that when people approach these types of things and analyze business work flows or business activities, they almost always analyze them in a single user context. Which is essentially the way that people thought about sagas 25-30 years ago. But the world is very different and they required different business analysis techniques.

01:08:05 Udi Dahan

So, in order to have things work at a collaborative level, you often need to fundamentally change the business problem. So one example that I give in my course is, for example, reservation systems. They say, "Well, reservation systems, Ticketmaster or whatever, people go in online and they start reserving these seats or those seats, or whatever, and if those seats are taken by somebody else then the command fails. Ergo, there was a race condition, right? Two people selected the same seat, you can't have both of them succeed.

01:08:36 Udi Dahan

So it's not even a question of saga, not saga, it's just sort of the business activity itself. If the command is likely to fail, the transaction is likely going to need to either technically roll back or you're going to have to perform a compensating action in order to get you back to the original state.

01:08:56 Udi Dahan

Now, a lot of the problems people are talking about the technical implementations way too soon, before really solving understanding the business problem and solving the business problem.

01:09:10 Udi Dahan

So in the interest of time, make a long story short, the problem of reservation systems at scale is that essentially they're set up to be competitive, not collaborative. So everybody wants the best seats. And then essentially, by exposing the raw data model, these are all of the seats, are they taken or not taken, creates a lot of technical challenges.

01:09:40 Udi Dahan

The better model, and what was ultimately implemented in the London Olympics, which I was thrilled to see that they did because it was a thing that I was talking about for years, in my course, before that so I can say, "Hey, there's at least a good chance that somebody somewhere over there actually listened and did this thing that I mentioned," is that instead of having people select their seats, people essentially say, "I want a certain set of seats, but in an area," there's a block here of 100 by 100 seats and that's what's available, you can say, "I want five," but you don't get to say which five.

01:10:20 Udi Dahan

And so, the system gets commands that are coming in, someone says, "I want five seats, I want four seats, I want three seats, I want 10 seats, I want this." And essentially, it's able to take all of these requests, it changed the user interaction model. It changed what's even the command means from, "I want those seats," to, "I want any five seats." By changing and shifting the business problem, then the software that does the processing can say, "Well, I'll rearrange all of these reservation requests to fit into the optimal space," and they're not able to make the maximum proportion of those requests succeed.

01:11:04 Udi Dahan

But essentially, by doing that, I've changed what I even think about as, first of all, what's showing to the UI, what's the command, what's the domain level that is processing those requests? So a lot of those things start to change, but it comes from a seeking to model the collaboration, the behavior of multiple users with regards to the system and optimizing for the whole. And then subsequently saying, "All right, let's craft a domain model that looks at finding an optimum," and that's where, when I use the term 'saga', slash a long running process, it's more in that category where the term that ... to use, not an insert a specific term saga, but a more general term. Say what you want there is a policy object.

01:12:08 Udi Dahan

And that policy object essentially takes in a number of messages, they may be commands, they may be events, and over some, usually there's a time horizon for that thing, runs a bunch of logic and says, "Okay, the best way to seat all of these reservation requests that I received within the last 10 seconds, five minutes, whatever, is this way.

01:12:36 Udi Dahan

So, when you do that, essentially the aggregate becomes that policy object that is receiving and managing all of those messages, and usually time as well. So in service, the sagas, in so much as they are designed for handling multiple messages, providing state management, and managing the passage of time, are a good implementation technique for implementing those types of policy objects.

01:13:13 Udi Dahan

So there's that category, but you only find those types of software design patterns after you've done the business analysis from a collaboration focused perspective. And often, that ends up resulting in much better solutions, users are much happier, they don't end up having to refresh their screen all the time, having problems getting into the system, et cetera. More of the commands succeeding in the system, many things go better when you're solving the right business problem the right way.

01:13:46 Udi Dahan

So that's Category A. Category B is when you're doing integration with, I'll call them third parties. So one of the examples that we've got some documentation for is, let's say, shipping. So you get orders that are coming in and you need to ship them. Now, you have a preferred shipping provider that gives you the best rates. So you want to ship with that preferred shipping provider most of the time. The problem is sometimes they're down.

01:14:16 Udi Dahan

So under the cases where your preferred shipping provider is down, then you fall back to talking to another shipping provider, which is slightly more expensive but you have better guarantees that things go out the door.

01:14:31 Udi Dahan

So that's a case where often times you'll have this sort of long running process where it's more process [managery 01:14:41] in nature, that you have sort of a single defined message that kicks it off. Then it says, "Send a message over here. If I don't get a response with a certain period of time, then I perform this other action, and then hopefully that is successful. If that doesn't succeed then I perform this."

01:15:01 Udi Dahan

So have a certain kind of well defined set of steps where it's process management territory, and that is often distinct from the policy situation that I described before. Now, the fact that NServiceBus sagas, as a technology, can be used for both of those things, they're not the same pattern. And I'd say that latter case, the process manager, usually the state is not of a great deal of interest after the process has completed.

01:15:33 Udi Dahan

So it's just a, "Well, which shipping provider did I use," and kind of recording that, and then all of the interim state gets thrown out.

01:15:42 Udi Dahan

So in those cases, most of the time people wouldn't look at that thing and think of it as an aggregate in DTD terms, and say, "That's a process management." So when integrating with third parties, you'll often do a process manager style, which is get a thing that comes in, which triggers the process, talk to A, talk to B, talk to C, manage time, whatever, and you're done.

01:16:10 Udi Dahan

The mistake that I see that happens is people use the process manager style for collaborative domains. And the reason that they do that is because they don't spend the time to think of them and to analyze them as collaborative domains. They say, "The user did this. I prefer steps one, two, three, four," same kind of process, long lived transactions as the original, 25 years ago, leaving a transaction open for a long time. That's the mistake.

01:16:43 Udi Dahan

So you don't want to be using the process manager pattern in collaborative domains because usually that's an indication that you're thinking of them as single user in the first place. So you want to take several steps back and when you do that you'll find this more policy object pattern, which often takes in multiple messages, it's not nearly as sequential in nature, usually there's a time component in it because it's a, "I'm not just going to let the collaboration happen over days and weeks, and whatever, without doing anything." And those are parts of the mechanisms of being able to manage good collaboration.

01:17:23 Udi Dahan

So when talking about sagas, I'd say that it's the ... the first step is that, in terms of clarity, it's a, "Are you in the collaborative domain," spend the time analyzing that properly. You'll find a more policy object pattern, where it is handling multiple messages and time and needs to manage state. Or are you more in integration scenario, where it's much more process manager pattern style?

01:17:53 Udi Dahan

And then once you recognize which area am I in, which pattern am I doing, then you can start using appropriate technology for that.

01:18:05 Christina

This is what's meant with coupling of events.

01:18:07 Udi Dahan

Yeah.

01:18:07 Christina

Because if you're using process manager for collaboration, then you are a couple over the boundaries.

01:18:17 Udi Dahan

Right. Essentially, the higher level of architectural style of the process manager pattern is the enterprise application integration. So often, that is where you have business process orchestration. In the Microsoft world, that would've been BizTalk, in the Open Source world, you have WSO2, and all of those other types of ESB technologies. You may sort of drag and drop and sort of draw out various work flows.

01:18:56 Udi Dahan

There's BPMN, the business process model and notation, BPML, business process model and language. So this idea of orchestrating a number of things as a kind of process is a thing that has been around for quite some time.

01:19:10 Udi Dahan

Doing that a large scale, at the level of multiple systems type of thing tends to, as you were just saying, Christina, result in a whole lot of coupling, ends up being very brittle, often ends up performing very poorly. Because the process manager pattern, while it's great, in the small, in the certain isolated integration domain, doing it as a full blown architectural style usually is not appropriate.

01:19:40 Kenny

Great. I think ... whoa, we've been talking now for almost ... well, close to one and a half hours.

01:19:49 Kenny

Oh, yeah. It was really interesting.

01:19:51 Christina

Yeah.

01:19:51 Kenny

So what I hear back, a pattern that keeps emerging and it's also within DTD ... well, essential to DTD, is you need to sign your business domain first, and that's usually a problem I also see coming back. Usually developers are only used to increment requirements instead of, "Well, we need to make a collaborative space to get her to redesign maybe even the business process here." I see that thing popping up back in all the answers you gave, right?

01:20:23 Kenny

Look at your business process and analyze that more. Start there without jumping to conclusions like it's all these technical matters.

01:20:32 Udi Dahan

Oh, to be fair, and let's call it understanding of most people's, most developers contexts, if they did try to ask these types of questions and to engage in these types of conversations, the type of feedback that they'd get from business and management type folks is, "That's not your job. We will tell you what to build and you will build it."

01:21:04 Kenny

And we already spent half a year thinking this up, so we won't change it.

01:21:09 Udi Dahan

Right. So if that's the cultural organizational context that they're in, even attempting to go about doing that exercise is ... it's difficult.

01:21:25 Udi Dahan

The other thing that's problematic, also related to that, is that in the past, let's call it business analysts, or business analysis, as a profession, was something that was established and identified as having a meaningful and distinct skillset from the programming side of things. And in many organizations, that role was deprioritized and sort of degraded. So in various organizations that I saw people that had the business analyst title, they were often ... maybe typists is too strong a word, but they go have meetings with the business people who would tell them a bunch of things, they would structure and format that into the system that they used, whether that's [Gero 01:22:30], or what have you, and then essentially bring that information via those systems to the programming teams.

01:22:38 Udi Dahan

But there was not very much true analysis that was done, it was more a recording, a formatting, and a structuring of these things that were given. And so, again, even if that role existed in organization, usually it does not have the political capital, the seniority, the knowledge and skills to be able to significantly push back and engage with business stakeholders to perform this very necessary activity.

01:23:10 Udi Dahan

And then subsequently, things go poorly and the developers are like, "Why is the system performing so terribly?" It's like, "We built exactly what you told us to build, telling you that there would be problems along the way. You didn't listen and this is what-

01:23:27 Kenny

Have fun.

01:23:29 Udi Dahan

Right. And then it's only when they're in a great deal of pain that it's a, "So what do we do now," that occasionally somebody will send me an email and say, "We're in a mess, we need help." But usually it's the developers that do that. But it's only a result of there being a mess and there being significant business pain associated with it that the folks on the business and the management side are actually willing to listen for the first time, and actually accept changes.

01:23:59 Udi Dahan

So a lot of time, what a consultant does is they come in at the perfect time, when the conditions are just ripe for a whole bunch of discussions to happen that couldn't have happened before. And then it's all you need to make all of these changes. And the developer's like, "We've been saying that for years now. They don't listen to us."

01:24:21 Kenny

Exactly. Yeah. That's what always happens.

01:24:24 Udi Dahan

But the consultant comes in and then they listen to them and then, "Oh, yeah. Look at, they're so smart. Why didn't you just do that from the very beginning?"

01:24:32 Kenny

And sometimes even, what I've seen, being on both sides, is you sometimes have a consultant telling you what to do, but then you say, "Well, you have a good point but you're lacking our contextual situation too much, so here's a slightly better thing that we already set for half a year to one year." So, if you're not careful enough, the consultant will bring you in a different ... Well, now, me being a consultant as well, I always be careful

01:25:03 Kenny

Great, I think ... well, this ends this fireside chat. Thank you very much. I think we've covered a lot of ... you've covered a lot of ground already. There's been tons of questions. I hope ... well, people have a lot more questions now. But I think you tackled the main discussions that we are having.

01:25:24 Kenny

So I'd like to thank you and thanks for the audience of engaging with the questions.

01:25:30 Udi Dahan

If people want to go deeper into these things, again, there's only so much we can cover in an hour and 15 minutes, my five day course, The Advanced Distributed Systems Design is online. There's a bunch of free stuff on there as well as [inaudible 01:25:45] and whatever on the particular .NET site, but it really does require going deep into it. And hopefully, one of these days, the courses will go back to happening in a real life, in a classroom context, where everybody can travel and the high density experience of really dedicating time.

01:26:09 Kenny

Yes.

01:26:10 Udi Dahan

There's a lot of unlearning and relearning to do in order to learn and apply these concepts correctly.

01:26:21 Kenny

So please, yeah, just ... we'll add that to the resources onsite [inaudible 01:26:26]. Thanks. And thanks to the rest. For the people still watching or listening, we are also updating the site, so we're trying to add these resources to every session so you can go to the session page, this session now. Also, keep that discussion going there because we now added the comment section to all the sessions, so people can keep on track from there. Or else just go to the selection.

01:26:54 Kenny

Thank you very much and hope to see you-

01:26:57 Christina

Thank you both

01:26:57 Kenny

In the future. Yeah.

01:27:00 Udi Dahan

Thank you, Christina.

01:27:01 Kenny

And until next time, I'm going to stop the livestream and we can continue talking here and see how much time you have. But thank you for the rest. Bye, bye.