EventStorming: From big picture to software design - Cédric Pontet

so let's get started even though the abstract of the talk was written in French because there are non french-speaking people in the room I will do the talk in English I hope it's okay for everybody so the title of the talk is even storming a superhero story so hint it will speak about superheroes of course but it will also speak about even storming at the beginning was the verb at the past tense I don't put the Bible very often but this is the even storming Bible you will learn everything about events domain events and how to build a mapping of complex domains through even storming I'm Cedric Pantera I'm the CTO of agile partner a company where we do software development and also agile coaching so I hold two to two hats I'm a software architect cloud architect and also an agile coach I also co-founded play 14 which is a playful event we are all around the world now and we spent basically two and a half days playing with a lot of things you we use play as a metaphor for learning basically and I am also an event storm you see the guy in the middle of the picture with a beard his name is Alberto Brandolini he is one of the thought leaders of domain-driven design and he's created this thing called even storming to try to improve the way we bring domain-driven design in companies but now even storming has become bigger than that and you can reuse it for many many different cases and I will speak about that during the talk so what is even storming even storming is a workshop format it's a discovery tool it's foreign for most communication tool alignment tool and it's a massive learning opportunity how does it work we'll describe that in a moment basically if you have a complex domain a complex business domain I'm pretty sure that all of you work in this kind of domains like for example banking insurance industry whatever is your your your job there must be probably a complex domain that you need to explore you need to understand that a lot of rules and a lot of things that are unclear so we can represent that through a series of events organized on the timeline that's the basic idea of even storming but of course they're also the name of storming which means that there will be some communication collaboration going on along the way Alberto realized that there were basic three level of abstraction that you could even storm the big picture to understand a big mess basically process modeling if you have a business process you can model it through even storming and software design you can go down and really drill through and go until you reach a point where your domain events and other artifacts will be transformed into code if you code in domain driven design way of and probably even sourcing as well but you don't really need to do that to use even storming even storming is actually a workshop so even though you don't do DDD and you don't really do even sourcing you can still use even storming the idea is instead of using structural modeling which is basically what we do in most cases saving classes into tables solving saving things at the current state in this case we use temporal modeling we are more interested in to what's going on what changes and what are the interactions between different actors that's why we use mainly something like even storming but now enough big words I'm going to tell you a story so imagine that you you are superior now and your superpower is even storming your master branded Nissan is wise and revered and he has taught you everything you need to know about even storming you are mastering this art now and you always carry around stickers and sharpies you know how to write on them you know that you should always write in capital letters you also have a large paper roll that you carry with you and you have your tape and you can even storm anywhere you want and one day you are called upon by the Avengers because they have a problem they need your help they want to create a universal ecommerce system and when we say Universal it's the scale at the universe where they can sell everything the gears their swag all this stuff so imagine Amazon but universe wise right this is a tough problem and even though the Avengers are great team they have a lot of responsibilities that are shared by skills and abilities they also called upon some consultants what not reached this kind of consultants but we'll see the problem is that within the Avengers and this great team the knowledge is distributed and it should remind you something about your own context income in large companies for example so we have Steve Rogers who is in charge of product strategy he's kind of the leader so he has charisma yes he's inspiring he's in charge of the product strategy because of that now we have also thought who is in charge of sales and marketing he's kind of persuasive and has a great negotiation skills so and also a great address book like he knows people that's useful for salespeople he assisted for communication and community management by Peter Parker that guy knows how to take pictures for example so it's quite handy when you speak about community management Natasha Romanov takes care of customer acquisition and growth hacking she's well she know how people she knows how people think and she can get access to any kind of information so that's quite useful she's working with Wanda Maximoff who is a user experience expert she's great at reading people and so she helps for that Clint Barton is taking of inventory and logistics he is good at things that move around and targeting them and following all these dis moving targets at the same time so he's working with Carol Danvers and she and Steven strange for shipping creating a portal to ship something at the other side of the universe is no problem for dr. strange and well Carol Danvers can can handle the heavy lifting so it's useful Bruce Banner could with number his smashing numbers so he's taking off finances and believe me all the customers paid at that big duel because they don't want to handle the other guy so it's quite handy Tony Stark of course is tech savvy so he's taking care of all the technology and operations part and he is at by nebula who is taking of infrastructure and architecture because she knows how to create self-healing systems and systems that work at scale and last but not least rocket racoon is the customer spot he is kind of good at haggling and is not really easily fooled so he will be taking care of customer support but the thing is there are some kind of silos in this kind of organization they don't always speak to each other very well they are all taking care of their own responsibilities but sometimes they are caught up by the day to day work and when it comes to creating this universal ecommerce system they don't really see the big picture it's a probably the hardest problem that have they've had to solved even harder than killing that guy but don't worry this talk is for free I will not reveal anything about the last model movie so the problem is they're lacking vision and the pun is intended it's difficult to make sense of this big thing there are a lot of things to take care of and that's why they call upon you they need to create a platform that is easy to use and easy to use when it comes to human beings it's already quite difficult but when it comes to aliens it's even harder they need to also handle something that is kind of ubiquitous like people every kind of culture and languages and currencies that I use need to be handled they also need something that will scale I mean if you have some kind of sport at the other side of this thought even that the other side of the universe and they want to buy some gear or whatever they need to cope with that scale so it's pretty difficult complexity this is a complex problem there are a lot of factors there are a lot of things to pay attention to and that's where the big picture even storming is useful so you remember your master who tells you that big picture even storming you should use it to make sense of a complex domain and see it as a whole it will provide you global overview across corporate silos that's the most important you will crud cross the barriers of corporations and it will trigger long overdue conversation most people in large corporation they don't speak to each other anymore so you arrive at the Avenger facility in your own Quinjet that's cool and you spot a room that you empty completely from all tables and chairs why because you want people to be focused to be engaged in the meeting not to sit down lazily and waited for her for weight that it happens they should be really collaborating and on the left there you spot this nice wall empty wall and you start taping your pepero roll on it the paper will be your unlimited modeling space why you want this to be a big space because you don't want people to limit themselves by physical boundaries the bigger the paper world is the bigger they will are the easier it will get for people to explore and not forget any part of the domain of the complex domain and if it gets too small just add some more you have other walls in the rules so in the room so you can actually add some more and then you have your secret treatment its delve there if you want to take a look you have all your post-its and your markers and all the gear that you need to actually run an even storming and last but not least you prepare a visible legend that's very important it will be incrementally populated along the way and it's going to be the reference for your or your session you need to invite the right people if you have different silos in the organization you should have people from at least one person from each side oh so you can get the big picture if you don't have that you might just skip part of the knowledge it's a big problem so your master Alberto says invite the right people and those right people are people with questions usually it's IT people technical people architects change agents DevOps people and people with answers these are decision makers business experts domain experts and business analysts sometimes these peoples are people are already in the organization but they don't talk to each other before you begin you ask Steve Rogers to give a bit of context why are we here today what do we want to achieve what's the overall goal in terms of strategy not in terms of software but in terms in terms of what will this thing bring to the organization what do we want to achieve here and then you remind people that the goal is to see the big picture so you should not leave anything unturned you should really go deep into knowledge and you remind people about some very basic rules one person one marker important everybody should be able to participate so it's very important that you provide these things for people one concept per sticky you don't want to have a book written down in one single sticky because you want this to be visible that's why also you recommend people to write in capital letters once more you need to enforce the timeline the whole idea is to actually have domain events along the timeline so this timeline is important the notion of what happens after what or before what is very important and of course you should make all the rules explicit then you start with explaining what the domain event actually is a domain event is something that occurred in time it's represented by verb at past tense and it should be relevant for domain experts you write down the first domain event in this case an item has been added to cut so item added to cut is your first domain event it's the easy one and you stick it on your modeling space around one third of the mandelic space is a good idea why because you want to leave space before so that in case something before should happen you have space and you want to give space after so the idea is to really explore and then you tell people okay now you know the rules everybody has stick is everybody has markers orange stickies by the way it's very important color coding and then everybody should start writing down some events so we start with item removed from card that's the parallel of the other and then we have shopping carts was checked out and then the delivery address was provided but then okay wait we are missing something here we are missing some to speak about the money and you remember your master tell you money is something you should really look at basically most companies want to make money right so follow the money it will trigger interesting discussions so you start with the group you start to explore the money thing so payment method was provided delivery price was calculated total price was updated and cut price was calculated before that and the car checked out was requested and then you can reprioritize you've seen that you need to move post-its around that's the cool thing with post-its that you can move them around so you can really enforce your timeline by really reprioritizing things in time and there you go yet another conversation emerged from from this this workshop we've always tend to follow the happy path because we are built like that we are optimistic most of the time so we also need to explore what when things go wrong grow wrong so the cart can be reset and the payment method could be invalid wrong credit card or something so it's important to follow that and then some questions arise yeah what about discounts and vouchers and things like that do we want to do that now it's gonna be very complex we don't really have a strategy for that maybe we can it would be interested Biswas business-wise but maybe you want to leave that for later on and then a new notation appears it's called hot spot and you will track all the questions all the things that you the decisions that you probably want to delay because you don't have the ability to answer that question right now you should track that on hot spot so you put it on the board and you date your living legend with a hot spot so a hot spot is a pain point a bottleneck a question that will lead answer because you probably don't have the right people in the room to answer that right now something to clarify later and then you go back to your events and the last events from that sequence is order is placed but what happens after that well you should validate your address you need to know where to send the products and of course because we take off not-so-happy pass we also have sometimes addresses that are invalid but wait how do you know your address is valid you need some kind of thing that you can call to validate your address and luckily dr. strange News the my universe repository it's a global address repository where you can really check that the address is valid cool so you will actually call that and that's yet another notation it's called an external system so the my universe universal address system and you increment your notation a system an external system is a system that is maintained by either another team in the organization or another organization so it's out of your control basically you will need to interact with that system to integrate with the city with that system somehow and you go on so you're after your authorized is placed and your address is validated you will have the order that is priced including the taxis then you need a payment method again another external system you probably don't want to implement your payment system yourself so you have the payment taking care of but now how do we know that the products are actually available do we need to take care of that what happens if the product is as been ordered and paid for and it's not available well we need to ask the user what he wants to do if he wants to have the product shipped later or if they want to actually be refunded from the product for the product so you will have to in task your inventory system about that so your product is either reserved or it's not available and it's a legacy problem so you don't have clean nice REST API - who call that system you will need to integrate with that this is another topic don't lose too much time speaking about that the idea is that the this conversation flow so you need to write down a hot spot and leave this problem for later on this is the whole idea of a spot not get stuck in a long conversation that will basically not provide any answers so you will need to work that around that and that's it and then we continue so you need to notify your user then the user has to take a decision do I want the product to be refunded or do I want the product to be shipped later and you introduce the notion of customer it's an actor in your system so you increment your notation a user or an actor is someone who interacts with the system and takes decisions and this is very important and you continue so you need to request the product bishop later if the decision was to ship later or to refund the product and so forth and so on and this is scheduled and you need to after that prepare the order you need to pack it you need to update the inventory system and you need to declare that the order has been prepared so that it can be shipped and for the shipping you want to also track the the product you need to be able to tell your customers where the product is or the products are and if everything is fine you need to alert them so send them notifications and in the end the order should be received and that's the end of your flu except you forgot about accounting this is something that is useful in most companies it's a pain in the ass usually but you need to update that so you will also track everything in the accounting system so transaction accounted for invoice prepared invoiced was the document was generated by the document system and then it's sent to the user dollar customer in that case but wait what happens if the order is canceled well usually people want to be refunded so you will have to take all these compensation ting actions that will need to take to happen so that everything is reversed so the order is refunded that means that the accounting is updated you have some counter thing to do your project product is expected to be returned and then the product is returned and the order is finally consult of the process is finished so at that moment it's basically good time to make a break and after the break you use storytelling to check if everything is right and that you haven't forgotten important things so you can actually use storytelling to tell different business narratives in that case you have two main narrative the order is successful the order is canceled there might be some more of course it's just an example so I I don't want to you to to really this domain is much more complicated than that but I don't want to spend too much time exploring the domain the idea is to explain what even storming is once you have your domain mapped out you can actually group domain events into sub domain boundaries you see some groups clusters of event emerging and you can regroup them the whole idea of subdomains is that they can be then represented in domain driven design by bounded context a bounded context is basically something that creates a current encapsulated whole of different concept that belong together so it helps you resonate about your big system into smaller parts and usually a subdomain and bounded context that is encapsulating a subdomain it has one single responsibility and you can have these nice events higher-level events with a higher level of abstraction that flow between these bounded contexts to synchronize them so in our case you have the shopping subdomain you have the payment subdomain you have the accounting the shipping the tracking and all these subdomains they probably need to either be coded by your team or you need to integrate with an external system and unwrap this integration nicely so big picture event storming Rick's rich discussions and interactions everyone should be engaged you have the right people in the room you can go up to 2025 people if you have a room big enough it should be very rich a lot of different people could work at different spots on the map because they know that part better then they will focus on that part and the different point of views are important to explore because most of the time not one single person as the whole truth most of the time they see part of the same problem in different angles so it's important to trigger these conversations you should always be focused on the business and you start building a shared language that's very important in terms of domain driven design this this notion of ubiquitous language the language is ubiquitous in in a given context of course but still it's a ubiquitous language for the company for the organization you start explaining a bit better what customer is what what an order is and this kind of business notion that you are using also it helps visualizing things we human beings like visualization it helps us resonate about things you have this incremental notation so you always start with the domain events the most important things because it helps you really build the timeline and it's normal that it's fuzzy it's fuzzy by design it should be a big mess according to Alberto because out of these cows some nice things will emerge and it's good that this conversation are taking place most of the time it's a very bad thing that people try to hide under the mat so good thing that conversation happen and you are exploring together you are building a shared vision and you keep uncertainty in check especially using odd spots you should always track things if a conversation is happening and it's going nowhere because you can't take that decision write that down on a hot spot and leave it for later and try to find the people who can help you solve that problem so the whole idea is to reach clarity about your big picture so times goes on and at some point rocket just says hey guys you put me in charge of customer support but I have no idea what the process for product written should look like so you need to map that as well so you will go bit deeper and not using the big picture anymore because you have different levels of abstraction that you can map as I mentioned in the beginning of the talk so here process modeling even storming can be used to make to map an epoch or set of features in that case it would be the product return and you are turbit the way you represent your your modeling so phase by by having some preconditions outcomes and the flow to discover is in the middle so the end goal is to have a product that is returned so you have the main events project written and then you have something that is the request a customer has requested a product return so it's a new notation it's called a command it's an order that is given by the user a decision that is taken by the user and it will be annulled by the software it could be also that to trigger a command is triggered by the system itself sending one part of the system would send a command to another part of the system it's always written down on posted with an empowered imperative verb it's an order it's it's it's something that you instruct the system to do and who gives that who takes that decision the customer of course but he needs some information to take that decision he probably needs other details the product description and the product price it's that product that he wants to return not the other one that that was part of that order so he needs that information to take that decision this is called this is called the red model it's something that is a decision-making tool it's not only data it's something that provides consolidated consolidated information in order to take a decision and it's displayed to the user or to the actor all that needs to take that decision and then you have the Avenger customer service system that will generate the main event called product Twitter and request it this will need to be handled by something and this something is called a policy something that will react to an event so fall so so far we have a command and domain event and we can have a command that is sent to an external system and generates the domain event but we have also policy policies will react to a given event the idea is whenever event then command okay so it gives you the ability as your master explained to you to have this nice flow of things so you have a rid model that is basically making an actor aware of things this actor takes a decision that basically lead to a command that is sent to an external system the external system will generate a domain event the domain event will be handled by a policy that will react to that even the policy is either automated or maybe a user another actor should take a decision on that and act on this policy and it triggers another command that will then be sent to another external system and so forth and so on so you can change things like that it's a color puzzle so in that case maybe the customer service ID agent will need to take the decision do we allow the project returned or not if some person just order on your platform and they keep on returning products you might want to tell them a guy's maybe you should order less and be sure about what you're ordering or if someone has ordered just written product like six months ago it's perfectly fine if they return a product now so this decision needs to be taken and then it will lead to another policy that will take off the of tracking the product return and compensating the action for the the accounting system and so forth and so on then the tracking policy will take off in updating the legacy system the the inventory system and in the end we will go back to the customer service system to say everything is ok now the product has been returned everything is fine so you are modeling a process now not the big picture anymore you go a bit deeper and it's more granular sisters seeing that you want to this is the part where people start forgetting things or lying because it's more like we are in charge of that process and most of the time they don't really want to show things too sometimes the management or whatever so you need to really pay attention to that that nobody is hiding some information because ambiguity does not compile that's what Alberto says you need to be clear about things you need to make everything as explicit as possible and you need to challenge the value you need to really try to take the chance to also discover inconsistencies and maybe new opportunities because having this discussion happening during that that modelling it gives you maybe the opportunity to offer new ways of doing things new services new business advantage that that you can take the overall idea is to reach agreement between people and so consensus so even later again rocket racoon comes to you and say this manual policy is really a pain in his ass because it's manual and of course it's a lot of work so at that point you probably want to maybe try to automate that and there are some rules that you should make explicit why can you automate what can you not automate because your system is a bit clearer and fun and now since thanks to the big picture and process modeling thing you are a bit deeper now and you can really represent things as software artifacts that's where software design even storming comes to place so the whole idea here is to have a set of software effects that are represented by these corrupt post-it and that will be in of enforcing the domain logic and the business consistency these things are called aggregate this is really something that you will code like it will be transformed into classes in object-oriented programming of functions in a functional programming and it will be in charge of what of really making sure that these this business logic is well represented but it's usually when businesspeople when they participate is kind of session they are getting a bit scared because the word aggregate which comes basic by the way from the domain driven design field it scares people for some reason but it's not so complicated to understand actually so an aggregate it's an yet a new notation it's basically a state machine logic it's something with a lifecycle take another for example another has a beginning and an end and in between different states but it needs to go through to be to be processed so we focus on behavior here not on data that's the whole the idea of oriented object-oriented programming basically that you always should focus on behavior and the aggregate and forces business consistency all the business rules should be enforced by that aggregate so the software design with aggregate is something that is difficult it really needs to be done by some people who know how to design software but also people who have the knowledge about the business because there are some rules to explain to make explicit so just imagine that you have requests for a project return that is a command this command is handled by this agreed called product return request and it will trigger something called product return requested it's an event this event will be reacted to by a policy called project return policy that will ask our give send a command to say okay we need to authorize that project return remember that the ally at the idea is to automate this this process it will this command will be handled by something another aggregate called customer history and this aggregate can take decision because it says responsibility its responsibility to take this decision because it implements the business logic so the product could be authorized the project return could be authorized it will be an event that will be reacted to by yet again this project return policy send a command accept product return to the product return request that will generate another event product return refund accepted and then the policy will again react and say ok refund product and then it will send this and this this comment will be sent to your payment system to refund the product that's the easy nice happy pass but then you can have the pass where the refund is not authorized so the policy will send a command saying ok refuse product return the aggregate will say product Griffin was refused and then you have the case and basically if the if it refused nothing else happens and then you have the case where the manual approval is required so the policy will send a command saying ok submit project return to approval the aggregate will trigger will generate an event that is pretty quick refund submitted to approval and at that point you need your agent from your customer support to do something so you need this list of product written previously to take the decision if you accept or not the return and in that case yeah the the actor will decide accept or not so you see that you have this kind of state machine that takes place and this is basically what you will encapsulate into the customer service bounded context the old idea is to actually this is what we call the policy is actually what is called also process manager it's a pattern messaging pattern and the Heidi is to have aggregates that will send even that will be reacted to by process manager that will really not take care of the business logic per se but more the orchestration of the different parts that take decision so this process manager just say if this then that if even then command and you can riri orchestrate things by just changing that piece of process manager that is just orchestrating if you change the process manager you don't need to change anything about the aggregate the aggregates which enforce the business rules they will stay the same but the orchestration might might change so it's a very flexible way to design software again you reach this knowledge through software design even storming it's a good time when you do this to rewrite your domain events because this will be code and if you say that you have given that is named that and you put that in production changing that name afterwards will be a pain it will be really painful so you need to pay attention to that so Alberto says use pedantic semantics precision really try to make the decision the final decision how do we call that domain event how do we call this thing you've seen that you had symmetries usually what you have in a system like that is you have a command that is generating an event and this symmetry is very important the same kind of command event pattern all the time but sometimes it does not and it's also important to track that again challenging things is a good idea you there is not one single domain model that you can create sometimes domain model makes sense at the beginning of your project and it may be you learn a bit more in the process and at some point you want to change that model you probably want to throw the other model the previous model away and and create a new one the good thing about domain even it's give you the ability to do this kind of changes without breaking everything because everything is really nicely encapsulated in two pieces of software that have of single responsibilities so throwing the wrong thing the way is a good thing but for that you need to make sure that you don't fall in your love with your intuition so challenge yourself and try to think outside the box heart problems don't have obvious solutions and the best thing you can do when you do a software design even storming is to have a product owner to ask questions to because these people they know the business and you need them even though it's a more technical even storming you need the business knowledge the override is consistency so word of advice if you are an even stormer and you want to run these sessions and you want to improve your superpowers and put them on steroids come prepared you should know your context you should know what you're trying to achieve as a facilitator before you start the session clarify the objective with the sponsor or the business owner in the before the event before the the workshop and maybe ask them to give it some context as I said you can start with an icebreaker with a fun activity I mentioned I was one of the founders of play 14 we do a lot of ice breaking games things like that just too so that people just get rid of their day to day thing and start to be in more collaborative mindset don't push your own assumptions as a facilitator your role is not to be a consultant it's to be a facilitator so you should not tell people your business is like that they know that their business they are the ones who are coming up with the rules and these things it's not your job your job is to make that emerge and the best way to make that emerge is to ask a lot of questions and well you when you're done with asking questions ask more questions again and again by the way there are a lot of tools that you can use that teach you how to to ask questions that are clean questions not not pushing your assumptions in your questions and so you should always work in improving your facilitation skills I'm preparing another talk on that subject and at some point maybe I will do it here and you can actually also mix even storming with other tools like story mapping impact mapping whatever other tools that you've used in the past you can really mix them together and it's a very very good thing there are a lot of different flavors you could map with even storming as is system or to be or you could use it for exploration that's the first intent but you could also use it for explanation you have a newcomer on your team you want them to understand the big picture process what you do as a company just do an event storming with with that person and they will get this vision in in like two hours you can map the whole thing it's a very good way to explain things because it's very visual single floor even storming from Adam dimetric is something that exists I will not go into details like that basically the idea of battle is that even storming is pizza can put your topping on it as much as you want and there is a Niven storming recipe book that is coming soon I will be writing probably in this book the my personal recipe which is using even storming for gathering together feedback this is what we've done at play 14 and I reused the the format with different meaning like we had the events what happened during the conference or the end conference the pink ones were what the moment what's just happened the green ones were takeaways and the yellow ones were improvements that we could make and it gives you a lot of information you could even use that to remap the whole Marvel Cinematic Universe you could try that that's a fun activity if you want to learn more you have the official website you have a limp a book that is not finished don't ask Albert about that he is making him a bit angry you have a github repository from Mario skill who is one of the even stormer and you have the blogs and stuff like that thank you very much we have two minutes for questions yep I expected that question so what Alberto says is that the end result is actually not the overall goal of even storming it's the discussions that are happening so usually what you can do is to take this large piece of paper and and just take it somewhere if you really want to you can you can use like online whiteboards and stuff like that to document the it's probably something that you you should be able to do again in in a much smaller time if you want to do it again so and actually redoing an even storming on the same subject gives you more insight so the the the the result the end result is not really the the post-its themselves it's the conversation that takes place but yeah documenting is a pain in the ass most of the time it's taking pictures and storing them in some kind of wiki that's good enough sometimes it's basically a brainstorming approach but there is a structure of it like the main event first gives you a bit of structure then you add the the hotspots to avoid long conversation that are quite sterile and and doesn't don't really provide any value then you have this notion of command and all this kind of stuff so it gives you a bit of structure in your brainstorming but the term storming comes actually from gamestorming which is a book that that'll read and and he decided to use these posted things to try to give a bit of structure still freedom yeah thirty seconds one more question yep yep so if you know the domain already you might push your own insights to other people so it you need to be careful of that sometimes not knowing the domain is actually more useful and just focusing on facilitation because the domain knowledge is already there people have it have it the problem is they have part of it and they don't share it with each other you can observe observe behavior during the during the session and you will see that if people people get disengaged for example if they start really like getting angry and this kind of stuff that's your role as a facilitator to handle that and maybe jump in and say okay let's cool down let's make a break come back to it afterwards and and try to figure this out so it's really facilitation skills okay I think we are done thank you very much [Applause]

Channel: Voxxed Days Luxembourg

Views: 3,656

Rating: 4.9466667 out of 5

Keywords: VoxxedDays, Luxembourg, Conference

Id: QwOrbYTaDOY

Length: 51min 13sec (3073 seconds)

Published: Tue Jun 25 2019