Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Heuristics for Digital Transformation execution through EventStorming workshop

9b63847a4c413a2604e1d64e5d595dab?s=47 Kim Kao
August 29, 2021

Heuristics for Digital Transformation execution through EventStorming workshop

In this era, it is often treated digital transformation as a business or technology-only topic. Although there are some different viewpoints to combine technologies with business goals, most of the transformations still fail. " Culture eats strategy for breakfast " is usual in every bureaucratic organization. In this talk, Kim Kao would like to tell you how to leverage common heuristics in Agile, DDD, and Eventstorming workshops to do goal alignment, refactor legacy systems to modern applications with business-oriented services. Then, teams with consensus go on the transformation journey.

9b63847a4c413a2604e1d64e5d595dab?s=128

Kim Kao

August 29, 2021
Tweet

Transcript

  1. © 2021, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. academy DevAx 10 Heuristics in running EventStorming Ways to collaborate with customers in building microservices Kim Kao Sr. Solutions Architect AWS
  2. Softball/baseball pitcher Father of 3 – Life is well architected

    Sr. Solutions Architect@Taiwan Co-organizer of DDDesign Taiwan Community Kim Kao
  3. © 2021, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. academy DevAx Outline today • Knowing your customers in goal alignment • What is EventStorming • 10 Heuristics in running EventStorming workshop • Q & A
  4. Digital transformation is not a technology; it is a way

    of thinking and operating -- Drive business grows with modern application
  5. 70% of digital transformation efforts do not reach their goal

    !
  6. None
  7. “Those who do not learn history are doomed to repeat

    it” George Santayana Philosopher, essayist, poet, and novelist
  8. “Culture eats strategy for breakfast (and lunch and dinner)” Attributed

    to Peter Drucker Author and management consultant
  9. CXOs need a different execution model to survive customer expectations

  10. CXOs need a different execution model to survive customer expectations

    Mindset Skillset Toolset
  11. Vision Clarity of vision Skillset Toolset Mindset CXOs need a

    different execution model to survive customer expectations
  12. Increase EBITDA Improve ROIIC by 3% ? ? ? ?

    ? 20,000 restaurants with mobile by year end Close 8 data centers by 2020 You don’t really know what it is ... Skillset Toolset Mindset CXOs need a different execution model to survive customer expectations
  13. Start End Requirements • Goal alignment journey • Knowing different

    perspective from different Business • Multiple function stakeholders engaged • Ubiquitous Language led to the same understanding
  14. © 2021, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. academy DevAx When we need to refactor legacy monoliths to microservices, it is about building automated, operatable, business focused solutions in microservices architecture. MODERN APPLICATIONS OVERVIEW
  15. Patterns for refactoring to microservices Domain-driven design Event decoupling Strangler

    pattern
  16. Events as decouplers Order station Order delivered Subscriber | Order

    station Package order Deliver order Subscriber | Grill station Cheeseburger ordered Subscriber | Fries station Large fry ordered Subscriber | Drink station Lemonade ordered Event Burger ready Event Fries ready Event Drink ready Event Order placed Joe orders burger, fries and drink
  17. • Moving monolithic applications to microservices by gradually creating events

    and APIs for various components of the legacy application The strangler pattern https://martinfowler.com/bliki/StranglerFigApplication.html
  18. • Bounded contexts are used to simplify complex models and

    teams; multiple bounded contexts results in smaller, easier-to-manage components Domain-driven design Opportunity Pipeline Salesperson Product Customer Territory Sales context Ticket Defect Product version Product Customer Support context
  19. © 2021, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. academy DevAx Case reference from BMW group
  20. Many possibilities to configure your car 1 2 3 4

    1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
  21. Base complexity Productivity Monolith Microservice 1 2 3 4 https://martinfowler.com/bliki/MicroservicePremium.html

    The software was divided into small self-contained and independent ”microservices” 4 1 Initial development was fast and focused on the MVP 2 Over time high dependencies developed and the overall complexity increased 3 Development speed became slower and slower; minor changes led to large refactorings Complexity drives change
  22. • Understand the domain • Cut microservices Identify bounded context

    1 • Business object model for each microservice • Learned from the details • Verified / reshaped decision from step 1 Identify business objects 2 • Each business object leads to one or more REST resources • Business object attributes became part of the JSON payload • Followed REST best practices Define API-first 3
  23. © 2021, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. academy DevAx What is EventStorming
  24. “All the key stakeholders in the same room with an

    unlimited modelling space, using stickies as domain events ” ~ Alberto Brandolini Founder, Event Storming
  25. © 2021, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. academy DevAx A fluent way to learn & share in consensus Big picture, process, design
  26. Traditional meeting

  27. Leave space for brain storming

  28. Immutable truth

  29. Events drilling in depth

  30. © 2021, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. academy DevAx 10 Heuristics in running EventStorming workshop
  31. Start with User Story mapping • Big picture modeling •

    Focus on high level flow • Include different stakeholders' viewpoints Ref from : https://medium.com/i-want-to-be-a-product- manager-when-i-grow-up/user-story-mapping-dd7462ee78cf
  32. Write down first Domain event •Write it on an orange

    sticker •One sticker - one event •Use past tense Order Created
  33. User registered User authenticated Shipment fulfilled Goods selected Order placed

    Time Drill down to each process
  34. Seeking for consensus

  35. Explore events Communicate with domain experts, not small group private

    talk only Dig out more details, avoid early abstractions and CRUDish style Focus on Happy path first Everyone can put on more events even though it’s the same one Don’t jump to conclusion without whole process discovering, learn and be curious
  36. Identify any concerned events • Using Red sticky note and

    post with 45-degree rotation • Write down your concern • I don’t understand • Something went wrong • Too hard to do at this stage • Discuss for why, how, what to mitigate the concern or risk • Parking lot is welcome in case questions couldn’t be clarify in time
  37. Using ubiquitous language to explain domain knowledge • Write down

    each specific wording which you never heard of it • Seek for a statement to well present the termination with consensus • Yellow sticky note in used
  38. Where the events come from • By human beings –

    Command • By timeline – Scheduled Job • By Specific event • …when OOO, then XXX immediately • …when OOO, then yyy in acceptable timely Policy
  39. A long running business … Policy

  40. Using a “Process” notation to include the policy period …

  41. Applied from web channel Checked Specific cardType reservation Verified financial

    statement Sent notification Filled up application form LOL co-branded credit card application policy • When entering a policy/process, implicity turns into another boundary (sometimes) • Seek for stakeholders’ input to flesh out entire scenario • Involves automation, non-automation processes • Apply when dealing with complexity branch policies • If success … • If fail …
  42. Flesh out Command, Actor, ReadModel, Rule, External System

  43. Domain model is about behavior and state change, time to

    fill command and logics…
  44. Command & Actor • Command – Present actor’s request or

    intention • Command trigger events • Use blue sticky notes • Actor – A real user/role or a system • Name it with clear definition • Never use “User” only Order Checked Out Check out Order member
  45. Business Rules • Obey couple of Invariant Constraints between Command

    and Event • Business logics, rules of the system Order Checke d Out Check out Order member • Support Credit card only after 18:00 • Max items for 10 in 1 order
  46. Aggregate • Owns responsibility to fulfill commands, • It’s all

    about capability
  47. Aggregate naming • At first, it looks like a black-box

    • Accept or reject commands with business intention • Provide capability to fulfill the intention • Generate the immutable truth, which is the business (domain) event
  48. “ Aggregate “ • Coherent Business Model • Command-Aggregate-Event •

    Work as State Machines, or Independent Components • Come with Biz Rules • Break the Timeline • Look for Behavior & Responsibilities Instead of Data • Postpone Aggregate Naming Invariants contraints
  49. Bounded Context

  50. Bounded Context at EventStorming • Using a pivot line swimlane

    to explict express different concept boundary • Sometimes the “POLICY” takes place • Each divided segment potentially could be a bounded context candidate • Focus on the flow relationships among each segment, realize how it interact with each other C1 Microservice Candidate 1 Microservice Candiate 2 Microservice Candidate 3
  51. Design Level – Wrap it up Service Service Anemic Model

    Domain Model Applying DDD Tactical Pattern All patterns, not partial • Responsible for loigc implementation • Manipulate model, persist to data store • Status only • Invoke Domain model methods • Keep & represent status • Provide business capability in methods
  52. Vision Take away

  53. © 2021, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. academy DevAx Q & A