[{"data":1,"prerenderedAt":73},["ShallowReactive",2],{"content-guides-eventstorming-introduction":3},{"markdown":4,"frontMatterAttributes":5,"bodyRaw":9,"contributorPaths":10,"menuType":12,"contentName":13,"slug":14,"readingTime":15,"menu":16,"nextDocItem":22,"previousDocItem":72},"\u003Cp>\u003Cem>"Where do I start?"\u003C\u002Fem> is a question that often arises when discussing or thinking about adopting\nevent-driven architectures. While event-driven architectures is seemingly simple to get started,\nthere are many considerations when adopting EDA as a strategy for your business.\u003C\u002Fp>\n\u003Ch1>Why EventStorming?\u003C\u002Fh1>\n\u003Cp>It's not uncommon for teams within company to each have their own understanding their problem\ndomain. When domain experts and technical teams are misaligned, it's hard or impossible to innovate\nand move quickly because of miscommunications.\u003C\u002Fp>\n\u003Cp>Have you worked at a company where a product team comes up with a list of requirements and throws\nthat list to the developers to build? That is an all-too-familiar scenario that typically doesn't\nlead to success. When the domain experts and engineers operate in their respective silos details are\nlost and assumptions are made . The end result is a product that may not solve the business problem,\ntechnical debt that makes adaption hard or impossible and frustrations across an organization.\u003C\u002Fp>\n\u003Cp>EventStorming is a technique that aims at bridging these gaps between business and engineering to\nreach a shared understanding. A side effect of this shared understanding is \u003Cem>better\u003C\u002Fem> software that\ncan \u003Cem>adapt\u003C\u002Fem> to changes and solves real-world problems for customers.\u003C\u002Fp>\n\u003Cblockquote>\n  \u003Cp>\n    It’s developers’ (mis)understanding, not domain experts’ knowledge, that gets released in\n    production.\n  \u003C\u002Fp>\n  \u003Cdiv>\n    - Alberto Brandolini, \u003Ca href=\"https:\u002F\u002Fwww.eventstorming.com\u002Fbook\u002F\">EventStorming creator\u003C\u002Fa>\n  \u003C\u002Fdiv>\n\u003C\u002Fblockquote>\n\n\u003Cdiv class=\"admonition\">\n  How can you ensure that your domain experts’ knowledge is what your teams will build and ship? \u003Ci>Turn\n  your developers and teams into domain experts.\u003C\u002Fi>\n\u003C\u002Fdiv>\n\n\u003Ch1>Exploring boundaries\u003C\u002Fh1>\n\u003Cp>A business domain is the area you and your company are working. You create solutions within this\ndomain to provide value to your customers and to make money or exist as a business entity. Most\nbusiness domains are complex enough to contain subdomains. An overly simplistic example is\ne-commerce. Shipping, billing and customer support are examples of subdomains within the e-commerce\nbusiness domains. Each subdomain may itself have multiple boundaries inside that need specific\nsolutions in order to provide business value. For example, the customer support subdomain may\ncontain multiple software systems to handle returns, billing, and website orders.\u003C\u002Fp>\n\u003Cp>The natural question is how do you identify, define and break down a domain and its subdomains so\nthat you can solve the challenges in each of them? EventStorming can help. The outcomes from\nEventStorming sessions vary depending on why type of session you are running, but the goal is always\nthe same: to come to a shared understand of a business process and model so that you can build and\ndeliver the right solution for your customers.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fguides\u002Feventstorming\u002Fassets\u002Fdiagrams\u002Fdomains-and-subdomains.png\" alt=\"A business domain is comprised of multiple subdomains.\">\u003C\u002Fp>\n\u003Ch4 class=\"admonition\">\n  EventStorming is a workshop-based approach used to break down a non-trivial business domain with\n  the goal of coming to a shared understanding across an organization or team.\n\u003C\u002Fh4>\n\n\u003Ch1>How to run EventStorming\u003C\u002Fh1>\n\u003Cp>EventStorming facilitates a shared understanding by getting domain experts in same physical or\nvirtual room to map a business process collaboratively. Through this exercise, people can ask\nquestions, sequence events in the business process, call out challenges and together build a model\nof how their business process works, or should work.\u003C\u002Fp>\n\u003Cp>EventStorming focuses on \u003Cem>understanding\u003C\u002Fem> vs. \u003Cem>solutioning\u003C\u002Fem>. Through EventStorming, you can find\nsubdomains, identifying bounded contexts and most importantly discover these collaboratively with a\ncross section of your business. During the process you use domains events as a language to describe\nthe process that you will model. In event-driven architectures, you can use these boundaries and\nevents as a starting point when you start to build independent and loosely couples systems.\u003C\u002Fp>\n\u003Cdiv class=\"admonition\">\n\n\u003Cp>EventStorming is a technique that is not limited to event-driven architectures, but is a natural\nfit. If you're using or plan to adopt an event-driven architecture strategy, we strongly suggest\nstarting with EventStorming.\u003C\u002Fp>\n\u003C\u002Fdiv>\n\n\u003Ch1>Flavors of EventStorming\u003C\u002Fh1>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fguides\u002Feventstorming\u002Fassets\u002Fdiagrams\u002Feventstorming-models.png\" alt=\"Choose your style of EventStorming sessions to start.\">\u003C\u002Fp>\n\u003Cp>Graphic showing three different types of EventStorming sessions, their focus and who participates.\u003C\u002Fp>\n\u003Cp>There are different types of EventStorming sessions with different participants and different\noutcomes.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Big Picture\u003C\u002Fstrong>: Designed to map a large and complex system or process. This is high level with\nthe majority of the participants being domain experts. Job family is mostly irrelevant, as long as\npeople have a good understanding of the business domain. The focus of a Big Picture session is\nlargely the \u003Cem>current state\u003C\u002Fem> rather than future state.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Process\u003C\u002Fstrong>: This is the next level down in terms of details. Once a subdomain or business\nboundaries have been identified in a Big Picture session, you can use a process-level session to\ngo into more depth. This flavor of EventStorming blends the current state with some \u003Cem>future\nstate\u003C\u002Fem>. It may involve more engineers.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Design\u003C\u002Fstrong>: A design-level session is down on the ground once a single team has a good\nunderstanding of a system or process and is getting ready to build. This focuses on what you \u003Cem>will\nbe building\u003C\u002Fem>, or future state. Participants include the technical delivery team with fewer\nnon-technical stakeholders. Once this is done teams can write user stories, plan a sprint or\notherwise start the development process. A team will be armed with an agreed upon understanding of\na business process which serves as their template for a proof-of-concept or first iteration.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch1>What's next?\u003C\u002Fh1>\n\u003Cp>Continue reading to learn how to use EventStorming and the benefits it provides. The following\nsections are sequenced and offer a pathway to run a Big Picture session.\u003C\u002Fp>\n\u003Cstyle>\n  .admonition {\n    background-color: rgb(230, 246, 230);\n    padding: 10px;\n    border: 1px solid darkgreen;\n    border-radius: 5px;\n    margin-top: 10px;\n    margin-bottom: 20px;\n  }\n  h4.admonition {\n    background-color: rgb(253, 253, 254);\n    text-align: center;\n    border: 1px solid gray;\n  }\n\u003C\u002Fstyle>\n",{"title":6,"order":7,"youtubeVideoID":8},"Introduction",1,"FG4UOoEJvBc","_\"Where do I start?\"_ is a question that often arises when discussing or thinking about adopting\nevent-driven architectures. While event-driven architectures is seemingly simple to get started,\nthere are many considerations when adopting EDA as a strategy for your business.\n\n# Why EventStorming?\n\nIt's not uncommon for teams within company to each have their own understanding their problem\ndomain. When domain experts and technical teams are misaligned, it's hard or impossible to innovate\nand move quickly because of miscommunications.\n\nHave you worked at a company where a product team comes up with a list of requirements and throws\nthat list to the developers to build? That is an all-too-familiar scenario that typically doesn't\nlead to success. When the domain experts and engineers operate in their respective silos details are\nlost and assumptions are made . The end result is a product that may not solve the business problem,\ntechnical debt that makes adaption hard or impossible and frustrations across an organization.\n\nEventStorming is a technique that aims at bridging these gaps between business and engineering to\nreach a shared understanding. A side effect of this shared understanding is _better_ software that\ncan _adapt_ to changes and solves real-world problems for customers.\n\n\u003Cblockquote>\n  \u003Cp>\n    It’s developers’ (mis)understanding, not domain experts’ knowledge, that gets released in\n    production.\n  \u003C\u002Fp>\n  \u003Cdiv>\n    - Alberto Brandolini, \u003Ca href=\"https:\u002F\u002Fwww.eventstorming.com\u002Fbook\u002F\">EventStorming creator\u003C\u002Fa>\n  \u003C\u002Fdiv>\n\u003C\u002Fblockquote>\n\n\u003Cdiv class=\"admonition\">\n  How can you ensure that your domain experts’ knowledge is what your teams will build and ship? \u003Ci>Turn\n  your developers and teams into domain experts.\u003C\u002Fi>\n\u003C\u002Fdiv>\n\n# Exploring boundaries\n\nA business domain is the area you and your company are working. You create solutions within this\ndomain to provide value to your customers and to make money or exist as a business entity. Most\nbusiness domains are complex enough to contain subdomains. An overly simplistic example is\ne-commerce. Shipping, billing and customer support are examples of subdomains within the e-commerce\nbusiness domains. Each subdomain may itself have multiple boundaries inside that need specific\nsolutions in order to provide business value. For example, the customer support subdomain may\ncontain multiple software systems to handle returns, billing, and website orders.\n\nThe natural question is how do you identify, define and break down a domain and its subdomains so\nthat you can solve the challenges in each of them? EventStorming can help. The outcomes from\nEventStorming sessions vary depending on why type of session you are running, but the goal is always\nthe same: to come to a shared understand of a business process and model so that you can build and\ndeliver the right solution for your customers.\n\n![A business domain is comprised of multiple subdomains.](\u002Fassets\u002Fexternal\u002Fguides\u002Feventstorming\u002Fassets\u002Fdiagrams\u002Fdomains-and-subdomains.png)\n\n\u003Ch4 class=\"admonition\">\n  EventStorming is a workshop-based approach used to break down a non-trivial business domain with\n  the goal of coming to a shared understanding across an organization or team.\n\u003C\u002Fh4>\n\n# How to run EventStorming\n\nEventStorming facilitates a shared understanding by getting domain experts in same physical or\nvirtual room to map a business process collaboratively. Through this exercise, people can ask\nquestions, sequence events in the business process, call out challenges and together build a model\nof how their business process works, or should work.\n\nEventStorming focuses on _understanding_ vs. _solutioning_. Through EventStorming, you can find\nsubdomains, identifying bounded contexts and most importantly discover these collaboratively with a\ncross section of your business. During the process you use domains events as a language to describe\nthe process that you will model. In event-driven architectures, you can use these boundaries and\nevents as a starting point when you start to build independent and loosely couples systems.\n\n\u003Cdiv class=\"admonition\">\n\nEventStorming is a technique that is not limited to event-driven architectures, but is a natural\nfit. If you're using or plan to adopt an event-driven architecture strategy, we strongly suggest\nstarting with EventStorming.\n\n\u003C\u002Fdiv>\n\n# Flavors of EventStorming\n\n![Choose your style of EventStorming sessions to start.](\u002Fassets\u002Fexternal\u002Fguides\u002Feventstorming\u002Fassets\u002Fdiagrams\u002Feventstorming-models.png)\n\nGraphic showing three different types of EventStorming sessions, their focus and who participates.\n\nThere are different types of EventStorming sessions with different participants and different\noutcomes.\n\n- **Big Picture**: Designed to map a large and complex system or process. This is high level with\n  the majority of the participants being domain experts. Job family is mostly irrelevant, as long as\n  people have a good understanding of the business domain. The focus of a Big Picture session is\n  largely the _current state_ rather than future state.\n- **Process**: This is the next level down in terms of details. Once a subdomain or business\n  boundaries have been identified in a Big Picture session, you can use a process-level session to\n  go into more depth. This flavor of EventStorming blends the current state with some _future\n  state_. It may involve more engineers.\n- **Design**: A design-level session is down on the ground once a single team has a good\n  understanding of a system or process and is getting ready to build. This focuses on what you _will\n  be building_, or future state. Participants include the technical delivery team with fewer\n  non-technical stakeholders. Once this is done teams can write user stories, plan a sprint or\n  otherwise start the development process. A team will be armed with an agreed upon understanding of\n  a business process which serves as their template for a proof-of-concept or first iteration.\n\n# What's next?\n\nContinue reading to learn how to use EventStorming and the benefits it provides. The following\nsections are sequenced and offer a pathway to run a Big Picture session.\n\n\u003Cstyle>\n  .admonition {\n    background-color: rgb(230, 246, 230);\n    padding: 10px;\n    border: 1px solid darkgreen;\n    border-radius: 5px;\n    margin-top: 10px;\n    margin-bottom: 20px;\n  }\n  h4.admonition {\n    background-color: rgb(253, 253, 254);\n    text-align: center;\n    border: 1px solid gray;\n  }\n\u003C\u002Fstyle>\n",[11],"content\u002Fcontributors\u002Fbrian-zambrano.json","LIST","EventStorming","\u002Fcontent\u002Fguides\u002Feventstorming\u002Fintroduction","5 min",[17],{"title":13,"content":18},[19,22,29,35,41,47,54,60,66],{"title":6,"order":7,"youtubeVideoID":8,"time":15,"path":20,"id":21,"link":14},"introduction","introduction.md",{"title":23,"order":24,"time":25,"path":26,"id":27,"link":28},"Step 1 - Invitations",10,"2 min","invitations","invitations.md","\u002Fcontent\u002Fguides\u002Feventstorming\u002Finvitations",{"id":30,"title":31,"order":32,"time":25,"path":33,"link":34},"events.md","Step 2 - Crowdsource events",20,"events","\u002Fcontent\u002Fguides\u002Feventstorming\u002Fevents",{"title":36,"order":37,"time":25,"path":38,"id":39,"link":40},"Step 3 - Sequence events",30,"timeline","timeline.md","\u002Fcontent\u002Fguides\u002Feventstorming\u002Ftimeline",{"title":42,"order":43,"time":25,"path":44,"id":45,"link":46},"Step 4 - People",40,"people","people.md","\u002Fcontent\u002Fguides\u002Feventstorming\u002Fpeople",{"title":48,"order":49,"time":50,"path":51,"id":52,"link":53},"Step 5 - Hotspots",50,"1 min","hotspots","hotspots.md","\u002Fcontent\u002Fguides\u002Feventstorming\u002Fhotspots",{"title":55,"order":56,"time":25,"path":57,"id":58,"link":59},"Step 6 - External systems",60,"systems","systems.md","\u002Fcontent\u002Fguides\u002Feventstorming\u002Fsystems",{"title":61,"order":62,"time":50,"path":63,"id":64,"link":65},"Step 7 - Pivotal events",70,"boundaries","boundaries.md","\u002Fcontent\u002Fguides\u002Feventstorming\u002Fboundaries",{"id":67,"title":68,"time":69,"path":70,"link":71},"learn-more.md","Learning more","4 min","learn-more","\u002Fcontent\u002Fguides\u002Feventstorming\u002Flearn-more",null,1792578865853]