Hi Aman, first of all thank you! For letting me know and also I am glad you found the DDD EU talk useful. I'll try my best to answer your questions!
- To your first question, these days and for the past 2.5 years, I haven't done big picture eventstorming nor do I plan on it. If my goals is to understand, what the user needs are and what services and components does the current system have today to accomplish those and how they work together. It's too chaotic. Requires a lot of folks and a lot of time. And I am not sure I fully believe the value in that. I wrote it about it in a different article and I mention some of my reasons there: https://domainanalysis.io/p/different-ways-to-understanding-the
- I do want to add, If it's a brand new area and my business is trying to experiment, then I think big picture eventstorming might be a great exercise.
- I do love the business process eventstorming. In a message driven architecture, this can be quite useful and gets us closer to the event schema / interprocess communication mechanisms, the compensating actions needed, etc. And yes, I would absolutely invite designers to those discussions as well.
- To me, domain modeling and UX research does go hand in hand. And this is one of the reasons I do love Service Blueprints. I think we can get both from a user perspective what are some of the pain points (from the front stage) and some of the architectural pain points (by looking at the interactions in the backstage). If you don't include that as part of the equation, can you even see that in the eventstorming process. Perhaps the user interface is built in a way to suit the existing legacy application's constraints. For one of the modernization initiatives, I worked very closely with a designer on our team to understand the user and user needs and how it is implemented today and then by talking to various people at different points built a service blueprint of that user need. Which we then used in a larger meeting with all of the stakeholders from all of the teams involved in that user journey, verified each step to make sure what is depicted is indeed right and then we had a design workshop to identify ways to make the experience better.
From a systems thinking perspective, which I also need to write about :), you can imagine the current system as something made up of several essential parts. And the most important thing is that the system is not a sum of its parts but how all of these different parts interact with each other to fulfill a user need or perform a function. If you are able to in the vast ocean of the current legacy system, drill down to your most important users and the most important needs for which your system exists, then you can map out how these work together, then its a matter of tackling , prioritizing what you want to handle, what parts you want to change and then deal with the how.
You can think of the designers as the advocates for your users. The reason why the current system exists today. If you exclude these folks, who is representing them at the table while you make important decisions? As techies, it is quite easy to focus, zoom in on all of the architectural things, platform things that needs love and easy to forget the user. Having the designers in the meeting can help you also bring this to focus and then you can put all of the things in the table to make the best tradeoff for your modernization journey. I hope this helps!
I would love to understand how big picture eventstorming helped you in your current state analysis and how did you structure your workshop? Did you have an all day workshop or multiple workshops? I'd love to know more.
Thank you for responding. I will first answer all your questions in one go because they are all related, and then I have a couple more for you 🙂:
- Using and structuring big picture event storming for current state analysis: Mind you, we (an e-commerce/retail company) are organised into business specific domains so a big picture for me often is scoped to only the domains that are affected by or participate in the process in some way or another. So I am not big picturing the whole org. I invite some developers, not many, I find us devs can easily derail the conversations into the deeply technical too quickly or worse, influence/intimidate the business participants a bit. True story and lesson learned!
To that end, I mostly focus my workshops on understanding all the critical events that transpire in a given business process today and systems/components in use, identifying actors and hot spots along the way, making notes for how long some steps might take etc.
Time is often a resource we are always short on, I always try to plan at least 3-4 hours for a big picture session, occassionally I have done all day workshops as well but those are rare, most often though the most people can part with are 2-3 hours. The very first session I will always aim to do in a physical office location with ample wall space so we can get to know each other a bit and have a high bandwidth communication, later sessions (if needed) I then take over to Miro and do online. Depending on how many hot spots we have on the storm to address and the complexity of the process, we might plan additional sessions online and these tend to be no longer than 1 or 2 hours max. I aim to get all the hotspots addressed so we can build a more complete mental model of the as-is flow.
Towards the end of the session I also always try to shepherd the participants towards voting for the biggest pain points and the one with most votes gives us our starting point for deeper dive towards solving and optimising (this is where I would use the process level event storming and complete the colour grammar of just this part). I have invited UX designers to these sessions before, sometimes they find it useful other times, they say, "it all sounds very technical", "chaotic", though that's may be my failure as a facilitator to not have kept people focussed on the business problem at times.
I have usually had a positive feedback from the participants, business experts felt they were listened to and devs felt they had a deeper understanding of the domain as a result and are able to create a solution that is more sympathetic to the business needs. I admit we don't always visualise the experience of the user, though we think about it, during these event storms. May be because I am not yet an accomplished event stormer so I am missing a trick or two. Hope all that answers your questions.
My follow up question to you (this question might have more connected questions):
How do you bridge from service blueprints to software system design?
To clarify, let's say I have done a fantastic Service Blueprint session (or two) with UX designers and relevant stakeholders, we now have a good understanding of the journey end to end and front to back. And let's say we have chosen to build software to ease the pain point and improve the UX, at the end of the day I still need to think about bounded contexts, language, consistency boundaries, invariants etc and model them in code. With event storming visualising the pivotal events, focussing on language and stakeholders etc, we can start to create a draft of the boundaries and start to bridge over to a richer view of the system to be built. How would you do that with Service Blueprints alone?
Once again, I really appreciate you taking time to help me out.
Hi Indu, a very refreshing perspective in your article and I also found the DDD EU conference
talk you co-presented with Olivia, quite insightful and walked away with some questions as well. I
am in somewhat of a similar situation at the moment in my org where we want to replace a
legacy system with a modern one, I have conducted big picture event storming sessions with
domain experts and stakeholders (they also happen to be the primary users of the system) to
understand the as-is process and pain points.
Then our designers reached out to me to understand how I am addressing users' needs and
pain points without potentially introducing biases (which according to them can happen in event
storming sessions since its a big chaotic session). I think they have a valid point and I haven't
really thought about it from that pov, biases and conflicts are good from an ES perspective
because I can visualise and address those. At this point we are looking at ways to collaborate
better without making it a methodology battle where we fight for our users'/experts precious time
and energy, to build something useful.
My questions for you?
- Given your experience with Service Blueprints, would you still do big picture event storming
and why?
- For other flavours of event storming (process and design levels) would you recommend
involving UX designers as well?
- I am also wondering if domain modeling and UX research can go hand in hand, i.e. UX
designer, domain experts/users and engineers under one roof in a tight question ->
response/idea -> code modeling loop so that domain model, to the extent possible, takes into
account or atleast is sympathetic to UX needs without being too influenced by it.
Apologies for a long list of questions and thanks for sharing your insights.
Hi Aman, first of all thank you! For letting me know and also I am glad you found the DDD EU talk useful. I'll try my best to answer your questions!
- To your first question, these days and for the past 2.5 years, I haven't done big picture eventstorming nor do I plan on it. If my goals is to understand, what the user needs are and what services and components does the current system have today to accomplish those and how they work together. It's too chaotic. Requires a lot of folks and a lot of time. And I am not sure I fully believe the value in that. I wrote it about it in a different article and I mention some of my reasons there: https://domainanalysis.io/p/different-ways-to-understanding-the
- I do want to add, If it's a brand new area and my business is trying to experiment, then I think big picture eventstorming might be a great exercise.
- I do love the business process eventstorming. In a message driven architecture, this can be quite useful and gets us closer to the event schema / interprocess communication mechanisms, the compensating actions needed, etc. And yes, I would absolutely invite designers to those discussions as well.
- To me, domain modeling and UX research does go hand in hand. And this is one of the reasons I do love Service Blueprints. I think we can get both from a user perspective what are some of the pain points (from the front stage) and some of the architectural pain points (by looking at the interactions in the backstage). If you don't include that as part of the equation, can you even see that in the eventstorming process. Perhaps the user interface is built in a way to suit the existing legacy application's constraints. For one of the modernization initiatives, I worked very closely with a designer on our team to understand the user and user needs and how it is implemented today and then by talking to various people at different points built a service blueprint of that user need. Which we then used in a larger meeting with all of the stakeholders from all of the teams involved in that user journey, verified each step to make sure what is depicted is indeed right and then we had a design workshop to identify ways to make the experience better.
From a systems thinking perspective, which I also need to write about :), you can imagine the current system as something made up of several essential parts. And the most important thing is that the system is not a sum of its parts but how all of these different parts interact with each other to fulfill a user need or perform a function. If you are able to in the vast ocean of the current legacy system, drill down to your most important users and the most important needs for which your system exists, then you can map out how these work together, then its a matter of tackling , prioritizing what you want to handle, what parts you want to change and then deal with the how.
You can think of the designers as the advocates for your users. The reason why the current system exists today. If you exclude these folks, who is representing them at the table while you make important decisions? As techies, it is quite easy to focus, zoom in on all of the architectural things, platform things that needs love and easy to forget the user. Having the designers in the meeting can help you also bring this to focus and then you can put all of the things in the table to make the best tradeoff for your modernization journey. I hope this helps!
I would love to understand how big picture eventstorming helped you in your current state analysis and how did you structure your workshop? Did you have an all day workshop or multiple workshops? I'd love to know more.
Thank you for responding. I will first answer all your questions in one go because they are all related, and then I have a couple more for you 🙂:
- Using and structuring big picture event storming for current state analysis: Mind you, we (an e-commerce/retail company) are organised into business specific domains so a big picture for me often is scoped to only the domains that are affected by or participate in the process in some way or another. So I am not big picturing the whole org. I invite some developers, not many, I find us devs can easily derail the conversations into the deeply technical too quickly or worse, influence/intimidate the business participants a bit. True story and lesson learned!
To that end, I mostly focus my workshops on understanding all the critical events that transpire in a given business process today and systems/components in use, identifying actors and hot spots along the way, making notes for how long some steps might take etc.
Time is often a resource we are always short on, I always try to plan at least 3-4 hours for a big picture session, occassionally I have done all day workshops as well but those are rare, most often though the most people can part with are 2-3 hours. The very first session I will always aim to do in a physical office location with ample wall space so we can get to know each other a bit and have a high bandwidth communication, later sessions (if needed) I then take over to Miro and do online. Depending on how many hot spots we have on the storm to address and the complexity of the process, we might plan additional sessions online and these tend to be no longer than 1 or 2 hours max. I aim to get all the hotspots addressed so we can build a more complete mental model of the as-is flow.
Towards the end of the session I also always try to shepherd the participants towards voting for the biggest pain points and the one with most votes gives us our starting point for deeper dive towards solving and optimising (this is where I would use the process level event storming and complete the colour grammar of just this part). I have invited UX designers to these sessions before, sometimes they find it useful other times, they say, "it all sounds very technical", "chaotic", though that's may be my failure as a facilitator to not have kept people focussed on the business problem at times.
I have usually had a positive feedback from the participants, business experts felt they were listened to and devs felt they had a deeper understanding of the domain as a result and are able to create a solution that is more sympathetic to the business needs. I admit we don't always visualise the experience of the user, though we think about it, during these event storms. May be because I am not yet an accomplished event stormer so I am missing a trick or two. Hope all that answers your questions.
My follow up question to you (this question might have more connected questions):
How do you bridge from service blueprints to software system design?
To clarify, let's say I have done a fantastic Service Blueprint session (or two) with UX designers and relevant stakeholders, we now have a good understanding of the journey end to end and front to back. And let's say we have chosen to build software to ease the pain point and improve the UX, at the end of the day I still need to think about bounded contexts, language, consistency boundaries, invariants etc and model them in code. With event storming visualising the pivotal events, focussing on language and stakeholders etc, we can start to create a draft of the boundaries and start to bridge over to a richer view of the system to be built. How would you do that with Service Blueprints alone?
Once again, I really appreciate you taking time to help me out.