00:00:08.990
Okay, hi everybody! It's my first time at Wrocław Love.rb, and my first day at a Ruby conference. The worrying thing for me is just a little question, and I’d like to ask you because I see I'm one of the guys with the widest beard here. Is anybody else sporting a beard longer than 40 centimeters? Okay, how about those with over 44 centimeters? Well, this must make me the wisest person in the room, I guess. Hopefully! I still try to dress like a young person, but that doesn’t really work. Anyway, I've already spoken too much about myself.
00:00:39.020
I’m here because, yes, I do some programming in Ruby. I used to be a developer and I'm mostly working in the demand-driven design community, but not exclusively. Another thing that I do is coach joy in settings like this. I've been facilitating a lot, but sometimes it's more that we get a bunch of people really angry about the topics, and I’m asked to go into that room and take care of it, to get a whip and bring some peace out of this chaos. That's how I came into this role.
00:01:03.109
This became my background, even though I initially just wanted to code. Well, this is probably the main reason why I’m here to talk about Event Storming. I’m also a consultant, and I'm starting to get into lean consulting too. It's not just about starting with code; it’s about trying to move into different perspectives. The last thing I did was start my own company a few years ago. Now we’re a small group of people working together, and things have changed a lot since I began.
00:01:29.869
When I started, I was the person being paid to write code. Now, I'm on the other side, where I’m the one paying others to have code written. However, at the end of the day, I'm still writing my own code, mostly for myself. Just putting me on the other side of the fence changes things. From one perspective of what needs to happen, I learned the most important lesson that hit me hard with my face: the Theory of Constraints. Does anybody here know about it?
00:02:09.170
Well, some of you do! The fact is, you probably already know it by different names. It's what you do when you perform performance tuning or profiling with your application. The person who wrote about this is Eliyahu Goldratt, and the book that introduces the topic is called 'The Goal.' It’s pretty famous, especially in the United States, and it’s groundbreaking. It also lies at the heart of a concept you might know a bit more about: the Kanban development process from David J. Anderson.
00:02:43.650
I’m not going to delve too much into that; I’ll try to find a simpler explanation. In every complex system, there is a single thing that constrains the throughput of that entire system, which is often referred to as the bottleneck. The bottleneck is what makes things go slowly and prevents progress. Let's consider a concrete example: if you have a pizza restaurant, and your oven can only cook four pizzas at a time, inviting more customers doesn’t make sense. If you invite more customers than your oven can handle, they will wait longer for their pizzas, resulting in bad reviews and ultimately harming your business.
00:03:18.330
Now, this is mostly the same concept as safe performance tuning, where you find the bottleneck in your software and focus on optimizing it. If you're working to optimize an area that isn’t the bottleneck, you’re essentially wasting your time, or worse, causing harm by optimizing the wrong thing. These are the basic rules: find the bottleneck, improve it, and soon the bottleneck will move to another area, allowing you to tackle the next one. The key takeaway for me was if we improve the bottleneck, we improve the entire system. But if we focus our efforts elsewhere, we’re just doing things without any substantial effect.
00:04:28.920
Now, you might wonder why this is important. For me, as a developer, it's crucial to identify that bottleneck. As a lean consultant, I help my customers find their bottlenecks too. Should developers care about it? The answer is yes, for a very good reason. Market and customer uncertainties along bottleneck activities will only attempt to cut costs. Customers working on bottleneck activities will have a strong interest in improving performance in that area because doing so would enhance their business.
00:05:10.889
This also means that our working conditions might differ greatly if I’m working on a non-bottleneck activity with a client who merely wants to reduce costs. I’m sure you can guess how that ends up — we might get pressured with deadlines and an increasing workload until one day, we lose everything to a cheaper country. I definitely don’t want to go there! This is precisely why I care as a developer about what the customer is asking me.
00:05:53.039
When the customer asks me to do something foolish, I’m not going to see any good outcomes in the bottom line. There’s much at stake regarding collaboration, but it’s facing some challenges. The first problem is that customers may not know what the bottleneck is. I know quite a few customers who say, "Yes, we have problems." That’s an easy statement to make, but the key question is: What’s the most pressing issue? Customers might claim they have many problems, but if I choose incorrectly, I could invest a lot of effort with no visible results.
00:06:45.919
An additional issue arises because they might be aware of their main problem but may not confide in you as a developer. Now, here's a little business secret of mine — and please, don't tell anyone; it could cost me more money! You might encounter different types of customers, and our challenge is to find the right direction to take. This challenge is hugely rooted in specific types of commercial enterprise software, but it doesn’t differ that much if you’re in a startup.
00:07:19.900
In a startup, it’s crucial to identify your bottleneck, which might be poor conversion rates or insufficient customers. The focus is on continuous improvement. If you're in a startup environment like Lean Startup by Eric Ries or Ash Maurya's approach, it’s just about making ongoing experiments to understand what needs further enhancement.
00:07:38.530
Moving on to topic number two — I would like to connect this to domain-driven design. I also need to express my sincere gratitude to those who shared a hamburger with me yesterday evening, as our conversation was so insightful that it prompted me to completely reshape my presentation.
00:08:08.680
So, let’s talk about domain-driven design! How many of you are familiar with this concept? Well, about 28.5% of the audience, which is a good minority! Now, what people typically think about domain-driven design is that it’s an architectural approach. However, I find this perspective slightly lacking.
00:08:24.970
Interestingly, many well-known individuals in the community have similar responses — in fact, I would say 90 to 95% of the people discussing domain-driven design outside its core community may see it as primarily an architectural approach. This gives us a huge opportunity! We need to correct this misconception. It’s not your fault; we’ve done a poor job communicating this from the start. Domain-driven design is not simply an architectural approach, nor should we view it as just over-engineered solutions.
00:09:01.120
While it's easy to criticize over-engineered software, it’s essential to recognize forms of architecture that should support frequent rewrites. Sure, we need methods to optimize our outputs, but we cannot ignore the complexities in certain environments. This is why domain-driven design has value — especially in complex domains that require rapid changes and not just in writing software quickly. Well-structured software allows for more frequent rewrites without significant hurdles.
00:09:58.420
For example, if you clearly understand the model, you can determine if it’s simple enough to tackle right away. To illustrate, consider an example from cinema: if you were to watch the movie 'The Sixth Sense' without knowing Bruce Willis's fate from the beginning, you’d be drawn into the entire experience. If you knew right away, you’d likely feel like you wasted your money on the ticket!
00:10:43.170
Philosophers might argue that it’s about the journey rather than the destination, which is a nice answer. However, the reality is that for many people — like commuters on an Italian train — the destination is what truly matters, and they want to reach it as quickly as possible.
00:11:20.640
So, my point is that not all journeys are equal. Some involve strategizing effectively while others do not. For example, if anyone remembers my previous presentations about pigs, hams, and similar projects, well, this time I won’t use that theme. The point here is that a worthwhile journey in the domain-driven design community is what we define as the core domain.
00:11:59.650
There’s a significant link between the core domain and the exploration area where you’re most likely to derive value. This requires conducting experiments to uncover potentially lucrative areas — whether or not you realize them upfront. If you're in a competitive market, these experiments become critical.
00:12:36.250
Now, to connect the dots, we see that many developers try to explore customer collaboration as a means of creative synergy. Both agile methodologies and domain-driven design emphasize the need to collaborate better with domain experts. However, this can be complicated, so how should we effectively gather requirements in such complex environments?
00:13:08.510
Typically, when I've encountered requirements gathering in corporate environments like banks or insurance companies, the process follows a familiar pattern. It's like a scene from 'The Usual Suspects' — you gather all necessary viewpoints to answer questions. You schedule interviews with several people to collect requirements, which eats up a lot of time. However, once you compile the information, you find that everyone describes the problem differently.
00:13:55.500
Suddenly, questions arise as you wonder why individuals don’t agree on certain aspects. The sad truth is that they may not even want to agree. This realization is important because ambiguous specifications can often be a trade-off — a category laden with conflicts between stakeholders. So, we may create ambiguous terms just to please various parties.
00:14:30.290
To mitigate this, I developed the Event Storming solution, which started as a small idea but proven to be effective. The essence is to gather all key stakeholders in the same room and build a model together. It may sound simple, but instead of having them face each other at a table, we should consider a more collaborative environment.
00:15:03.070
For instance, instead of seating everyone around a table, let’s utilize a space that allows for free movement and interaction. When we held an educational workshop with Matthias in Amsterdam, participants were very engaged, and after two hours, they often requested a break because of the intense energy output!
00:15:50.840
The key is to break some assumptions and manage this interactive environment wisely. By shifting from sequentially gathering input to fostering chaotic conversations, we can save time, as we’ve gained weeks of progress through this approach. Our aim is to involve everyone in contributing to the process.
00:16:32.800
To facilitate this, trick number one requires participants to collaboratively write down domain events on sticky notes rather than having one person write while others supervise. This pattern resembles the behavior of workers, where everyone looks toward a single contributor rather than participating. By distributing tasks, we can significantly enhance throughput.
00:17:00.360
Moreover, people must feel empowered to share their thoughts. It usually takes two or three minutes for a meeting to reach peak efficiency; after that, participants can’t stop modeling unless they are exhausted. Typically, in a few hours, they create intricate models due to this environment.
00:17:43.440
While I initially approached this observing the participants to understand their motivation better, I later discovered that much of the technology evolution results from boredom! Many project teams start rewriting software or swapping technologies simply because the old system becomes tedious. This realization opened my eyes to the necessity of fresh approaches in tackling business problems.
00:18:30.580
In scenarios where we gather different stakeholders into the room, the process can unearth several underlying issues. By using paper rolls and sticky notes in a more liberated format, we develop a solid model fairly quickly. This isn’t merely about speeding up the planning process; it’s about creating an environment where ideas flourish.
00:19:02.540
Moreover, I've also come to recognize the point where it’s essential to delineate boundaries in our models. We need to map out the intricacies in the workflows and interactions to facilitate better collaboration among participants. Understanding where different components fit into a larger context can evolve our perspectives.
00:19:48.670
Furthermore, adopting a transparent process allows for clearer insights into problems. In one of our workshops, we ended up discovering many hidden issues that our customers hadn’t realized existed before, which drove change. The model we built together wasn’t merely a representation of tasks; it reflected the coordination needed in their processes.
00:20:30.350
As we dive deeper into creating models, the important takeaway is to ensure we have sufficient space while maintaining clarity of roles. Another aspect that often emerges is the framing of concepts, such as recognizing domain events that hold business significance over mundane actions that might save code.
00:21:05.770
In our workshops, certain terms — like commands and events — open paths for greater discussions. What we need to focus on are business-relevant events and processes to establish a clearer understanding. Once we clarify what constitutes a significant event, we can structure others around it.
00:21:41.540
Structures must evolve flexibly as we maintain consistency across the board — namely ensuring that models share the real business process. With events tied to business operations, this should bridge definitions across varied contexts and offer straightforward explanations.
00:22:27.700
Think of it as ensuring that our decision-making frameworks match real-world experiences. When you ask someone to make a decision about ordering pizza, let’s base it on actual cuisine options shown — not on obscure data from a backend system waiting to pull information!
00:23:14.420
To sum up, when we frame conversations and discussions under these models, they generate a lot of engagement among stakeholders. As developers facilitate workshops, they start learning contextually rather than simply analyzing code. Our collaborative effort usually reveals profound insights for everyone involved.
00:23:58.920
At the end of this process, colleagues discover areas with deficiencies in understanding. Conversations deepen because they engage with systems thinking and invite perspectives that reveal emergent narratives about their work. This reciprocity builds a culture of improvement and collaboration.
00:24:42.950
In conclusion, gathering feedback from these interactions forms an integral part of the iterative process that drives an organization forward. The Open in dialog while modeling enables us to address miscommunication from day one of a project — essential to any successful venture!
00:25:25.530
Thank you so much for your time, and feel free to continue this discussion afterward. I’d love to hear your thoughts on implementing these concepts in your businesses! If you’d like to get to know more, you can also find resources on my blog and in the Even Stormers community on Google+.
00:26:09.930
Thank you very much, everyone! And now, I will open the floor to any questions you may have.