Some updates about EventStorming

Hi everybody. After a long silence I finally found some time to start writing again some content for this blog. Well, many things happened in the meanwhile in the EventStorming space, and I finally managed to find some time and discipline to start sharing our findings more effectively.

In the meanwhile, EventStorming found its way through word-of-mouth, twitter and conference workshops. But it’s looking like a web version of Fight Club: getting viral and secret at the same time. Maybe it’s time to make some change.

EventStorming Community/Mailing List

I’ve started a new public community on Google+: it’s called EventStormers. Here’s the link. I’ve chosen Google+ mostly for the look: our content is a lot more visual than other discussion groups, and I felt that Google+ was a good tool for that. I know there are some drawbacks too, but it’s working well, so far.

Some colleagues were already sharing content on the smaller private community called EventStorming Practitioners. Communities rules prevent me from turning the old one into a public one. So, members of the private community, which are ok with the idea of going public, will have to share their stuff again. That includes me too.

Writing some stuff

It’s no secret that I am planning to write something more than a blog post. EventStorming and Model Storming are tricky topics (and yes, I am aware that I haven’t published much about Model Storming and that many people are still confused about the two terms).

Telling the what might be relatively straightforward, but telling the why  and exploring the how can take ages. However, I finally acknowledged to focus on EventStorming for now, and I am working on readable content. Portions of it are actually making their own way to the blog.

But that’s the offer. I am writing about things I care and think that are worth sharing. But - as every blogger knows - I also write pushed by the urgency of a freshly learnt lesson. The drawback is that this is too much self-centred.

So I am asking your help.

If you are curious about EventStorming, please join the community and start asking questions, or maybe ask what you would like to know about EventStorming right here in the blog comments. I’ll do my best to share the answers I know, and find the ones I don’t.

Thanks everybody

 

 

Go personal to boost engagement.

Weird episode during today's EventStorming session. We had a meeting room with a big wall available, that we set up with a plotter paper roll. The room had a big table, that could not be moved away so we simply moved it aside, to provide more space in front of the Modelling Surface.

Unfortunately, it wasn't enough. Some participants showed up a little late, so we waited for them. When they came in, they saw other participants sitting (cause we've been waiting) and immediately grabbed their seats. Hrmpf! :-/

Well, I thought: "This isn't going to last much" and said politely: "You won't need your seat. We'll be standing most of the time, working by the paper roll". What I didn't consider was that many of the participants were ladies, and the answer was: "We don't have the right shoes for that!".

Ouch. Surprise. I've never thought about it. :-(

Add that to the fact that I couldn't adopt my usual I'll-kick-you-in-the-butt strategy that works perfectly with developers, (I am a gentleman, after all), and for the first time having people stand up became harder than usual, resulting in lower-than-average engagement and less observable body language, for a while.

Time for a Plan B

The surprise trick that really worked well was "could you please add Actors close to the corresponding event?" and since "actor" meant "me" for many of the participants, they all stood up and added information to the model, raising engagement at the same time. Wow!

Ok, lessons:

1. As Jef Claes reminded me, remove seats. I focused on the table and forgot the smaller enemies. Seats were still there, inviting and comfortable
2. Environment matters a lot. And preparing the meeting is really important. I did a survey on the room before the meeting (something which is hard if I travel to lead a workshop), but I focused on surfaces, and space. Maybe is time to set up a room preparation checklist (next post, maybe). As Sun Tzu said: "Every battle is won before it's ever fought"
3. personal involvement (actor == me) works pretty well as an engagement booster. I normally go to actors together with Command exploration, but in this case (small timeframe available) it was better to go straight to the actors.
4. shoes... maybe mention 'bring comfortable shoes' in the invitation.

EventStorming: invite the right people

Invite the right people

People are the primary ingredient for a successful party. You’ll need good music and drinks too, but if the girls won’t show up, the party will be lame

You’ve been reached by some buzz around EventStorming, you may even have experienced it in some evening event t the local user group. Now you fell like trying the experiment in your own company. But then a question pops up.

Who should be invited?

Ideally, one would like to have participants coming from two fields: people with questions and people with answers. They provide the perfect mix of curiosity and wisdom.

When exploring complex business domains (the scope of EventStorming is usually the whole business flow) this implies that a lot of people should be involved, and triggers a lot of warnings. Let's see some.

• They won't be available at the same time.
• The meeting will turn into a waste of time, at least for many of them.
• You'll end up nowhere due to conflicts that may arise.

All these worries are legitimate. But they lead us to do things in a way that doesn't work. The meaningful conversation with the Domain Expert that is at the core of Domain-Driven Design is often not that meaningful.

Should I look for specific roles?

I am somewhat reluctant to map those people to company roles for a couple of reasons: personal attitudes are more important than roles for the workshop to deliver, moreover I’ve seen so many different, somewhat dysfunctional company structures that tying myself to randomly assigned roles is not a wise choice.

So I won’t provide any answer like ‘every developer should attend the workshop’ or ‘only team leaders, business analysts and domain expert should be there’. Instead I’ll suggest to take a different path.

A somewhat zen answer

The best answer that comes to my mind is something that may disappoint you: “Just close your eyes and imagine the perfect meeting, where curious people with the right questions get answered by people who know the answers, or are honest enough to say that the answer is yet to be found”. Now name the people you saw, and invite them.

It’s no different from what you would do for organising a party. The party won’t be perfect if the right people won’t show up. Now, do you invite friends to the party according to their roles or attitudes?

A more cynical answer

If this sounds too mystical, or you feel that the key people won’t show up, you may run the opposite approach: “In a year from now, after the project has been a complete failure, burning a couple of million euros, your company will run a post-mortem meeting. Who do you think is going to be there?” And if they don’t look like interested in your unconventional type of meeting you might present the bargain: join the meeting now instead of the post-mortem, you might save some cash this way.

Conflicts are fine

The most common objection, albeit often implicit, is that if we bring all of those people together we won’t be able to handle the conflicts. This is very likely to happen in a traditional meeting, but remember: this is an EventStorming workshop: no tables, no boredom and an unlimited modelling surface on the wall.

The fact is conflict is there, and probably will be there tomorrow too, and it will probably be one of the most dangerous risk factors in your project, so why waiting?

In GOOS book, Freeman and Pryce introduce the notion of Walking Skeleton like the minimal piece of code that touches all the possible architectural pain point, as soon as possible, because you don’t want discover critical spots too late in the project.

I think this approach is really effective, and I also believe that most of the risk in large scale enterprise projects resides in people, so I'll try to reuse the idea and try to get in touch as soon as possible with the key people that could be the biggest source of risk in my project.

Managing conflicts

In EventStorming we’ll have many people discussing around a model they’ll be building collaboratively. For most of the time they’ll care about the area they’ll know more, and the workshop will achieve interesting speed allowing them to work in parallel (we have an unlimited modelling surface, space to walk, plenty of stickies and working markers, remember?).

You may discover something interesting in the way people group and act in front of the modelling surfaces. Some people will take explicit ownership of given portions of the modelling space (which later you may want to label as subdomains), others would be more reluctant, or dubious, maybe they’re not the real domain experts. Some would try to impose their own view over the system, others would try not to contradict their boss. Help them, provide enough markers and stickies to allow them to publish their view too and to let diverging perspectives emerge.

A place for hotspots

One of the things I love about EventStorming is that it provides a safe place for finger pointing. Given we’re building a modelling artefact, we actually can finger pointing at the stickies. When somebody says “it’s not exactly like that”, that’s the moment to listen to a story: “can you explain us why?”

The interesting thing is that, the physical model makes it easy to trigger the conflict - because you see what’s wrong -  but also helps in keeping the conflict at the model level, without turning into a personal issue. As I said, there’s a lot of value in discovering modelling issues and underlying conflicts, the earlier the better.

Solving some conflicts…

Many conflicts may in fact be solved using one of Domain-Driven Design secret weapons: Bounded Contexts. To put it in practice during the workshop, you just need to accept the fact that two diverging opinions by two domain experts may be both right …in their own place. In fact Bounded Contexts are like separate room with their own private model which is perfectly fit to the needs of their corresponding domain expert.

To put it in another way: you won’t solve conflicts by reaching an agreement, or - even worse - a trade-off. You can solve some conflicts just by assuming that the two views are equally valid, and that it would be your job, as a software architect, to find the best way for them to co-exist.

… and get along with some others

Bounded Contexts are great. But they’re not magic. Some conflicts would be resolved by deeper exploration, and that would need time. Time that you probably won’t have during the workshop. Some others, would never be solved (the I-hate-you-damn-bastard-and-I-always-will category, for example).

The best thing to do here is to mark the hotspot - possibly with a vivid coloured signal - advising that this is danger zone, and move on to the best area. This is already really valuable, and nobody is asking us miracles. Endless debating over a single issue might turn the workshop into a boring meeting, so keep the discussion short if there’s no easy way out. Other participants will appreciate it.

In general I am not trying to solve issues or to take decisions during an EventStorming session. My primary concern is to keep the workshop flow going, to have everybody engaged in what we’re building together.

What if we won’t have all the people?

Given a lot of the value resides in observing the interactions between participants, for every key person missing you’ll be losing the value of the interactions between him/her and everybody else. You can do your math, it’s not headcount, it’s counting relationships.

Beware of those folks who promise they’ll join you later. Especially if they are Italians. They’ll miss all the key information: one can not understand a movie from the ending titles, and being there is the most successful ingredient.

Just getting there

However, one might have to acknowledge what’s the real starting point (and I have an easy one: people invite me to run EventStorming sessions in their companies) and get along with that. Every organisation is different.

Sometimes getting the right people on board might be a long process. One may actually get there step by step, so even if I personally prefer to fight for my right to party there might be situation where a temporary trade-off is necessary. Here are some basic tips to get you started.

• Declare experiments: be honest, this might be the first time you run an EventStorming workshop, and even if you attended one, being on the facilitator side might be totally a different job.
• Manage risk: what is the worst thing that can happen during a meeting? It’s probably wasting time… oh, you’ve never wasted time in your company (sarcasm).
• Timebox: every open ended meeting might bloat. Keep it under control key people won’t be available for the whole day. Keep a visible agenda, or a timer. Just try to use participants’ time in the most effective way.
• Look at people’s faces: bored people tend to look bored. Just ask them why they’re not finding interest. And take some corrective action.
• It’s not a trap: some people will look like they shouldn’t really be there. Let them go if they don’t feel like. I normally try to take mobile phones and the like away to have full attention, at least for a limited amount of time, but some roles have different degrees  of machine slavery.
• Take breaks: engagement is good, but drains you energies a lot. You don’t want to be in low fuel status. Take a break, maybe every 45 minutes, and enjoy it.
• Retrospect: whatever the outcome is, just find some time to highlight achievements and problems of the meeting, to be sure next one will be even better.

In some organisations, key stakeholders won’t be available at the same time, or won’t free their time for just another meeting. It’s fine. You haven’t achieved anything yet.

Let your first EventStorming build some reputation in order to be attractive for key domain experts, in the next session.

Introducing Event Storming

Disclaimer: This is the seminal article about EventStorming. This is where everything started, so I think it's relevant to keep the original. At the same time, EventStorming has evolved a lot since I wrote this article, and the format described in this page is no longer my favorite one. In fact, there's not a single EventStorming format, the tool proved itself so versatile and powerful that I perfectioned a few different recipes. I also had to start writing a book about it, which is slowly progressing to completion. As of today, the better entry point to understanding EventStorming potential is probably my presentation 50.000 orange stickies later (which is also available in video) or reading the first chapter of the book, which is available for free. We are also working on a new version of the EventStorming.com website that should organize pointers to the interesting content about EventStorming that many practitioners published.

My perspective on the coding versus modeling balance

Root Cause Analysis stencil uploaded on Graffletopia Stencil

There are few OmniGraffle stencils which I use frequently during my consulting gigs, especially while gathering information for a change initiative, and in presentations also. One of my favorites is the one I just uploaded to Graffletopia for sharing.

Notation info

• Observable Facts are ellipses (or bubbles). 
• When using a tool for drawing like OmniGraffle, I take advantage of colors to display perceived severity. White is neutral, from yellow to red is bad. Black is disaster.
• Border thickness maps to our perception of our ability to affect/change a phenomenon. A fact with no border is under our control, a fact with a thick border is something we cannot influence easily. A company policy which is generating an undesirable effect might be mapped like a constrained fact (but later, you might be in the position to influence it).
• Unknown Areas are represented as clouds. There's something important there which we don't know yet.
• Question marks are part of the stencil as well. I never know everything, but mapping the things that I don't know is often a good idea.
• Since my primary use is to collect information for change at a system level, local solutions are part of the notation also.
• Direct dependencies are represented by arrows. 
• Dotted line arrows represent indirect dependencies. I'm less strict than some other more precise notation, I use the same dotted line for not-so-clearly-related facts and for relationships with delay. It's less precise, but at sketching time I probably don't have enough information to make a clear distinction anyway.

Some guidance

I have to admit I am driven by instinct more than a real formal process. However in drawing the map I have influences from Peter Senge ("The Fifth Discipline"), Craig Larman ("Scaling Lean & Agile Development" and from Eliyahu Goldratt (who described the Reality Tree in "It's not Luck!").

Collecting Data

I start collecting sparse data, from my observation. If I can draw direct links, I add them. If a fact has no clear explanation, I add a cloud or a question mark. Same goes of the causal effect link is no sufficient to imply the consequence. The fact that it's raining doesn't necessarily imply that I'll get wet. But if my car is broken, and I have no umbrella, and I have to go shopping for food, that's another story.

I don't need that much precision on the constraints. I like to capture the mood. If the team says there's nothing that it can be done about a policy, I'll draw it as a constrained fact. But I'll challenge that assumption later when it comes to use the drawing for collaborative problem solving,

Please feel free to share your comments. Hope you'll find it useful!

Setting up a DDD sample app

The guy who started it all is called Emanuele Del Bono. He’s a friend, a nice guy and a respected colleague. He participated in the first Domain-Driven Design class of my company, and also did a fantastic job in finding a suitable place for the class. He is also one of the guys that animated a discussion on the DDD-IT mailing list that urged me to write this posts, some time ago. So I should have been warned about the danger behind his simple request.
Some weeks ago, he complained about the lack of code example in the DDD-IT mailing list, and challenged the list to see if anybody dared to post the code of some aggregate. Innocent and legitimate request, ...or so it seemed. However, since he used the word “courage”, the one that kids use among themselves to do things they will regret, I accepted the challenge and started working on some code that could be shared, and found useful by the list.

Why should I regret it?

As I said, the request is both legitimate and innocent. What could be the drawbacks. I can point out two.

Time: I like to do things well, and sometimes I tend to get lost in meaningless details. So, for me, doing things right will take time. Given how busy I am, there’s a clear and present danger of never finishing the stuff.

Questions: there are many things that I don’t want to talk about when talking about Domain-Driven Design. Frameworks are one of these. I use some of them, but I can’t really say I love them. However, I don’t like questions like “how do you do this with Spring and Hibernate?” because you can probably do it in a smarter way that I can figure out. I think one of the values of DDD is to provide a conceptual background where these type of problems, decrease their importance to the point of being mere implementation details (even though they can make your time a hell if they don’t work exactly as expected). So my worry is to get too many questions focusing on the wrong side without really clarifying doubts on the part that matters most.

Choosing a domain

I definitely need something different from Cargos. Since I know the training domain a little, and used it also in the recent DDD school camp, I decided to choose this domain. However, as will be clearer later, we’ll need precision in defining what this is really about. Simply knowing how things work in the training domain won’t be enough.

Choosing a programming language

Since colleagues were eager for code, the first thing to do was choosing a programming language to actually show some code. The obvious choice was to choose my favorite language and get along with that. Problem number one: I don’t have a favorite language. Problem number two: there are too many things in the code that could divert both writer and readers attention from the actual scope of the task.

Java: this has been my first choice, a little conservative I have to admit. However, it’s bee a while since I wrote some java code, and I stopped following Java trends after Oracle’s takeover. Last but not least, all of my local configuration needed an update.

Groovy: a lot more pleasant to work with than Java, but to make it really pleasant I had to deconstruct Grails a little, in ways that might look obscure to most readers, carefully selecting only some of the available features. Good topics for a blog post, but not for this app.

C#: though I’ve been recently playing with the platform, and I appreciated some features, I still don’t feel like it’s mine. Still too hard for me to distinguish good and bad stuff.

Ruby: I am relatively new to the language, and probably missing some key tips on the technology stack and on the programming style (“You still think like a Java guy” Paolo Perrotta once said, I hope I improved a little since then…).

Given this starting point, I started with Java. I thought I could set up quickly a skeleton architecture with Spring, like the ones I was used to work with.

So I opened up the IDE and started coding.

Wrong choice.

After setting up an Aggregate an some satellite Services that did their dirty job, or faked it with a mock implementation, I finally realized that I was getting all wrong and was underestimating the task of writing a sample application. What was my problem?

Ambiguity.

The model I was building looked perfectly sound from a “modeling” perspective, but I was getting uncomfortable in the multiple roles of developer, analyst, and domain expert or product owner. Moreover, the “let’s show some code quickly” approach that I started with, didn’t really work. To define exactly what my aggregates were supposed to do, I needed a lot more precision, since a little business tweak in the underlying domain would have driven me in divergent modeling choices. I needed consistency and unity of vision in my domain, before I could implement it in my model.

Well, that was no surprise. That’s exactly what DDD is for. And a common, simplified development cycle is:

1. gather some information from the domain expert about features A, B and C;
2. quickly implement it as a domain model, using DDD patterns;
3. spot contradictions in the current understanding of the domain, that emerge from the model;
4. refine the model, asking to the domain expert what he precisely meant when he talked about features A, B, and C.

The only weird thing is that all the roles are in my head now. And to keep my sanity and stop swinging from one interpretation to another one of the same corner of the domain, I need to be a little more structured, and define exactly what I want from myself.

Providing a little structure

I want to model my aggregates around a problem, and I want this to be precisely defined. So, despite this being just an example, or maybe exactly for this reason, I can’t go for shortcuts. Let’s start with a user story and see where it lead us. 



My first problem was to find a good name for my role. I mean, my company is rather small, so there’s not much of a clean role separation. I could have put something like “as Me” and was probably going to be more correct, even if less portable.

However, that’s defining the starting point, and the scope for the first iteration. But it’s not precise enough. Let’s nail it down with an acceptance test.

Scenario: Publishing a new training
Given a Catalog
And a Training gourmet coding not yet published
When I publish Training gourmet coding on Catalog
Then Training gourmet coding is available on Catalog

And try to make it work. Of course this means setting up Cucumber in the development environment, something I thought it wasn’t strictly necessary, but I realized I am getting addicted to.

By the way, despite my previous experiences with Cucumber and Java, and the precious guidance by the secret ninjas cucumber scrolls, setting up again Cuke4Duke in my project didn’t work that smoothly. Looks like Maven got in the way. Again.

No, please. Not that again.

In a second, Maven destroyed my pleasure. And made me think that, even though I am still a rookie on Ruby, every second spent on solving problems on Ruby is a second spent learning, while the time spent on Java is probably wasted. So, after just a few minutes, I already dropped my platform and started again with Ruby, instead of Java. But this sample app is a sandbox, for learning and experimenting. Needs to be fun.

Modeling question number one

Do I really need a catalog? When thinking about managing trainings, a Catalog is the abstraction that naturally comes to mind. However when I started thinking about what I really wanted to do with this application, I couldn’t find any behavior for the catalog within the boundaries of my application. I said “boundaries” which means that I need to define scope more precisely. A little context map will do the job.

The ultra-basic context map, with my application and an Anti-Corruption Layer separating it from the external website model

 The main idea, for now, is to manage the trainings locally and trigger a publishing action on an external website. I have no idea about how to do that, but I need to make it clear that I am not directly working on the catalog that is visible to a potential customer. I have an external website for that. Maybe some hosting service exposing APIs would do the job. But I don’t want to know that. Right now I just need to know that I won’t publish directly on that. I’ll hide the details behind some domain service and hide all the little dirty things needed to complete the job behind the curtain of a neat interface. More likely, I’ll pretend to do that, and shamelessly fake everything, but behind the same interface.

Ruby, the architecture and me

I hereby state loud and clear my ignorance about the architectural patterns in Ruby. I don’t know much about it, so whenever you see something that doesn’t quite fit the picture or that seems awkward, feel free to comment and correct me. The only thing I am almost sure about is that I don’t want to use Rails. Can’t say it won’t fit in the picture (I am not looking for a 100% DDD application, and I can figure out portions of the application that could be implemented according to that paradigm) but definitely Active Record is not what I want to start with, and definitely I don’t want a full framework stack. I want to add things little by little.

Persistence framework

After exploring a little, I’ve chosen Sequel. A lightweight persistence framework that can be used at two different levels of abstraction. I started with the very low level approach, so my repositories now look a little vintage. :-)

Also DataMapper looked interesting. I’ll probably give it a try when trying to make the architecture a little more agnostic about persistence frameworks.

The trickiest part so far has been separating persistence instructions from transaction management. In a typical DDD architecture, transaction management is an application layer concern, but this seems to be at odd with most of the examples regarding ORMs and persistence frameworks in general.

What I like so far

I really like the Ruby testing stack. Cucumber and Rspec are incredibly well supported by RubyMine, and coding is a pleasure in this area. Getting to all green is always a pleasure.

What I don’t like so far

Of course the database had his revenge after that presentation. SQLite rebelled and I wanted to test the app also with some real DMBS, but installing MySQL has been a little pain (well, the actual installation run smoothly ...it just didn’t work with my Ruby version). I had to switch to a different Ruby version and to reinstall it before having it work with my stack.

There are also a few things that don’t feel right on the architecture. I missed some of the things Spring was doing behind the scenes, and that used to be my default paradigm so there is a high possibility that the whole stuff looks like a Spring based Java application in Ruby dress. Some patterns which are relevant in Java and C# (like Application Facade and Repository) probably have a more elegant alternative implementation in Ruby, and there are some Singletons around (forgive me) which are basically placeholder for a different implementation. In general wiring up is not as elegant as I would haver liked.

Ok, but where is the code?

I’ve started a project on GitHub. It’s called D3N. You can find it there. It's still naive, but I’ve tried to do things well and started to post also issues about the things I want to cover/experiment in the next weeks. At the end I am thinking more about a playground than a “sample app” (I hate this term).
So far, there's not so much to see, but I've been writing a hell of a long post. Let's try to get more use cases implemented and more coverage of the actual evolution. As I said before, there’s a lot more in doing a DDD application than just the resulting code.

As somebody once said: it’s the journey, not the destination.