“I open Pandora’s box” – An interview with Alberto Brandolini on Domain-Driven Design and EventStorming

EventStorming Creator, author of Introducing EventStorming – An act of deliberate collective learning and founder of Avanscoperta , Alberto Brandolini is a 360° consultant in the Information Technology field. Asserting that problems cannot be solved with the same mindset that originated them, Alberto switches perspective frequently assuming the architect, mentor, coach, manager or developer point of view. In November, he is visiting Germany to give his workshop “EventStorming” in Munich . We had the opportunity to interview him.

codecentric: In his book „Domain-Driven Design“ (2004), Eric Evans proposed an approach to designing complex software systems from the business first, starting with a domain model, which requires domain experts and software developers to work together. To achieve this, he provided a framework for making design decisions and a vocabulary for discussing domain design. Can you give us a short introduction why a common understanding of the business domain matters in our industry?

Alberto Brandolini: I think Domain-Driven Design (DDD) exposes a fundamental flaw of software development for the enterprise: the notion that we can build – horrible word, the software is not a house! – software upon trusted requirements.

This is an illusion, and a dangerous one. Some requirements can be certain, like “It should be possible to import files from version 2.1”. But many of them are going to be uncertain even if they seem to be carved in stone. 

They’re going to be contradictory, because of the nature of organizations: silos and departments with different views and needs, not to mention the hidden conflicting goals. Eric Evans also shifts the focus to the language. The language itself cannot be trusted: terms are ambiguous in their nature, different people will have a different interpretation for the same word.

So DDD promotes a way to develop software that assumes a high level of architecture fluency and proficiency – to have more options available – and allows the development of multiple very efficient models perfectly tailored to the local contexts.

The enemy hiding in shadows is the notion of “the large data-centric model” that was so pervasive in the past years. The fundamental ambiguity of the language was ruled out by data-centric implementation that forced entire organizations to agree on what a “Customer” or an “Order” meant, forcing them also to agree on ways to share data, only to find themselves locked in a stalemate a few years later: everybody is depending on the same data, so changing it is now too risky. Confidence is gone, evolution slows down and workplaces stop being interesting.

I think the whole problem has been there for a very long time, but it’s exploding now for two factors. The first one is Microservices: they’re fashionable right now, but their promise can only be fulfilled with a DDD way of thinking especially when it comes to Bounded Contexts. The second one has to do with the job market: there’s a growing trend of developers leaving unhealthy workplaces, and in my opinion, there’s a strong correlation between given architectures where the dominant feeling is fear of breaking things and the inability to retain talent.

It turns out that a deep understanding of the business – as advocated by Domain-Driven Design – can be a great driver for a more purposeful approach to software development: we understand what’s the right thing to, and we turn it into a software solution with the lowest number of trade-offs.

Feels good, and makes me want to stay to see the end.

codecentric: In 2013 you introduced your workshop concept “EventStorming”, which translates the DDD philosophy into a group collaboration format and light-weight modeling technique. How did you discover it?

Alberto: EventStorming didn’t happen as a planned discovery. The first time I started modeling with colored sticky notes on a paper roll, it was in a little meetup between friends and colleagues of the Italian DDD Community. 

It’s interesting to look at the details: the meetup was happening on Saturday and I drove 200 km to get there. I took my tools with me: sticky notes and a paper roll. At that time I always had a paper roll in my backpack, because I couldn’t stand the constraints on meeting rooms shape and availability. My friend Emanuele Delbono was hosting the workshop and described the process he wanted to explore, and then we split into groups.
I needed to baseline something quickly so I took the paper roll – there were whiteboards, but there were other teams too – and started to lay down my understanding with the DDD and CQRS building blocks, and got to something in a few minutes, while the other teams hadn’t even started. Ok, I had a good hand this round.
But I think the surrounding matters: it wasn’t a business environment, it was among friends and it was a Saturday. This combination gave me all the possible freedom for experimentation: I was amidst smart people so I could skip the introduction and get straight to the point, and I also knew that we were there to discuss. Shortcomings in an experiment would have been addressed.
Later, I started using this approach – initially called Event-Based Modeling – to teach DDD building blocks to newbies, without passing through the traditional definitions. And it worked and got some practitioners hooked.
The real explosion happened when Vaughn Vernon invited me as a ‘special guest’ on his IDDD tour, in Leuwen and Cracow. That was not ‘just a class’. There were 50-70 amazing people in the room and they loved EventStorming and started experimenting in their workplaces, in their local communities and providing incredibly valuable feedback, ideas, and variations.

codecentric: In the past, you have compared EventStorming to creating pizza – which seems alarmingly trivial, considering the complexity of the problems that want to be solved …

Alberto: I still do! But I don’t think it is trivial. I am Italian and aware of the real complexity of making a good pizza. A good friend of mine is into the business of gourmet pizza, and there’s definitely a lot to know to make a memorable product out of apparently simple ingredients. So, pizza is definitely serious stuff for me.

The point I am trying to make with the pizza metaphor is that collaboratively validated business storytelling is a platform for more sophisticated reasoning. I have variations for the big picture recipe that could go for an ‘Enterprise Retrospective’, an ‘Organization Reboot’, a ‘Startup Design’, or a ‘Launch new Product’ type of workshop. They share the foundation, but the steps can be different.

Also, Process Design and Software Design are very different from the big picture recipe: here we’re building something, collaboratively enforcing a colored grammar that serves as an interdisciplinary lingua franca. The dynamics here are really different, but still, the basic ingredient is validated event-based storytelling.

Some colleagues developed their own variations from that recipe: Konstantin Kudryashov visualizes delays to get a Value Stream Mapping out of it, Paul Rayner, Wojtek Ptak and Mariusz Gil had interesting value-oriented variations too; Jacopo Romei uses Big Picture to visualize inconsistencies in organization culture and behavior. Not to mention more radical offsprings like Adam Dymitruk’s Event-Modeling.

What amazes me is the possibility of combining some elements from everybody’s background into a very flexible and powerful tool. 

Locking the recipe into orthodoxy would prevent a lot of this magic from happening. Of course, some people will make bad recipes, but some others will come up with an amazing one.

codecentric: 8-16 participants in one room, often meeting for the very first time in person, and all of them with their own subjective views of and biases about the business domain – how do you manage to distill a coherent “big picture” from this initial “chaos”?

Alberto: I’d say it is pure facilitation magic. Nobody wants to be the one that just put sticky notes on the wall, leaving it in a chaotic space, so we can rely on the assumptions that everybody in the room wants to sort out this mess badly.

The more structured answer is “step by step”.

We start from chaos – well, locally consistent clusters of events in an inconsistent whole – then we try to impose some structure. We then realize our initial structure was naive, then we apply something more sophisticated, till we get to an organization which is satisfactory for everybody in the room.

Sorting out the mess together is an act which is between learning and team building. But it also serves the purpose of challenging the status quo: the initial chaos encourages dissonant voices that would not easily surface when starting from a superimposed structure.

The last trick is what I call “Incremental Notation”: I am ready to visualize boundaries, actors, systems, departments and many other constraints. But I start from the simplest possible building blocks, the Events, and then I ask the audience what they would need to see next. This way the workshop tends to stay in the sweet spot of engagement and goes where it can deliver more value.

But you mentioned coherence, and here’s a thing: coherence is not necessarily my goal. Especially in Big Picture, I need to visualize our current state of understanding of the business. If our business is incoherent, I need to visualize reality, not a photoshopped version of it. Hot Spots are my best friends here: all the disagreements are visualized, a few can be resolved, but not all of them.

codecentric: There are other approaches, such as “Domain Storytelling”, which focus primarily on creating empathy between the parties involved. How do you handle the emotional aspect of participants discussing and disagreeing, urgencies and process flows?

Alberto: There are a few ideas that help dissent to be visualized: from providing markers and stickies to everyone so that they can write before agreeing on what to write, to encouraging the use of Hot Spots (especially when trying to converge on a solution).

However, emotions are really context-dependent, and human beings can always surprise you. So a prescriptive recipe on how to handle emotions sounds like a bad idea to me. But as facilitators, we can handle the system: a chaotic round of problems and opportunities will leave everybody the opportunity, and sometimes the anonymity, to visualize dissent without openly challenging the boss.

I do a few things, though. I observe participants, I quietly ask disengaged ones for feedback, I look at body language signals to check if something is wrong. I do a few things consciously, like setting an informal tone with little space for hierarchy and distances, and I suspect there are a few things that I do unconsciously, that make participants feel safe. 

But I have to say that many times showing the whole story did a little miracle: it’s hard to get angry with your coworkers who are clearly doing their best given their constraints. I do open Pandora’s box. But what I get is more reconciliation than fights.

codecentric: Larger businesses often have a unique set of rules and regulations, which can work against the free flow of information between developers and domain experts, and make collaborative workshops difficult. What do you do about company politics? 

Alberto: Personally? Nothing. I just make their impact visible. Usually, I am not called into an organization to start a revolution, and having a solution before understanding the problem isn’t a great strategy for a consultant. I have a radical transparency policy inside my company because I find this approach to be more effective, given our size mission and skills, but it doesn’t mean every organization should adopt the same principles.

So constraints and regulations are in place? Let’s make them visible! Let’s see the impact. Let’s see if our competitors have the same problem, or if they’re exactly under the same constraints. Once the constraints are visible, and they’re diagnosed to be part of the problem, we can play what-if.

In my personal experience, I’ve found a lot of discrepancies between the constraint and its actual implementation. There were simple solutions available that were perfectly compliant to the rule – if the constraint came from a legal background – or to the idea – if the constraint was originated from some corporate rule.

There’s a variety of solutions that can be applied: fuzzy processes can preserve the spirit of a rule without being trapped into rigid mechanics; I’ve found a lot of inspiration in Dave Gray’s ‘The Connected Company’ that provides a good review of different enterprises, policies, and organizations, for example shifting from rules to principles. And I always have Cynefin in the back of my head: complicated processes to handle complexity is not a good fit.

codecentric: To sum it up, what problem does EventStorming solve, and how is that accomplished? When is it useful, and for whom?

Alberto: As I hinted earlier, EventStorming isn’t aimed at one specific problem. It’s a platform, providing recipes that are useful in a wider spectrum of problems.

The most obvious ones are related to cross-silo collaboration, because of lack of visibility, transparency, common language and blame game. Whenever collaboration is needed across boundaries, the combination of event-driven storytelling and visualization can be incredibly useful.

However, more practically, here are a few ways I’ve used EventStorming, from large scale to small scale.

To build a model of an entire business line. In a single workshop, we validated the business narrative and highlighted inconsistencies so that the software teams weren’t bound anymore to contradictory or conflicting requirements. Moreover, we could highlight the natural boundaries for partitioning the system into Bounded Contexts.

To lay down the design of startup. It doesn’t happen often – most startuppers are unaware of the problems in the software architecture space – but we’ve done it with Soisy.it and it turned into a cool success story: we blueprinted the whole event-driven architecture in 18 meters of space and less than 3 days of work.

To retrospective (and re-align) an entire organization. Retrospectives across team boundaries lack the common ground and easily turn into a blame game. EventStorming provides the common ground and supports more informed and educated conversations, not to mention the prioritization of key issues, that becomes embarrassingly obvious.

To design processes which are business-friendly and customer-friendly and tech-friendly too. When many stakeholders are involved, it’s too easy to say “We can’t make everybody happy!” … but that’s not true: we just need a more structured conversation in order to make every stakeholder reasonably happy.

To design Event-Driven and/or Event-Sourced software with very high efficiency. The impedance mismatch between business storytelling and software implementation is minimized (that was the DDD goal from the very beginning). Technical stakeholders including UX and business stakeholders can improve their model together and get quickly to testing and implementing the software: roundtrips between ideas and implementations can get very short with the right infrastructure in place.

codecentric: Thanks a lot for the interview, Alberto!

A shorter, translated (German) version of the interview was published on heise developer .

EventStorming Creator, author of Introducing EventStorming – An act of deliberate collective learning  and Founder of Avanscoperta, Alberto Brandolini is a 360° consultant in the Information Technology field. He’s a frequent speaker in software development related conferences in Italy and across Europe, since rumors spread about his funny attitude. Besides consulting and running Avanscoperta, he’s also a trainer for UK based company Skills Matters where he teaches Domain-Driven Design.