Profile cover photo
Profile photo
Alberto Brandolini

Post has attachment
Interesting discussion this morning, started by Thomas Perrain. ...I guess some of you have similar experiences...

Had fun in the last three days of educational workshop, playing with a different domain.

Instead of something we had a real expert in the room, we've chosen to run the workshop on something we had real customer experience: the Italian railways company.

I've chosen that, because everybody acknowledges that it's a complex domain. Yet we managed to model a lot of it. Or at least to have an emergent structure and vision of the next step.

It's been actually fun, because we ended up with quite a few proposal for improvement that turned out easy on top of an Event-Driven architecture.

Food for thoughts.


Had an interesting conversation yesterday with +Paul Rayner about ...well almost everything! :-) However, one of the interesting bits was about strategies to wrap up the design artifact.

Looks like there are so many different ways to deal with that, and I am nowhere close to a definitive answer. So I'd like to hear your opinions/ideas about that.

Different context yesterday: more a product exploration than a business driven one.

The interesting bits were related to the fact that we were discovering designing not the perfect match for one specific organisation, but a more generic market fit.

Probably the most interesting one is that being right doesn't necessarily pay off: if the underlying problem is complex, but your users haven't realised it yet, they might be more inclined to buy something apparently simpler, matching their own mental model rather than something complex, that looks like "too much stuff I'll neve need". The real challenge became wrapping complexity with simplicity or presenting something with sophisticated internal machinery like a relatively trivial tool from the outside.

Other key point was: we have no guarantee that the customer's bottleneck is within scope. Our product might serve a support flow, and not the most critical one, or it might map with multiple bottlenecks in the company.

One of the approaches that seemed interesting was to try to solve at least one problem for a given category of users in a distinctive way, in order to hit the potential decision maker. Or consciously decide to focus primarily on some users, and limit ourselves to the basic homework in ancillary portions of the flow.


Some days ago I've tried EventStorming in an unusual context.

Most of the attendance was business, including some C level in a complex business. There's been some fuss around the meeting so a few more people joined and we ended up having 25 people in the rom focusing mostly on the sales process.

The operations itself was big enough to call for another 2 meetings entirely.

I wasn't given the room I wanted, and the lack of space kicked back in, since people had a hard time sorting all of the events, due to the lack of free space to shuffle things around.

In order to get out of the rabbit hole of sorting the whole story, we ended up using a smaller space as an area to sort "chapters" instead and sort a smaller version of the overall picture. Chapters were more or less the subdomains in DDD lingo.

This solved the impasse, because we now had an idea of the expected shape of the overall flow, but also created a lot of weird commentaries like "oh this should belong there" "No this should belong there!" if categorisation and boxing was the real problem.

However, this was also the first time I'd have traded Events for something more coarse grained, since space limitation made managing all the huge event quantity hard to manage, and ended up postponing some interesting conversations.

- Room requirement are strict: half of the dysfunctional behaviour were in fact dependent on room size and to the Big Table in the center antipattern. Afternoon was kinda dysfunctional.
- Space matters: without slack space, shuffling things around becomes a lot harder.
- When business becomes really complex, a zoomed version of the overall flow could help envision the global shape.


Post has attachment
Add a comment...

Hi All,

I finally started writing again after some weeks of silence. I am sorry for the pause (and personally annoyed too) but I'll be back to work. I just realised I am in my forties...

Thank you for your patience and support.


Just run an edu workshop with an unconventional audience. A few people had a UX and Service Design background.

Talking about external systems, it was interesting to note that some were looking for precision: "is it a software system, or a Touch Point?" while I clarified that I had no interest in the precision of the notation. Or even more: "precision is considered harmful". At the initial stage, there's little advantage in a clean separation between systems and something more fluffy like "external community" (a key external entity in our domain).

What really matters is that "they're external" and "they're at the boundaries of our exploration space" and "there might be some risk associated with them".

Talking again about the UX/Service Design perspective, the feedback I had was "we focus on the customer journey while ES digs around the feasibility of the underlying processes" providing a complementary perspective.

Post has attachment
You probably already know... but I decided to open the gates and make the Work in progress book available on LeanPub.

Still a lot of work to do, but it may already be of some help for somebody.

Every feedback is Welcome.



Post has attachment
Back from a blasting #DDDEU. I've seen people modelling everywhere... EventStorming heaven!

There would be tons of things to say, for now... I uploaded my presentation slides:

... more will follow soon! :o)

The precision blade
The precision blade
Wait while more posts are being loaded