Podcasts about Event storming

How can teams unlock elite productivity while navigating the complexities of DevOps? Expert consultant Xing Zhou reveals how DORA metrics—from deployment frequency to change failure rate, drive performance and bridge gaps between leadership and the team members. Xing's impressive career spans companies like Amazon, Pivotal Labs, and Integral. He currently serves as  Xing has led high-performing teams, implemented cutting-edge DevOps strategies, and helped organizations make meaningful progress toward elite DORA benchmarks. Xing and Ashok discuss actionable steps for C-Suite leaders and product teams, focusing on SLAs, CI/CD, behavior-driven development, and event storming workshops to drive alignment and enhance productivity. Packed with real-world examples, this conversation is essential listening for anyone aiming to turn metrics into a reflection of team health and organizational success. Inside the episode... A clear explanation of Dora metrics: what they are and why they matter. How SLAs and SLOs empower teams while aligning with organizational goals. Continuous delivery (CD): balancing technical capability with business priorities. The difference between pull request (PR) and trunk-based development for CI. Behavior-driven development (BDD) and its role in improving test automation. Event storming: how this simple tool drives clarity in business processes. Practical strategies for introducing new practices like BDD or event storming to your team. Mentioned in this episode: Behavior-Driven Development (BDD) Gherkin language for test automation Event storming Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Success Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. Subscribe to the Convergence podcast wherever you get podcasts including video episodes to get updated on the other crucial conversations that we'll post on YouTube at youtube.com/@convergencefmpodcast Learn something? Give us a 5 star review and like the podcast on YouTube. It's how we grow.   Follow the Pod Linkedin: https://www.linkedin.com/company/convergence-podcast/ X: https://twitter.com/podconvergence Instagram: @podconvergence

Was bedeutet es eigentlich, Domain-driven Design (DDD) umzusetzen? Diese Episode beginnt die Reise durch ein vollständiges Beispiel und zeigt , wie die verschiedenen Techniken wie Event Storming und strategisches Design zusammen wirken, um den Aufbau von Anwendungen zu unterstützen. Das zeigt, wie man mit einem einfachen, aber vollständigen Ansatz mit DDD beginnen können. In dieser Episode geht es um taktisches Design, CQRS, Event Sourcing und hexagonale Architektur. Links Training Domain-driven Design saniert Legacy Folien Taktisches Domain-driven Design (DDD) Taktisches Domain-Driven Design mit Java und jMolecules mit Oliver Drotbohm Folgen zu Architecture Management Events, Event Sourcing und CQRS Video zu Kafka als Datenbank-Monolith Christian Stettler: Domain Events vs. Event Sourcing - Weshalb Domain Events und Event Sourcing nicht vermischt werden sollten Vaughn Vernon about Ports and Adapters and DDD

Was bedeutet es eigentlich, Domain-driven Design (DDD) umzusetzen? Diese Episode beginnt die Reise durch ein vollständiges Beispiel und zeigt , wie die verschiedenen Techniken wie Event Storming und strategisches Design zusammen wirken, um den Aufbau von Anwendungen zu unterstützen. Das zeigt, wie man mit einem einfachen, aber vollständigen Ansatz mit DDD beginnen können. In dieser Episode geht es um die Elemente von Strategic Design wie Bounded Context. In einer zweiten Episode wird es um taktisches Design gehen. Links Folien Bert Jan Schrijver about Generic or Specific? Domain Story Telling mit Henning Schwentner und Stefan Hofer Wir bauen eine Software-Architektur - Struktur der Lösung Technischer Kontext und fachliche Aufteilung - iSAQB Advanced Beispielaufgabe Bounded Context - Was ist das genau? Team Topologies Team Topologie in der Praxis mit Kim Nena Duggen

Dino Scheidt is an AI Engineer, former CTO and Founder who works with Fortune 50s, Start-Ups, and Governments on Data Intelligence and AI Architectures. In this conversation, we explore the evolving landscape of AI with a particular focus on generative AI and its applications. Dino criticizes the concept of 'AI strategies,' arguing that AI should be seen as a tool rather than a strategy. Despite his initial skepticism towards generative AI, Dino acknowledges its potential, especially in transforming traditional value chains through AI-enabled communications. We also delve into the challenges and opportunities posed by non-deterministic systems, the concept of Data P&L, and the complexity of integrating generative AI into existing business operations. Dino wraps up the discussion by emphasizing the importance of lateral thinking and digital representation of business processes to leverage future AI innovations effectively. EPISODE LINKS: Dino Scheidt LinkedIn: https://linkedin.com/in/dinoscheidt Dino Scheidt Website: https://din.ooo The Gartner Hype Cycle: https://en.wikipedia.org/wiki/Gartner_hype_cycle TIMESTAMPS: 00:00:12 Introduction and background 00:00:45 AI and Generative Models 00:04:36 Deterministic vs Non-Deterministic Systems 00:08:19 Unpredictability, Value Chain, and AI Integration 00:13:26 Hype Cycle: Adjective to Noun 00:19:13 Strategic Integration of Generative AI 00:28:36 Value of Generative AI: Consumer vs. Enterprise Perspectives 00:32:12 Event Storming and Tactical AI 00:39:51 Future of AI and Final Thoughts 00:42:36 Closing CONNECT: Website: https://hoo.be/elijahmurray YouTube: https://www.youtube.com/@elijahmurray Twitter: https://twitter.com/elijahmurray Instagram: https://www.instagram.com/elijahmurray LinkedIn: https://www.linkedin.com/in/elijahmurray/ Apple Podcasts: https://podcasts.apple.com/us/podcast/the-long-game-w-elijah-murray/ Spotify: https://podcasters.spotify.com/pod/show/elijahmurray RSS: https://anchor.fm/s/3e31c0c/podcast/rss

In dieser Folge des INNOQ Podcasts geht es um einen echten Klassiker der modernen Softwareentwicklung: „Programming as Theory Building" von Peter Naur. Daniel Westheide und Sven Johann sprechen über dessen anhaltende Relevanz und warum Programmieren weit mehr als das Schreiben von Code ist. Sie erläutern, wie genaue Planung und ein tiefes Verständnis für das Softwaresystem die Grundlage für erfolgreiche Projekte bilden. Daniel gibt zudem Einblicke in praktische Methoden wie Domain-driven Design, Event Storming und Prototyping, die helfen, langfristig wartbare Software zu entwickeln. Außerdem sprechen Sven und sein Gast über die Bedeutung von genauer Dokumentation und warum es wichtig ist, Entwickler:innen langfristig im Team zu halten, um Wissen zu teilen.

Christoph Steinlehner is a Product Management coach who helps product managers and leaders that are feeling stuck in their work caught and struggling to facilitate between different perspectives in a business.In today's episode:The challenges of effective business-product communicationHow visual mapping can help improve communicationThe MAPPER method walkthough—Christoph's contact info:• LinkedIn: https://www.linkedin.com/in/csteinlehner• Website: https://csteinlehner.com/•  Substack contributor: https://mapperclub.substack.com/—Where to find the host, Adam Wakeling:• Twitter: https://twitter.com/adamjwakeling• LinkedIn: https://www.linkedin.com/in/adam-wakeling-26494b35/• YouTube: https://www.youtube.com/@TheProductDevelopmentPodcastIn this episode, we cover: (00:00) Preview(00:54) Intro(02:01) Main challenges in effective communication(03:40) X-department perspectives in communication(05:20) The bigger picture(08:28) What is visual mapping?(11:48) Differences in types of visual maps(16:18) Walkthough of MAPPER method(25:20) Reflection part of MAPPER(26:03) Similarity to Event Storming (27:53) Challenges in implementing MAPPER(33:21) Resistance to new frameworks(34:50) Leveraging AI with the MAPPER method (39:04) OutroFollow the podcast on Twitter: @proddevpodcastGet in touch with the host, Adam Wakeling, on Twitter: @adamjwakeling

Qualitätsanforderungen, auch bekannt als nicht-funktionale Anforderungen, sind entscheidend, damit die Software-Architektur tatsächlich die richtigen Probleme löst. Nur mit den passenden Qualitätsanforderungen kann man die geeigneten Technologien auswählen. Doch die richtigen Anforderungen zu finden, ist oft eine Herausforderung. In dieser Episode stellt Michael Plöd “Quality Storming” vor – einen Ansatz, mit dem man gemeinsam mit Domänen-Expert und anderen Stakeholdern kollaborativ Qualitätsanforderungen ermitteln kann. Links Michaels Artikel über Quality Storming Nicole Rauch zu Event Storming & Specification by Example Domain Story Telling mit Henning Schwentner und Stefan Hofer Folgen zu Collaborative Modeling Systems Thinking in Large-Scale Modeling with Xin Yao - OOP Special Beispiele für Quality Requirements Präsentation von Michael zu Quality Storming Dave Gray, Sunni Brown, James Macanufo: Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers

Alberto Brandolini is the creator of Event Storming, a technique aimed at fostering a shared understanding of business concepts among all stakeholders in a software development endeavor. However, architects may encounter challenges within the business domain that exceed their influence. Alberto will explore this issue and propose potential solutions. Links Alberto's Event Storming Book Folge über DDD, Event Storming und Specification by Example mit Nicole Rauch Folge über das Messen von Produktivität

"Jako użytkownik chcę przeszukać bazę książek, aby znaleźć kilka książek" - takiego rodzaju User Story są niestety dość typowe i w zasadzie niewiele dobrego wnoszą do projektu. A trudności, jakie często pojawiały się przy formułowaniu wartościowych User Story, skutkowały się pojawianiem różnych technik wspomagających ich rozpoznanie. Kuźnią wielu pomysłów były prace zespołów stosujących Extreme Programming w projektach Chrysler C3 i Connextra... Kompleksowe podejście zarówno do identyfikacji User Stories jak i ich dalszego wykorzystania z projekcie zaproponował w końcu w 2014 roku Jeff Patton, proponując warsztatową technikę User Story Mapping.W tym odcinku Better Software Design dodajemy więc User Story Mapping do naszego analitycznego toolboksa. A moim gościem w tej rozmowie jest Michał Bartyzel, który bardzo mocno wykorzystuje tę technikę w swojej codziennej pracy z zespołami. W tym odcinku rozmawiamy z Michałem między innymi o:bezużyteczności wielu historyjek typu "Jako klient chcę się zalogować, aby zrobić zakup w sklepie",odkrywaniu właściwych aktorów, ich celi biznesowych i funkcjonalności, które służą ich osiągnięciu,sposobach budowania mapy historyjek, zgodnie z założeniami User Story Mappingu,wykorzystaniu USM w projekcie,różnicach i podobieństwam pomiędzy EventStormingiem i User Story Mappingiem,sposobach prowadzenia warsztatu analitycznego.Materiały dodatkowe:It's All in How You Slice, artykuł Jeffa Pattona opisujący pierwotne założenia techniki, rozwiniętej następnie do User Story MappinguThe New User Story Backlog is a Map, drugi po artykule istotny wpis Pattona na temat problemów z historyjkamiUser Story Mapping: Discover the Whole Story, Build the Right Product, książka Jeffa z 2012 roku, przedstawiająca technikę User Story MappinguStory Map Concepts oraz Agile Story Essentials, krótkie i rzeczowe podsumowania pokazujące zasadę działania USMPolecam także zajrzeć na stronę Michała, a w szczególności na prowadzonego przez niego bloga.Zapraszam!

Dzisiaj spotykamy się w trochę większym gronie: naszym gościem jest Mariusz Gil, specjalista od event stormingu i podcaster "Better Software Design". Rozmawiamy o event stormingu od a do z - czyli od definicji, przez cały proces, aż po narzędzia. Przemaglowaliśmy Mariusza dość dokładnie, więc można powiedzieć, że ten odcinek Pato to takie kompendium event stormingu. Enjoy! Nasze sociale i linki Materiały do odcinka

Hosts Dan Ivovich, Owen Bickford, and Sundi Myint kick off the 11th season of the Elixir Wizards podcast. This season's theme is “Branching Out from Elixir,” which expands the conversation to compare notes with experts from other communities; they discuss their experiences with other languages like JavaScript, PHP, Python, Ruby, C#, Go, and Dart before and after learning Elixir. This season's conversations will illuminate how problems are solved in different languages vs. Elixir; upcoming episode topics teased include education, data processing, deployment strategies, and garbage collection; the hosts express excitement for conversations analyzing similarities and differences between communities. Topics Discussed in this Episode Season 11 branches out from Elixir to compare notes with other programming communities Sundi, Owen, and Dan introduce the season theme and their interest in exploring these conversations The hosts compare their experiences with PHP, JavaScript, Python, Ruby, C#, Go, Dart and Elixir The Wizards compare and contrast differences in their personal experience building similar things with different languages Dan dreams in Ruby and uses it for quick prototypes Comparing problem-solving approaches across languages will reframe perspectives Upcoming episodes explore data processing workflows, machine learning, and game development Pop Quiz: Who's that Pokémon... or language, or framework? Links Mentioned https://smartlogic.io/ https://codepen.io/ https://i.redd.it/0lg7979qtr511.jpg

Rafal Maciag is Founder and CEO of ModelingEvolution, which helps businesses and organisations implement effective, high-quality software solutions. The company's Modellution product provides a collaboration platform for Event Storming and Event Modeling.In today's episode:• The foundational concept of Event Storming and how it serves as a catalyst for collaborative transformation• How to integrate Event Storming and Event Modeling concepts into a business• Rafal's story of founding a company and lessons learned—Rafal's contact info:• LinkedIn: https://www.linkedin.com/in/rafalmaciag/• ModelingEvolution: https://www.modelingevolution.com/—Where to find the host, Adam Wakeling:• Twitter: https://twitter.com/adamjwakeling• LinkedIn: https://www.linkedin.com/in/adam-wakeling-26494b35/—In this episode, we cover:(00:00) Introduction(00:56) Putting everyone on the same page(02:32) What is Event Storming?(08:40) Examples of 'events'(12:39) Enabling Customer Journey Mapping(16:00) How often to conduct Event Storming(23:48) 'Movies' in Event Storming(26:17) Who organises everything?(28:10) Challenges of implementation of Event Storming(29:54) How organisations are working with ModelingEvolution(31:24) What Rafal has learned from founding a company(33:37) Building the right things(36:14) Final thoughts from Rafal(38:00) OutroFollow the podcast on Twitter: @proddevpodcastGet in touch with the host, Adam Wakeling, on Twitter: @adamjwakeling

In der Folge gibt es einen Vortrag von mir zu sehen. Er ging als Premiere im Rahmen des Streams live und es gab eine Diskussion im Chat. Domain-driven Design (DDD) steht für eine Vielzahl an Techniken wie strategisches DDD, taktisches DDD und kollaborative Modellierung. Dieser Vortrag gibt einen Überblick über das DDD-Universum. Dabei stellt er nicht nur die verschiedenen Konzept vor. Er zeigt außerdem auch die jeweiligen Vor- und Nachteile der Praktiken auf und weist auf die typischen Fallstricke hin - und wie man sie vermeiden kann. Links Training Softwarearchitektur-Kickstart 1-Tages-Workshop “Microservices: Architektur, Implementierung und Produktion” 1-Tages-Workshop “Advanced Microservices” Folge “How to Understand Almost Anything” mit Markus Völter Folge “Domain Prototyping” mit Tobias Goeschel Folge “Architektur-Migration nicht nur zu Microservices Folge “Strategisches Domain-driven Design” Folge “DDD, Event Storming und Specification by Example” mit Nicole Rauch Folge “Domain Story Telling” mit Henning Schwentner und Stefan Hofer

Ein letztes Mal "Herzlich Willkommen zu Unboxing Agile" heisst es in dieser Folge. Die Community hat zahlreiche Namensvorschläge abgegeben, ich habe mir wochenlang mit der Entscheidung Zeitgelassen und ab der nächsten Folge erstrahlt dieser Podcast in neuem Glanze. Doch vorher gibt es noch ein absolutes Highlight. Einen Blick in einen der besten Arbeitgeber Weltweit: Rossmann. Josi Schlichting ist Bereichsleiterin Methoden & Coaching in Organisation & Prozesse. Was das heißt, dass erklärt sie im Podcast. Außerdem erzählt sie, wie sehr der Familienbetrieb Rossmann durch eine sehr gute Führungskultur das Unternehmen zu einem tollen Arbeitgeber macht, bei der agile Werte und New Work sehr schön vorgelebt werden. Eine wirklich tolle Folge. Viel Spaß beim Hören.

Was hat Event Storming mit dem Bullshit-Asymmetrie-Prinzip (auch bekannt als "Brandolinis Gesetz") zu tun? Diese und noch viel wichtigere Fragen, besprechen wir in dieser Podcast-Folge mit Jürgen Meurer. Event Storming ist eine Praktik, die ursprünglich aus dem Domain Driven Design (DDD) stammt. Die Erfindung der Methode wird Alberto Brandolini zugeschrieben. Ja genau - der mit dem gleichnamigen Gesetz: „Das Widerlegen von Schwachsinn erfordert eine Größenordnung mehr an Energie als dessen Produktion.“ Zurück zum Thema: Event Storming ist ein (Groß)Gruppenformat, um das verteilte Wissen über eine fachlich-technische Domäne in einem Workshop explizit zu machen und so ein "gemeinsam geteiltes mentales Modell" zu entwickeln. Kurz: alle die dabei waren kapieren den Gesamtzusammenhang der Fragestellung plötzlich viel besser. Gerade im Kontext komplexer Produktentwicklung eignet sich diese Methode somit sehr gut, ein gemeinsames Verständnis zu schaffen. Sie kann damit eine tolle Grundlage für Story Mapping oder Customer Journey Mapping bieten - aber auch für die Erstellung klassischer Projekt Strukturpläne. Du kannst Event Storming sowohl für bestehende Produkte anwenden, als auch in der Entwicklung komplett neuer Produkte und Services einsetzen. Jürgen Meurer, setzt diese Methode bereits seit vielen Jahren erfolgreich bei seinen verschiedenen Arbeitgebern an. Inzwischen ist Jürgen als Agile Coach aktiv, hat aber auch lange als Product Owner und Scrum Master gearbeitet. Damit ist er übrigens auch ein interessantes Beispiel für den Weg, sich vom Product Owner zum Scrum Master bzw. Agile Coach zu entwickeln. Seine letzten Stationen waren Studitemps, Freeyou, AXA und nun SHOP APOTHEKE bzw. Redcare Pharmacy. **Quellen und Links zum Event Storming** Jürgen Meurer empfiehlt die folgenden Quellen, um mehr über Event Storming zu lernen: - zentrale Webseite zum Thema: https://www.eventstorming.com/ - Buch von Alberto Brandolini: Introducing EventStorming - An act of Deliberate Collective Learning (leanpub.com/introducing_eventstorming) - Brandolinis Gesetz, auch Bullshit-Asymmetrie-Prinzip - Weitere passende Podcastfolgen Weitere Themen zu bestimmten Podcast-Folgen, auf die Tim im Laufe des Gesprächs hinweist: - Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen - Mit Customer Journey Maps arbeiten Jürgen Meurer freut sich über den Kontakt zu euch. Für weitere Fragen rund um das Thema und zu seinen Erfahrungen erreicht ihr ihn am besten auf seinem LinkedIn-Profil (linkedin.com/in/juergen-meurer/). Kanntest du Event Storming bereits vorher? Hast du eventuell selbst schon mal an einer solchen Session teilgenommen? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Domain-Driven Design ist in aller Munde, aber was steckt hinter dem Buzzword?

Adam Dymitruk, CEO and founder of Adaptech Group, joins host Jeff Doolittle for an exploration of the event modeling approach to discovering requirements and designing software systems. Adam explains how the structured approach eliminates the specifics of implementation details and technology decisions, enabling clearer communication for all stakeholders while keeping conversations focused on the business opportunity. Using concrete examples of event modeling in practice, they examine event modeling in the context of other related approaches and methodologies, including event sourcing, event storming, CQRS, and domain-driven design.  

"Nie informatyzujemy bałaganu" - to jedno ze zdań, które wyniosłam ze studiów i chodzi mi ono po głowie przez lata pracy jako analityk biznesowy. Zanim zlecisz wykonanie systemu IT lub zaczniesz dobierać gotowy produkt pod sposób pracy Twojej firmy - sprawdź, czy on ma sens, czy proces np. zakupu nie trwa zbyt długo, nie zakręca niepotrzebnie na wiele działów w firmie. Jak bardzo można skomplikować proste sprawy widać w historii, kiedy ostatnio chciałam kupić tapetę. Byłam zdecydowanym klientem i jedyne, czego potrzebowałam to wejść i kupić. Najlepiej szybko. Zakup trwał 11 kroków i wiele kontaktów przez sklep, maila i telefon! Kiepski proces powoduje, że: klienci uciekają lub zniechęcają się (bo ile razy można podawać swój adres?) pracownicy tracą koncentrację, masę czasu, a to pompuje koszty, które odbijają się albo na kliencie albo na firmie w postaci niższej marży Czym jest proces? Zespół następujących po sobie działań pozostających w związku przyczynowo-skutkowym wykorzystywany dla uzyskania zamierzonego rezultatu przez zespół fachowców na wielu stanowiskach. (Trocki, Romanowska) Dla małych firm: procedury stanowiskowe odgrywają również ważną rolę jak między-stanowiskowe procesy - też powinny być optymalne warto tworzyć procesy, bo to zasób, który zostanie w firmie nawet wtedy, kiedy dobry pracownik zmieni pracę, a następcy będą mogli utrzymać wysoki poziom i powtarzać sukcesy Dla dużych firm: w dużej firmie mamy klapki na oczach i widzimy głównie swój dział, zespół. Zapominamy, że wszystko, co robimy, ma swoje konsekwencje w procesie obejmującym wiele działów, sięgającym klienta. nieoptymalne procesy generują ogromne koszty (straty), a przy tym są mniej widoczne, bo "dla mnie wygląda OK". Jeśli nie wiesz jak wyglądają Twoje procesy, albo ciągną się one przypadkowymi pętlami przez wiele działów - zrób stop! Nie trać czasu na IT. Najpierw uporządkuj to, jak chcesz działać. Co zrobić? 0. Wyciągnij opisane procesy biznesowe (jeśli masz) Sprawdź czy są aktualne. Zaktualizuj. 1. Zmapuj proces warsztaty, wywiady, obserwacje, analiza danych kierownicy, specjaliści, reprezentanci działów, zespołów zrób jak potrafisz lub EventStorming, Value Stream Mapping, BPMN 2. Usprawnij proces skracaj czas, nakład, koszt, ścieżkę krytyczną wybieraj sprawy z puli wyznaczaj priorytety eliminuj wąskie gardło ujawniaj reguły decyzyjne i automatyzuj je 3. Informatyzuj proces przypomnij cel przedsięwzięcia wyznacz priorytetowe obszary procesu biznesowego i zaplanuj wydania określ wymagania na rozwiązanie IT w oparciu o proces Masz doświadczenia z chaotycznym procesem biznesowym? Próbowaliście taki zinformatyzować? Podziel się swoimi doświadczeniami w komentarzu. Subskrybuj podcast "najpierw analiza biznesu" w ulubionym miejscu: Spotify: https://open.spotify.com/show/7A6f1SYYyoxspRNrBo1WgU?si=51c38fc6d04542d9 Apple podcasts: https://podcasts.apple.com/pl/podcast/najpierw-analiza-biznesu/id1642672502 Google podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5saWJzeW4uY29tLzQzNDI4My9yc3M Zostaw ocenę podcastu i komentarz, abyśmy docierali do większej liczby przedsiębiorców i managerów wprowadzających rozwiązania IT do swojej organizacji. Playlista YouTube: https://www.youtube.com/playlist?list=PLWBT6pVo_3e1JLFu2mX0TUVnibZHI4RFN analiza IT: https://www.analizait.pl/category/podcast-najpierw-analiza-biznesu/ Zostańmy w kontakcie na: kanale YT: https://www.youtube.com/channel/UCs6T_zfDTFPxFMfvi2nonAQ newsletterze dla przedsiębiorców / biznesu: https://analizait.pl/analityczny/podcast/  

It's important that engineers challenge tech strategy. We talk about Challenge in our book: The Value Flywheel Effect. In a previous episode found we went over the Value Flywheel in general. There are four phases: Clarity of Purpose, Challenge, Next Best Action, and Long Term Value. Today, we're going to deep dive into Challenge, which is phase two. Challenge is about the environment. When you decide on a strategy, do you have the right environment to challenge it? We've found this to be hugely important. In the last episode, we talked about Clarity of Purpose and setting direction. Part of bringing people along with you, is creating an environment where they can question purpose and challenge direction. But also, it's doing it in a safe and constructive fashion. You don't have your architecture leaders setting the direction and imposing it. You need to do it together. And you need to do things in a collaborative and facilitated to invite challenge. Techniques we use like Wardley Mapping, Event Storming and Threat Modelling are done as a team and collaboratively. People have an opportunity to challenge the process and artefacts. They're not challenging the individuals. That's very important. Because you need to have a good feedback loop. To understand if it can be better. Or if this could be improved. In high performance organisations in the cloud, things move very fast. You can't know at all. Challenge is about engineers. Our greatest engineers know the nuts and bolts and the nooks and crannies of the system. If you silence their voice, you're going to lose a huge amount of value. If you create a good environment, your engineers can point out where things won't work. Or bring new ideas to the table. You get richer system. So design your organisation and your tech around the ability to challenge. It's absolutely critical. Architects and senior leadership teams are there to enable and empower teams to deliver the best outcomes they can. It's about flipping the hierarchy. The team is at the top of the pyramid. And from a hierarchical point of view, we're there to enable and support. If you hire smart engineers, your best technical strategy is to get out of their way. Make sure they know what the goal is, and get out of their way. You have got to put in the right support systems to make sure people can work effectively. In traditional leadership, there can be a struggle. The team is carving out their own way and traditional leaders don't like that. But if you hire smart people, you need to let them do the work. You need enabling constraints as well. To guide engineers along the path. You need to enable teams to grow really fast, but you want to do it in a secure and well architected way. So that you're not going fast and creating lots of technical debt. Part of an environment for success is making sure guardrails are in place to enable engineers go fast responsibly. A big part of this is understanding where we are on the journey. By mapping your org capability and environment you can see if you have the capabilities to set you up for success. And if you have expertise for secure development, Wardley Mapping or Serverless, for example. If you don't then what are you going to do to get them in place for your teams? The last thing is pathway to production. By making sure you have a rapid feedback loop into the hands of real users you're part of an environment for success. Because you are removing impediments to the flow of value to end users. You have a well oiled pathway to production. So you're not waiting months and sometimes years for feedback on the things that your teams are working on. What happens if you don't have a good environment for challenge. You'll start to see people disengage. They'll feel that they are not listened to. And they will leave eventually. Especially if they're talented engineers. If they don't have an avenue to challenge, contribute or give their opinion, then that lack of engagement will drive them away. Also you're not getting the best out of your teams. You're not going to be able to meet your Clarity of Purpose. Or your goals because the teams are following a plan that was decided in advance. So there is no push back on that. You will see frustration and people will not feel part of the process. Team interaction modes will be suboptimal. Lots of teams will do the same things. There will be repeat work because there's no way to challenge. You'll see teams competing with each other. Instead of enabling and empowering each other. There are two systems. The system of all the employees in the company. And then the system or the technology we're working on. You have to bring those two together and look at them through the same lens. And that's something that I think architects have to do. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

This interview was recorded for the GOTO Book Club.gotopia.tech/bookclubRead the full transcription of the interview hereJames Higginbotham - Author of "Principles of Web API Design" and Executive API Consultant at LaunchAnyMike Amundsen - Author of "Design and Build Great Web APIs" and (Co-)Author of Many More BooksDESCRIPTIONJames Higginbotham, author of “Principles of Web API Design”, outlines the key points of creating and using APIs in today's world. In the conversation with Mike Amundsen, author of “RESTful Patterns and Best Practices for API's Cookbook” you discover the principles of James' ADDR process and how job stories and event storming contribute to a successful API launch. Furthermore, they touch upon key terms such as minimum viable portal and why API boundaries are so hot at the moment. The interview is based on James's book "Principles of Web API Design".RECOMMENDED BOOKSJames Higginbotham • Principles of Web API DesignMike Amundsen • Design and Build Great Web APIsMike Amundsen • RESTful Web ClientsRonnie Mitra & Irakli Nadareishvili • Microservices: Up and RunningRonnie Mitra, Irakli Nadareishvili, Matt McLarty & Mike Amundsen • Microservice ArchitectureRonnie Mitra, Mehdi Medjaoui, Erik Wilde & Mike Amundsen • Continuous API ManagementRonnie Mitra & many more • DataPower SOA Appliance Administration, Deployment, and Best PracticesTwitterLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket at gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily.Discovery MattersA collection of stories and insights on matters of discovery that advance life...Listen on: Apple Podcasts Spotify Health, Wellness & Performance Catalyst w/ Dr. Brad CooperLooking for a catalyst to optimize your health, wellness & performance? You've found it!!Listen on: Apple Podcasts Spotify

Events sind ein wichtiges Element vieler Architekturen. Sie spielen in ganz unterschiedlichen Bereichen eine Rollen: Bei der Analyse mit Event Storming, bei der Implementierung im Domain-driven Design, bei der Verwaltung von Zuständen mit Event Sourcing und bei der Aufteilung von Systemen in lesende und schreibende Teile mit CQRS (Command Query Segregation Principle). In dieser Episode diskutiert Eberhard diese Bereiche und welche Rolle Events in jedem von ihnen spielen. In der Praxis führen Missverständnisse in diesem Bereich immer wieder zu Architektur-Herausforderungen. Links Episode mit Nicole Rauch u.a. zu Event Storming DDD Referenz Martin Fowler zu Event Sourcing Kafka Video Susanne Braun zu Eventual Consistency Episode zu Microservices, Transaktionen und Konsistenz Christian Stettlers Artikel zu Domain Events vs Event Sourcing

Provided as a free resource by DataStax https://www.datastax.com/products/datastax-astra?utm_source=DataMeshRadio (AstraDB) In this episode, Scott interviews two Domain Driven Design (DDD) experts from Thoughtworks - Danilo Sato Director and the Head of Data & AI (part of Office of the CTO) and Andrew Harmel-Law, Technical Principal. This was a further delve into Domain Driven Design for Data after the conversations with Paolo Platter and Piethein Strengholt. Danilo and Andrew gave a lot of great information about Event Storming, domain definitions and boundaries, ubiquitous language, and so much more but the main theme was "just get people to talk to each other". DDD is about bridging the gap between how the tech people talk and how the business/business people talk; if you are doing it right, both sides can understand each other and then the engineers can implement those business process learnings as part of the code. For an initial PoC, Danilo recommends starting with 2-3 data products. It is better if you can do the PoC across multiple domains but it isn't necessary. Validate value and do it quickly. As Andrew mentions, the earlier you can show value, the less pressure there is overall. Look for the initial quick wins while also building for the long-term. One key thing to remember, per Danilo, when doing DDD for data and data mesh in general: it is always an iterative process. Andrew briefly discussed a way to do DDD in more of a guerilla style than the blue/red books (well known DDD guides). Don't get ahead of yourself as Max Schultze mentioned in his episode. Do not let the size of the eventual task throw you into analysis paralysis. Andrew talked a lot about how normalization and strong abstractions on the application side make it very difficult to re-add the context lost when you normalize. Both Andrew and Danilo talked about the need to embrace complexity. If you want context, you have to accept there will be complexity. In the pursuit of simplification, you lose the richness, and that is VERY hard to reconstruct afterwards. Some practical advice for boundary definition is that the boundaries need to be very clear but malleable. Build everything with an eye that it will evolve. Before you start splitting into many 2 pizza teams, look at the big picture and select some coarse-grained boundaries. It is MUCH easier to split later than it is to glue things back together. Danilo's Webinar with Zhamak called "Data mesh and domain ownership": https://www.thoughtworks.com/en-us/about-us/events/webinars/core-principles-of-data-mesh/data-mesh-and-domain-ownership (https://www.thoughtworks.com/en-us/about-us/events/webinars/core-principles-of-data-mesh/data-mesh-and-domain-ownership) Vladik Khononov, 7 Years of DDD: https://www.youtube.com/watch?v=h_HjtYAH0AI (https://www.youtube.com/watch?v=h_HjtYAH0AI) Danilo LinkedIn: https://www.linkedin.com/in/danilosato/ (https://www.linkedin.com/in/danilosato/) Danilo Twitter: @dtsato / https://twitter.com/dtsato (https://twitter.com/dtsato) Andrew LinkedIn: https://www.linkedin.com/in/andrewharmellaw/ (https://www.linkedin.com/in/andrewharmellaw/) Andrew Twitter: @al94781 / https://twitter.com/al94781 (https://twitter.com/al94781) Data Mesh Radio is hosted by Scott Hirleman. If you want to connect with Scott, reach out to him at community at datameshlearning.com or on LinkedIn: https://www.linkedin.com/in/scotthirleman/ (https://www.linkedin.com/in/scotthirleman/) If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/ (https://datameshlearning.com/community/) If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see https://docs.google.com/document/d/1WkXLhSH7mnbjfTChD0uuYeIF5Tj0UBLUP4Jvl20Ym10/edit?usp=sharing (here) All music used this episode created by Lesfm (intro includes slight edits by Scott Hirleman): https://pixabay.com/users/lesfm-22579021/...

“It's great if developers have understanding about the domain, because then they can propose better solutions, that's not necessarily the same solution that the users have in mind, which are often limited by what they know." Stefan Hofer is the co-author of Domain Storytelling–a collaborative, visual and agile way to build domain-driven software. In this episode, Stefan shared the story of how he came up with Domain Storytelling and explained how this technique can help us understand business domain better and bridge the misunderstandings between software developers and domain experts. Stefan walked us through how the modeling works, including the notations and other pictorial aspects of it, and emphasized the importance of the collaborative aspect of Domain Storytelling. Stefan then explained how Domain Storytelling differs from other similar modeling techniques, such as Event Storming, and gave practical tips on how to run a successful online collaborative workshop. Listen out for: Career Journey - [00:05:51] How Domain Storytelling Started - [00:07:01] Misunderstandings are Common Problems - [00:09:52] Importance of Understanding Domain - [00:12:08] Domain Storytelling - [00:13:46] The DDD Angle- [00:19:01] When Domain Expert is Unavailable - [00:20:34] Domain Storytelling Tools - [00:22:59] Pictographic Language - [00:25:51] Translating into Software - [00:30:23] Difference with Event Storming - [00:33:24] Online Collaborative Workshop - [00:38:00] 3 Tech Lead Wisdom - [00:43:13] _____ Stefan Hofer's Bio Stefan Hofer is bad at drawing. However, he thinks he can build up domain knowledge by drawing domain stories. Stefan studied software engineering in Austria and earned a PhD in computer science. Since 2005, he has been working for WPS – Workplace Solutions in Hamburg, Germany. His job there is to help teams develop software that does the right job the right way. He maintains domainstorytelling.org. Follow Stefan: Twitter – @hofstef LinkedIn – https://www.linkedin.com/in/hofstef/ Website – https://domainstorytelling.org/ Egon.io – http://egon.io/ Our Sponsor Today's episode is proudly sponsored by Skills Matter, the global community and events platform for software professionals. Skills Matter is an easier way for technologists to grow their careers by connecting you and your peers with the best-in-class tech industry experts and communities. You get on-demand access to their latest content, thought leadership insights as well as the exciting schedule of tech events running across all time zones. Head on over to skillsmatter.com to become part of the tech community that matters most to you - it's free to join and easy to keep up with the latest tech trends. Like this episode? Subscribe on your favorite podcast app and submit your feedback. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/75.

Neste episódio Lula conversa com Ana Carolina Lima (UX designer at Taller Digital Business), Sebastian Ferrari (CTO & Co-Founder of Taller) e Alice David Dos Santos (Software Developer) para falar sobre Event Storming! Aperte o play e bora! Em breve as referências deste episódio estarão no backstage do Love The Problem: http://k21.link/lovetheproblem Ah, segue a gente no Instagram também: https://www.instagram.com/lovetheproblem/

Marco Heimeshoff ist Trainer, Redner und Softwareentwickler. Er organisiert KanDDDinsky, eine Konferenz über Domain-driven Design und die Kunst von Business Software und ist Mitbegründer der deutschen DDD-Community und von VirtualDDD.com. Zwischen der Beratung von Unternehmen rund um den Globus und seinem normalen Job in der Entwicklung von Software für das Gesundheitswesen findet man ihn auf Konferenzen, auf denen er über DDD, sozio-technische Systeme und First Principles spricht. Mit mehr als einem Jahrzehnt Erfahrung hilft er Teams dabei, sich zu verändern und zu lernen – vom Code bis zur Kultur – und dabei, Domain-Driven Design, agile Softwareentwicklung, funktionale Programmierung und CQRS mit Event-Sourcing zu meistern.

Do all members of your team share equal time in the spotlight? Or do your developers seems to be marginalized when credit is given to the team? On this episode, Serge Dibao, Engagement Lead at Red Hat Open Innovation Labs, hits us with a thought-provoking episode centered on Developer Empathy. You learn what Dev Empathy is, why it's important, and how to be more intentional about it in your day-to-day product delivery. For this and other awesome team practices, check out the Open Practice Library for yourself! openpracticelibrary.com

In this episode I continued my conversation with Alberto Brandolini, the creator of Event Storming and the author of Introducing EventStorming – An act of deliberate collective learning and the Founder of Avanscoperta, a technology consultancy. He is also the founder of the Italian Domain-Driven Design community.  Alberto has been working as a software developer and architect for many years, but in recent years he has been consulting many companies helping them to adapt collaborative thinking and modeling. He leads workshops, which involve various departments of an organization to find the fastest and best ways of deciding on domain models and designing systems. Currently, these workshops are held virtually due to the global pandemic.  He has also been a keynote speaker in many technology and software-related conferences around the world in the past years. However, currently due to the pandemic he is not participating in as many events. We discussed many challenges and benefits of holding these workshops and talks online. This talk is divided into two sessions, and I hope you enjoy it!   To learn more about Alberto's workshops and upcoming events please visit his website. You can connect with Alberto on Twitter @ziobrando and on LinkedIn. Connect with me on Twitter @SaraTorrey and on LinkedIn.  For more information about us visit axoniq.io

In this episode, I spoke with Alberto Brandolini, the creator of Event Storming and the author of Introducing EventStorming – An act of deliberate collective learning and the Founder of Avanscoperta, a technology consultancy. He is also the founder of the Italian Domain-Driven Design community.  Alberto has been working as a software developer and architect for many years, but in recent years he has been consulting many companies helping them to adapt collaborative thinking and modeling. He leads workshops, which involve various departments of an organization to find the fastest and best ways of deciding on domain models and designing systems. Currently, these workshops are held virtually due to the global pandemic.  He has also been a keynote speaker in many technology and software-related conferences around the world in the past years. However, currently due to the pandemic he is not participating in as many events. We discussed many challenges and benefits of holding these workshops and talks online. This talk is divided into two sessions, and I hope you enjoy it!   To learn more about Alberto's workshops and upcoming events please visit his website. You can connect with Alberto on Twitter @ziobrando and on LinkedIn. Connect with me on Twitter @SaraTorrey and on LinkedIn.

Czym zajmuje się Team Leader w Allegro? Jak wygląda cykl życia oprogramowania w zespole produktowym? Jaka jest rola inżyniera oprogramowania w rozwoju produktu? W jaki sposób wykorzystujemy w Allegro Event Storming? Jakich technologii używają programiści w zespołach produktowych?Między innymi o tym opowie Michał Bareja, Team Manager w Allegro, w rozmowie z Piotrem Betkierem. Linki do materiałów:Prezentacja Macieja Szarlińskiego o Event Stormingu >>>Service Mesh w Allegro >>>  Wyszukiwarka w Allegro >>> Architektura Heksagonalna >>>Michał jest liderem zespołu developerskiego w obszarze Delivery Experience. Wielki fan Domain-Driven Design, Test-Driven Development'u, Pair Programming'u, Event Storming'u i metodyk zwinnych. Przez większość swojej kariery pracował w software house'ach. Po dołączeniu do Allegro odkrył, że rozwój produktów to znacznie więcej niż tylko pisanie kodu.Michał is a Development Team Leader in the Delivery Experience area. Huge fan of Domain-Driven Design, Test-Driven Development, Pair Programming, Event Storming and Agile methodologies. Worked in software houses through most of his career. After joining Allegro, he discovered that product development means a lot more than just writing code.

Diese Woche ist Nicole Rauch zu Gast. Mit Event Storming kann man Domain-driven Design ganz praktisch und kollaborativ umsetzen. Und Specification by Example stellt sicher, dass man auch das richtige baut. Buch-Tipp: Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing von Gojko Adzic

In this episode I talked with Adam Dymitruk, the creator of Event Modeling. Listen until the end for a great surprise, Adam has for you all. In this episode Adam and I discussed: the entire process of Event Modeling with some examples and details the ideas behind the concept of Event Modeling some of the differences between Event Storming and Event Modeling Event Modeling storyline and swimlanes The importance of UI/UX  Patterns - Scenes of a Movie Components of Event Modeling Input/Output States Limitations Given-When-Then State Change and State View Translation Patterns Automation Cost and Agile Programming Blueprint We then talked about some of the activities that are keeping him busy, within the next few months: A 40-Hour Virtual Workshop, His Book and Teaching Event Modeling at the University of Victoria Also here is a list of some great resources:  Adam's Website His Blog "Event Modeling: What is it?" Event Modeling Slack Channel and Intro Videos Adam's presentation at AxonIQ's virtual Conference  The Event-Driven Meetup Sara's Blog Series "From Model to Code" Adam and I are both very active on Twitter: @adymitruk @SaraTorrey For more information about AxonIQ, please visit us at axoniq.io or visit our Events page

Dans cet épisode, Audrey et Emmanuel interviewent Thomas Pierrain et Bruno Boucard pour nous parler d’Event Storming. Enregistré le 30 avril 2020 Téléchargement de l’épisode LesCastCodeurs-Episode–233.mp3 Interview Ta vie, ton œuvre Thomas Pierrain Organisateur du meetup #DDDFR, co-fondateur de 42skillz, Thomas est un eXtreme Programmer & architecte technique obsédé par les usages (vs. l’approche orienté solution). Bruno Boucard possède une expérience de plus de 30 ans allant de la programmation kernel à la gestion de projets en mode eXtreme Programming. Actuellement, il est coach technique, mais aussi speaker international. Il est co-fondateur de la société 42skillz et l’organisateur du meetup BDD Paris. Event storming en 2 mins C’est quoi en deux minutes Ça sert à quoi Qui l’utilise ? (communautés, boites etc) L’event storming en pratique Comment ça se déroule ? Qui vient a ce workshop ? Combien de temps ? L’utilité et le Retour d’expérience Retour dans des boîtes classiques Les points intéressants que cela peut soulever Autour de l’event storming Comment on code ensuite ? Event storming en continu ? ou c’est un évènement unique ? Son lien avec DDD, event sourcing ? Lien avec les Microservices ? Resources pour aller plus loin Le livre d’Alberto Brandolini Article de blog de Thomas Pierrain L’après midi du DDD épisode 2 Nous contacter Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/

Event Storming pomaga skomunikować zespół techniczny i część biznesową. Dzięki pewnym założeniom możemy opisać występujące procesy tak, aby obie strony w pełni je rozumiały. Tablica, kolorowe karteczki – czy to pomysł na rozwiązywanie problemów komunikacyjnych? No i inne pytanie, które coraz częściej sobie zadajemy jako świadomi programiści…Kiedy Event Storming przyniesie nam wartość?O podstawach Event Storming, Mariusz bardzo dużo opowiedział w podcaście Maćka Aniserowicza – DevTalk #110. Zachęcam do jego przesłuchania, bo tam usłyszycie o świetnie omówionych podstawach.My natomiast skupiliśmy na dalszych rozważaniach. Jakie wartości jako programiści możemy wyciągnąć z sesji Event Stormingowej, co może być artefaktem takie sesji oraz kiedy ES się nie sprawdza.Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem:➡️ Czy spotkałeś się wcześniej z Event Stormingiem?➡️ Czy miałeś okazję wypróbować w praktyce sesje Event Storming?➡️ Jeśli tak, to czy spełniła wasze oczekiwania?Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję

On this episode, we sit down with Red Hat Open Innovation Labs Senior Architect Patrick Carney to dive into Event Storming as way to align teams on a common understanding of the system they're building. Check out the Open Practice Library for yourself! openpracticelibrary.com ===== Event Storming: https://openpracticelibrary.com/practice/event-storming/ Cheetah facts: https://cheetah.org/learn/resource-library/ Value Slicing & User Story Mapping: https://openpracticelibrary.com/practice/user-story-mapping/ Autonomous Cheetah: https://www.cnn.com/2015/06/24/tech/mit-robotic-cheetah-darpa/index.html ===== Hit us up on Twitter: @practicelibrary Connect with Patrick LinkedIn: https://www.linkedin.com/in/patrick-s-carney/ Connect with Matt LinkedIn: https://www.linkedin.com/in/matttakane Twitter: @matt_takane Connect with Jerry LinkedIn: https://www.linkedin.com/in/jerry-becker Twitter: @jerryjokesalot Follow Open Practice Library Instagram: @OpenPracticeLibrary If you're liking this podcast so far, please review us on your fav podcast platform

Domain-driven design (DDD) is helpful for managing complex processes and rules—especially those between business experts and developers/users—and turning them into models. CEO of Virtual Genius Paul Rayner describes how the vast tooling in DDD enables developers to focus on the coding that really matters and makes systems more collaborative, taking into account three primary considerations: (1) how to get better at collaborating, (2) strategic design and understanding why design really matters, and (3) modeling codes. He also touches on bounded context, microservices, event storming, event sourcing, and the relationship between Apache Kafka® and DDD. EPISODE LINKSWhat is Domain-Driven Design?Microservices, Apache Kafka, and Domain-Driven DesignTurning the Database Inside Out with Apache SamzaLet’s Build “eBay” by “Turning the Database Inside Out” and Using ServerlessDesigning Event-Driven SystemsDesign Patterns: Elements of Reusable Object-Oriented SoftwareThe Event Storming HandbookRefactoring: Improving the Design of Existing CodeExplore DDD ConferenceJoin the Confluent Community Slack

Leggi il Magazine AgileItalia su https://agileitalia.agileforitaly.com

EventStorming tworzy przestrzeń do dyskusji nad projektami, z perspektywy wiedzy technicznej i oczekiwań biznesu. Potrafi znacząco usprawnić projekty, a nawet zablokować te, które nie mają racji bytu. Dobrze przeprowadzony ES wymaga dobrego przygotowania i obeznania w umiejętnościach miękkich. Jak już wielokrotnie mówiliśmy w DevTalku, samo klepanie kodu już nie wystarcza! Nasz dzisiejszy gość jest mocno […] The post DevTalk #110 – O Event Storming z Mariuszem Gil appeared first on DevTalk.

Dziś trochę o narzędziach dla architekta. Będzie o MindMap, Event Storming, Eisenhower box, Pareto, MoSCoW, SWOT, C4!Ciekawe linki i inne znaleziska z tego odcinka: Mirantis Acquires Docker Enterprise Mind Map Priorytet czy priorytety? Eisenhower Box Zasada Pareta Vilfredo Pareto Metoda MoSCoW Technika MoSCoW Moscow – czyli jak nadać znaczenie wymaganiom w projekcie Analiza SWOT The C4 model for visualising software architecture

A Conversation with Kenny Bass-Schwegler and Alberto Brandolini about the power of Event StormingSupport the show (https://www.agilealliance.org/membership-benefits/)

How can sticky notes help you and your team find and resolve problems which are deeply hidden within your business model? How can this quest through colorful papers accelerate the mending of a legacy code which supports that business model? Today we speak with Alberto Brandolini, an inventor of Event Storming, about how this fun and rapid group modeling technique can accelerate learning and productivity within your development team. From upgrading and improving the existing systems to developing new ones, Alberto’s Event Storming helps teams visualize every little wheel of complex machinery they are tasked to maintain or create. When you finish listening to the episode, make sure to visit Alberto’s website and to check out his nearly finished book.

A conversation about Software Engineering, the German-German border, Event Storming, and the role of language in Project Management and Programming. Robert Reppel, CTO of TwoTonic Labs.

Arnaud et Emmanuel bravent les chaleurs pour discuter des tendances Java, des collections immuables (d’où le titre de l’épisode, une citation d’Alan Watts), de sondage de la population de développeurs, d’event storming, de lois et de data structures. Enregistré le 31 juillet 2019 Téléchargement de l’épisode LesCastCodeurs-Episode–215.mp3 News Langages Rapport sur les tendances Java par InfoQ Collections immuables en Java : ni maintenant, ni jamais Yaegi : un nouveau compilateur pour Go Zulu 8 inclut maintenant le support de TLS 1.3, permettant aux applications Java 8 (serveurs, clients, peu importe) de négocier automatiquement TLS 1.3 sans modification du code. Ajoutez simplement -XX:+UseOpenJSSE Sondage L’état des développeurs: sondage JetBrains2019 Langage Java le langage principal pour 34% (JavaScript 40%) mais leseul langage pour 44% de ceux ci OS de dev: Windows un peu en tête mais sinon égal polyglot Apps Backend 60% / front 46%) Mobile 23% data analysis (13%) / ML (7%) ne developpe pas (13%) polyapp OpenSource 56% contribuent à l’open source dont 37% plusieurs fois par an ou plus Tests aucun (16%) Mobile 83% font de l’Android et 59% iOS Frameworks cross-platforms 42: react native, 30 flutter, 29: cordova, 28 Ionic Outils 9% IDE cloud 10% code review 44% issue tracker (Excel sinon?) moi j’ai besoin gestion soirce, issue tracker, ide au minimum) 83% dark theme Fun 33% de chiens, 26% cats, 23% les deux, 17% sans ; 1% autre (alligator?) Code le week end 87% AI replace devs 6% oui completement, 57% partiellement Demographique du sondage 70% employee temps plein, 6% employeir, 6% freelance, 1% retraite La societe 10% opensource 61% produit 47% dev interne taille de l’equipe 2–7: 51% 8–12 21% methodo agile 40% scrum, 11% kanban, 3% XP, 32% programming mother fucker (none) Ecosystème Java Version: 11: 22%, 10 et 9: 13–14%, 8: 83%, Quel app serveur: 66% tomcat, 21% jetty, 5%: WL, WS, Wildfly, JBoss EAP, Glassfish, 23% aucun si aucun, quoi? SB 61%, netty 12% Spark Java 6%, vert.x 4%, undertow 3% embedded 62% , war: 53% Web framework: Spring Boot 56% (ca fait peur, comme Google == internet), Spring MVC 43% build system Maven 70%, gradle 53%, ant 13% latest Java EE 39% Scala versions 2.13: 20% 2.12: 68%, 2/11: 36% sinon 73% utilisent Java 8, 28% java 11 unit test Scalatest 77%, JUnit 26% 10% whitebox macros, 60% n’utilisent pas les macros web framework akka-http: 39% Play 38% Spring 17% libraries Akka 55% Spark 40% build system 71% sbt 39% maven 18% gradle Kotlin target: Android: 66% JVM 57% native 8% JDK 11: 25% 10–9: 11–14% 8: 80% Android: 74% Pie 9 79% 8 Oreo, sous 50% à la 4 KitKat type of app: mobile: 62%, web abckend 41%, libraries 29% 71% pour travail, 69% maison autres langages 86% Java Databases usage MySQL 60%, PostgreSQL 32%, MongoDB 30%, Rediis 27% Oracle dB 16% ??? Frameworks Quarkus 0.19 avec acces MongoDB, Neo4j, AWS DynamoDB et Apache Tika Middleware Elastic Cloud on Kubernetes (ECK) 0.9.0 Alpha 2 Cloud Kubernetes est maintenant disponible sur CloudFoundry Data Micronaut Predator est sorti et renommé Outillage Importer les rapports Jacoco au format XML dans SonarQube Netbeans 11.1, la première release ASF en tant que toplevel project Méthodologies Event Storming, une description Sécurité Jouez avec les adresses IPs Zoom Zero Day NoLimitSecu - Hors Série – Episode 1 – Histoire du droit du numérique Loi, société et organisation Le code source de l’ordinateur de guidage de module lunaire et du module de commande d’Apollon 11 open sourcé sur GitHub Quand GitHub applique la legislation US et bloque brutalement les utilisateurs d’Iran et autres pays sous sanction (Et avec moins d’affectif). Des projets comme Nuxt.js impactés L’Assemblée nationale adopte la loi sur la cyberhaine Facebook écope d’une amende historique de 5 milliards de dollars et repense son fonctionnement Taxe française sur les géants du net : 9 questions pour tout comprendre La France a adopté la “loi Huawei” au grand dam des opérateurs télécoms Handicap : les grandes entreprises vont devoir rendre accessibles leurs sites et applis Qu’est ce qui se passerait si tous vos canaux Slack fuitaient ? Travail en remote : ce qu’il faut savoir avant de se lancer ! En vrac par Tristan Nitot Outils de l’épisode Twitter : cette extension Chrome et Firefox permet de revenir à l’ancienne version Rubrique débutant Les data structures, les objects et un un peu d’énervement sur les ORMs An Object is a set of functions that operate upon implied data elements. A Data Structure is a set of data elements operated upon by implied functions Conférences JugSummerCamp le 13 septembre 2019. DevFest Toulouse le 3 octobre 2019. Neo4j Online Developer Expo and Summit (NODES) le 10 octobre 2019. KOTLIN/EverywhereParis le 19 octobre 2019. DevFest Nantes les 21 et 22 octobre 2019. Voxxed Microservices 21 au 23 octobre 2019. ScalaIO du 29 au 31 octobre a Lyon. Thème programmation fonctionelle. Devoxx Belgique du 4 au 8 novembre 2019 Bdx.io le 15 novembre 2019. DevOps D-Day les 13 et 14 novembre 2019 - Le CfP est ouvert. Codeurs en Seine le 21 novembre 2019 Nous contacter Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/  

Zapraszam serdecznie do odsłuchania dziewiątego odcinka drugiego sezonu DevTalk Trio. Jak zwykle, przy mikrofonach: Maciej Aniserowicz, Andrzej Krzywda i Sławomir Sobótka. Kontynuujemy tematy poruszone w poprzednich odcinkach. Drugi sezon DevTalk Trio nie mógłby powstać bez pomocy firmy Lingaro. Firma specjalizuje się w rozwiązaniach z obszarów Business Intelligence, Hurtowni Danych i Big Data. Klientami Lingaro są […] The post DevTalk Trio S02E09 – Co to jest event storming appeared first on DevTalk.

Flexible software usually means well modularized software. Instead of one big ball of code, you want to create components that work together. Dividing up your application into those components has always been a bugbear of design and it's what domain-driven design (DDD) is trying to solve. In this episode, Coté talks with Jakub Pilimon to figure out what DDD is, plus how event storming is used to find domains. Also, outside of Poland, is it "evangelist" or "advocate"?

Flexible software usually means well modularized software. Instead of one big ball of code, you want to create components that work together. Dividing up your application into those components has always been a bugbear of design and it's what domain-driven design (DDD) is trying to solve. In this episode, Coté talks with Jakub Pilimon to figure out what DDD is, plus how event storming is used to find domains. Also, outside of Poland, is it "evangelist" or "advocate"?

Flexible software usually means well modularized software. Instead of one big ball of code, you want to create components that work together. Dividing up your application into those components has always been a bugbear of design and it's what domain-driven design (DDD) is trying to solve. In this episode, Coté talks with Jakub Pilimon to figure out what DDD is, plus how event storming is used to find domains. Also, outside of Poland, is it "evangelist" or "advocate"?

Flexible software usually means well modularized software. Instead of one big ball of code, you want to create components that work together. Dividing up your application into those components has always been a bugbear of design and it's what domain-driven design (DDD) is trying to solve. In this episode, Coté talks with Jakub Pilimon to figure out what DDD is, plus how event storming is used to find domains. Also, outside of Poland, is it "evangelist" or "advocate"?

Flexible software usually means well modularized software. Instead of one big ball of code, you want to create components that work together. Dividing up your application into those components has always been a bugbear of design and it's what domain-driven design (DDD) is trying to solve. In this episode, Coté talks with Jakub Pilimon to figure out what DDD is, plus how event storming is used to find domains. Also, outside of Poland, is it "evangelist" or "advocate"?

This month on the Cucumber podcast, Aslak Hellesøy and Steve Tooke speak to Kenny Baas and Bruno Boucard about the relationship between Domain-Driven Design (DDD) and Behaviour-Driven Development (BDD). While both share many similarities, there isn't a great deal of crossover between the two communities. Our two guests want to change that by demonstrating that both practices and communities have more in common than they may think. ### Show notes [Kenny's article about DDDBDD](http://blog.xebia.com/combining-domain-driven-design-and-behaviour-driven-development/) [Bruno on Twitter](https://twitter.com/brunoboucard)/ [Kenny on Twitter](https://twitter.com/kenny_baas) [DDD conference in Denver, Sept 2018](http://exploreddd.com/) [Event Storming introduction](http://ziobrando.blogspot.com/2013/11/introducing-event-storming.html) [Example Mapping introduction](https://cucumber.io/blog/2015/12/08/example-mapping-introduction) [Kanddinsky Conference, Berlin, October 2018](https://kandddinsky.de/) [Cucumber on Twitter](https://twitter.com/cucumberbdd)

Alex and Drew open the show talking about dog friendly workspaces, Haml, the upcoming inaugural Vancouver Tech Meetup, an open-contribution style company, and go over the upcoming week of Meetups Around Town. Our guests this week are Robert Reppel and Erik Reppel. Robert Reppel is Director of Engineering at Adaptech Solutions and co-host of the DDD/CQRS/ES Meetup and the new Vancouver Tech Meetup. A true Polyglot, Robert has more than 25 years of practical, hands-on experience as a Software and Systems Architect, fixer, aligner, deliverer and explainer of products and projects within all aspects of the software development life cycle. Also joining us is Robert's son Erik Reppel who is working on his B.SEng. at UVIC majoring in Computer Science and has interests in big data and time series events. Erik is also cofounder of launchaco.com a company that instantly searches domain names, social media handles and gives you the means to a custom website in 3 easy steps.

Drew and James open the show quickly with a brief chat but then jump right into meetups. The guest this week is Adam Dymitruk, the Founder and CTO of Adaptech Solutions, organizer of the Git Help and 0-tech meetup, Linux Desktop Meetup, and the DDD/CQRS/ES Practitioners meetup!