Big Picture EventStorming#

เมื่อผู้บริหารสั่ง “แยก Transfer เป็น 6 services” แต่แต่ละฝ่ายยังเล่า flow ไม่เหมือนกัน การวาด architecture ก่อนมอง business timeline จะตรึงความไม่รู้ไว้ใน network Big Picture EventStorming ชวนคนหลายฝ่ายสร้างภาพร่วมของสิ่งที่เกิดขึ้นจริงตั้งแต่ต้นจนจบ แล้วทำให้ conflict, delay, policy และ opportunity ปรากฏก่อนตัดสิน solution

เป้าหมายคือ Collective Learning#

EventStorming ของ Alberto Brandolini อธิบาย practice นี้ ว่าเป็น flexible workshop สำหรับ collaborative exploration ข้าม business และ technology Big Picture สนใจทั้ง line of business และทำให้ความเห็นต่างอยู่บนพื้นผิวเดียวกัน

Output ไม่ใช่ diagram ที่ “ถูก” แต่คือ:

• shared timeline ที่ทุกฝ่ายแก้ได้
• hotspot ที่ยังไม่มีคำตอบหรือมีหลายคำตอบ
• policy/decision owner ที่ขาด
• bottleneck, rework และ manual intervention
• candidate boundaries และ strategic opportunities ที่ต้องศึกษาเพิ่ม

Frame ก่อนเปิด Board#

ใช้ framing canvas สั้น:

Decision question:
Business line / value stream:
Start event:
End event:
Time horizon:
Perspectives required:
Known constraints:
Out of scope:
What happens after the workshop:

ตัวอย่าง question คือ “ตั้งแต่ Customer ยืนยัน Transfer จนยอดถูก reconcile มี events และ unknown states อะไรบ้าง” ไม่ใช่ “ระบบเรามี services อะไร” เริ่ม/จบกว้างพอให้เห็น handoff แต่เล็กพอเล่าเสร็จ

เชิญ Business owner, Product, Customer Support, Operations, Finance/Accounting, Risk/Compliance, Engineering และ SRE ตาม scope หากมีแต่ managers flow จะขาด workaround หากมีแต่ engineers board จะกลายเป็น log/table names

รอบที่ 1: Domain Events ตามเวลา#

ให้ทุกคนเขียนสิ่งที่เกิดแล้วใน past tense:

Transfer Requested
Beneficiary Confirmed
Eligibility Approved
Funds Reserved
Provider Submission Accepted
Provider Outcome Became Indeterminate
Ledger Entries Posted
Transfer Reconciled
Customer Notified

เริ่ม silent generation แล้วค่อยวางซ้ายไปขวา ไม่อภิปรายคำทุกใบในทันที ให้ timeline กว้างก่อน ถ้ามีคำว่า Transfer Completed ให้ถาม completed สำหรับ Customer, Provider หรือ Ledger และวาง alternatives แยกไว้

System map

นี่คือ Big Picture view: ใช้ events สำรวจเวลาและทางแยกก่อน ยังไม่บอก API, database หรือ message broker และจงใจแสดง indeterminate path เพื่อไม่ให้ timeline กลายเป็น happy path

รอบที่ 2: Failure, Delay และ Manual Work#

happy path ให้ข้อมูลน้อย ให้เติม:

• duplicate request/callback
• provider timeout หรือ late report
• approval หมดอายุก่อน execution
• funds reservation ถูกปล่อยแต่ provider สำเร็จภายหลัง
• beneficiary ถูกแก้หลัง screening
• Operations reconcile แล้วพบ mismatch
• customer complaint เริ่ม manual case

ติด hotspot ที่ policy ขัดกันหรือไม่มี owner อย่าปิดด้วยสมมติฐาน เช่น “คง retry ได้” สำหรับ money movement timeout อาจเป็น unknown และ retry แบบใหม่อาจสร้างผลซ้ำ

รอบที่ 3: Commands, Policies และ Actors#

หลัง event flow พอเห็นแล้ว เพิ่ม:

• Command: intent ที่อาจถูก reject เช่น Confirm Transfer
• Actor: Customer, Operations Agent, Scheduler, Provider
• Policy: เมื่อ event หนึ่งเกิดแล้วต้องตัดสินหรือเริ่ม command ใด
• External System: provider/bank/regulator feed ที่มี semantics ของตน
• Read Model/Information: ข้อมูลที่ actor ต้องเห็นเพื่อเลือก

อย่าแปล sticky ทุกใบเป็น class หรือ message Command/Event เป็น thinking grammar บน board การ publish message เป็น implementation decision ภายหลัง

เมื่อ zoom เข้า Process Level และ Design Level ความสัมพันธ์หนึ่งช่วงอาจขยายเป็น:

System map

คำว่า MODEL ในภาพเป็น Design Level hypothesis ไม่ได้แปลว่า sticky note ต้องกลายเป็น Aggregate ทันที Process Level อาจหยุดที่ Event → Policy → Command ก่อน แล้วค่อยเพิ่ม model/read model/ external system เมื่อคำถามต้องการรายละเอียดนั้น

Pivotal Events และ Hotspots#

Pivotal Event เปลี่ยน phase หรือความรับผิดชอบ เช่น Transfer Confirmed เปลี่ยนจาก draft เป็น committed intent, Execution Became Indeterminate เปิด reconciliation responsibility ใช้ pivotal events เสนอ candidate phases/subdomains แต่ทดสอบด้วย language, policy, lifecycle, ownership และ change pattern เพิ่ม

Hotspot แบ่งได้:

จาก Board สู่การเรียนรู้รอบถัดไป#

ภายใน 24 ชั่วโมงสรุป:

1. narrative ของ 2– 3 journeys
2. glossary conflicts
3. policies พร้อม owner/source status
4. hotspots และ ranked questions
5. candidate subdomains/boundaries พร้อม evidence/alternative
6. workshop ต่อไปหรือ experiment

อย่า export board 300 stickies แล้วถือว่าส่งมอบ Artifact ควรตอบ decision question ที่ตั้งไว้ และระบุสิ่งที่ยังไม่รู้

แบบฝึกปฏิบัติ: Transfer Big Picture#

วาง session 2 ชั่วโมง:

0– 10    Frame scope and notation incrementally
10– 35   Silent event generation
35– 60   Build and narrate the timeline
60– 85   Add failures, delays and manual work
85– 105  Add actors, commands, policies and systems
105– 115 Mark pivotal events and hotspots
115– 120 Owners, next experiments and playback

Deliverable ต้องมีอย่างน้อย 2 competing meanings, 3 failure paths, 2 policy questions, 1 manual repair flow และ candidate boundary 2 ทางเลือก ห้ามมี acceptance ว่า “เลือก Kafka”

รายการตรวจสอบ#

• มี decision question, start/end และ out-of-scope
• participants ครอบคลุมผู้กำหนด policy และผู้ทำ exception จริง
• event timeline มาก่อน system/component diagram
• unhappy, late, duplicate และ manual paths ถูกเล่า
• command/event บน board ไม่ถูกบังคับเป็น message
• pivotal event เป็น hypothesis ไม่ใช่ boundary proof
• ทุก hotspot มี owner หรือ next experiment
• ผลถูกย่อยเป็น artifact ที่ review ได้

อ่านเพิ่มเติม#

• EventStorming Official Site — รูปแบบจากผู้สร้าง
• EventStorming Resources — starter kits และข้อจำกัด
• Incremental Notation — ลด cognitive load ระหว่าง workshop