สรุปบทความ Decentralized Architecture Needs More Than Autonomy

Photo by Shubham Dhage on Unsplash

จากบทความ Decentralized Architecture Needs More Than Autonomy

ใจความหลัก ๆ คือ นอกจากความเป็น autonomy แล้ว การออกแบบ Architecture ที่เกิดจากการตัดสินใจแบบ Decentralized (เพื่อไม่ให้เกิดคอขวด) จะเวิร์คมากเลยเมื่อเรามี practice ที่ดีทั้งในเรื่อง technical และ culture แล้วก็เรื่อง trust ด้วย ซึ่งจะเกิดขึ้นมาได้จากของพวก ADRs หรือ advice forums ที่คอยค่อย ๆ สร้างขึ้นมาในองค์กร

ต้นตอของบทความนี้มาจากหนังสือ Facilitating Software Architecture ที่ผมกำลังอ่านอยู่ด้วย แล้วก็ชอบที่เค้าบอกว่า

..one where autonomy is earned through shared understanding, not just granted by org charts.

มันถึงจะเกิด decentralized architecture ได้จริง ๆ แล้วก็ decision-making at scale ไม่ใช่ว่าเอาแต่บอกว่าให้ทุกคนมี autonomy แล้วก็ต่างคนต่างไปกันคนละทาง วอดวายแน่นอน ถ้าเราไม่มี shared understanding ที่ตรงกัน

เป้าหมายของ decentralization คือ การตัดสินใจได้ดีอย่างรวดเร็ว โดยมีคนที่เกี่ยวข้องที่เหมาะสมเข้าร่วมด้วย ซึ่งแต่ละคนก็จะต้องรู้บทบาทหน้าที่ของตัวเองให้ชัดเจนด้วยเช่นกัน

ปัญหาในองค์กรที่เห็นคือ เราพยายามจะรวมทุกคนเข้ามาในที่ประชุม และต่างคนต่างก็พยายามออกความคิดเห็นในเรื่องต่าง ๆ ออกทะเลบ้าง เข้าเรื่องบ้าง แต่ผลลัพธ์สุดท้ายคือ ไม่สามารถตัดสินใจอะไรได้สักอย่างตอนจบประชุม แล้วก็ไม่สามารถ scale ได้เลย เพราะพยายามจะทำให้ทุกคนเข้าใจ หรือตอบสนองความต้องการของทุกคน

Without that structure, autonomy becomes a liability.

กระบวนการที่เค้าแนะนำคือ Architecture Advice Process ซึ่งกำหนดไว้ว่า

Anyone can make and take an architectural decision, as long as they:

1. Seek advice from everyone meaningfully affected by the decision
2. Seek advice from experts with relevant experience

และพยายามเน้น transparency over control หลังจากนั้นให้เขียน Architectural Decision Record (ADR) เก็บไว้ ซึ่งสำคัญมาก ๆ ถ้าเราจะไปทาง decentralized teams / architectures เพราะทุก ๆ การตัดสินใจเราสามารถย้อนกลับมาอ่าน แล้วเปลี่ยนแปลงมันได้เสมอ ถ้าบริบทเปลี่ยนไป แล้วที่ผมคิดว่าสำคัญจริง ๆ คือเรื่องเปลี่ยนจาก FOMO ไปเป็น JOMO ถ้าเราไม่เปลี่ยนเรื่องนี้ก็จะกลับเข้าลูปนรกที่กล่าวไว้ด้านบนคือ เราพยายามจะรวมทุกคน และแต่ละคนก็จะพยายามเข้าร่วมตลอดเวลา

แล้วก็นอกจากนี้เราควรจะมี Architecture Advice Forums ไว้ด้วยเช่นเดียวกัน เพื่อ shared context ต่าง ๆ ควรจะเป็น recurring session ที่มีไว้สำหรับ advice เท่านั้น ไม่ใช่เพื่อ approval หรือ consensus

เรื่องพวกนี้จะค่อย ๆ shift จากเรื่อง approval ไปเป็น alignment และจะเปลี่ยนพฤติกรรมของคน และองค์กรไปเรื่อย ๆ ใช้เวลานานแน่นอน แต่เปลี่ยนได้ไหม มั่นใจว่าเปลี่ยนได้ 🙂