Conway’s Law

โครงสร้างของระบบสะท้อนโครงสร้างการสื่อสารขององค์กรที่สร้างมัน

ใจความสำคัญ

Conway’s Law มาจากบทความชื่อ “How Do Committees Invent?” ของ Melvin Conway วิศวกรคอมพิวเตอร์ชาวอเมริกัน เขาเขียนบทความนี้ในปี 1967 และส่งให้ Harvard Business Review พิจารณาก่อน แต่ถูกปฏิเสธเพราะบรรณาธิการเห็นว่าเขา “ยังพิสูจน์วิทยานิพนธ์ของตัวเองไม่ได้” Conway จึงส่งให้นิตยสาร Datamation ซึ่งตีพิมพ์ในฉบับเดือนเมษายน 1968 แทน

ประโยคต้นฉบับของ Conway คือ

“Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

— Melvin Conway, How Do Committees Invent? (1968)

แปลเป็นไทยได้ประมาณว่า “องค์กรที่ออกแบบระบบ (ในความหมายกว้าง) ถูกจำกัดให้ผลิต design ที่เป็นสำเนาของโครงสร้างการสื่อสารในองค์กรนั้น” ตัว Conway เองไม่ได้เรียกข้อสังเกตนี้ว่า “กฎ” (law) — ชื่อ “Conway’s Law” ถูกตั้งขึ้นภายหลังโดย Fred Brooks ในหนังสือ The Mythical Man-Month ซึ่งทำให้แนวคิดนี้เป็นที่รู้จักในวงกว้างกว่าบทความต้นฉบับเสียอีก

ใจความสำคัญที่สุดคือ สถาปัตยกรรมซอฟต์แวร์กับโครงสร้างองค์กรไม่ใช่เรื่องที่เป็นอิสระจากกัน ทีมสื่อสารกันอย่างไร module/บริการ/คอมโพเนนต์ในระบบก็มักถูกแบ่งไปตามรอยต่อการสื่อสารนั้น เพราะการออกแบบ interface ระหว่างส่วนต่าง ๆ ของระบบต้องอาศัยการพูดคุยตกลงกันระหว่างคนที่รับผิดชอบแต่ละส่วน — รอยต่อการสื่อสารที่ยากหรือมีต้นทุนสูง (เช่น อยู่คนละทีม คนละไทม์โซน ต้องผ่านหลายชั้นอนุมัติ) จะกลายเป็นรอยต่อ (interface) ที่หยาบและมี friction ใน code ตามไปด้วย

ความหมายและนัยยะ

ข้อสังเกตนี้บรรยาย ความสอดคล้อง (correspondence) ระหว่างองค์กรกับระบบ มากกว่าจะฟันธงทิศทางเหตุ-ผลเดียว นักวิชาการยังถกกันว่าโครงสร้างองค์กรเป็นตัวกำหนด design ทางเทคนิค หรือ design ทางเทคนิคเป็นตัวกำหนดโครงสร้างองค์กร หรือทั้งสองฝั่งกำหนดกันไปมา (co-evolution) งานวิจัยของ MIT และ Harvard Business School พบว่าองค์กรที่ทีมเชื่อมโยงกันหลวม ๆ (loosely coupled) มักผลิตสินค้าที่ modular กว่าองค์กรที่ทีมเชื่อมโยงกันแน่น และงานศึกษาของ University of Maryland ร่วมกับ Microsoft ก็ยืนยันความสัมพันธ์นี้ด้วยการวิเคราะห์คุณภาพซอฟต์แวร์เชิงประจักษ์

Chris Ford เพื่อนร่วมงานของ Martin Fowler สรุปกลไกเบื้องหลังไว้กระชับว่า “software coupling is enabled and encouraged by human communication” — เมื่อคนสื่อสารกันง่าย code ของพวกเขาก็มักพันกันง่ายตามไปด้วย และในทางกลับกัน ถ้าออกแบบสถาปัตยกรรมขัดกับโครงสร้างองค์กรที่มีอยู่จริง (เช่น อยากได้ระบบ modular แต่ทีมยังรวมศูนย์การตัดสินใจ) ความตึงเครียดจะปรากฏใน code — จุดเชื่อมต่อที่ควรง่ายกลับซับซ้อนขึ้นเรื่อย ๆ เพราะทีมไม่ได้ถูกจัดให้สื่อสารกันตามแนวสถาปัตยกรรมที่ต้องการ

Martin Fowler สรุปว่าองค์กรมีทางเลือกอยู่สามแบบเมื่อเจอกับ Conway’s Law:

เพิกเฉย — แสร้งทำเป็นว่ากฎนี้ไม่มีผล ทั้งที่มันมีผลเสมอ
ยอมรับ — ออกแบบสถาปัตยกรรมให้สอดคล้องกับรูปแบบการสื่อสารของทีมที่มีอยู่
Inverse Conway Maneuver — จัดโครงสร้างทีมใหม่โดยตั้งใจ เพื่อ “บังคับ” ให้สถาปัตยกรรมที่ต้องการเกิดขึ้นตามมา

Inverse Conway Maneuver คือการพลิกทิศทางของกฎ: แทนที่จะปล่อยให้องค์กรที่มีอยู่กำหนดสถาปัตยกรรมโดยไม่ตั้งใจ ก็ออกแบบทีม (ขอบเขตความรับผิดชอบ ช่องทางสื่อสาร รูปแบบ ownership) ให้ตรงกับสถาปัตยกรรมเป้าหมายตั้งแต่แรก คำนี้มีร่องรอยการใช้ตั้งแต่บทความของ Jonny LeRoy และ Matt Simons ใน Cutter IT Journal ปี 2010 และถูกทำให้เป็นที่รู้จักกว้างขึ้นมากผ่านบทความ Microservices (2014) ของ James Lewis กับ Martin Fowler ต่อมาหนังสือ Team Topologies ของ Matthew Skelton และ Manuel Pais (2019) ได้ขยายแนวคิดนี้เป็นกรอบปฏิบัติเต็มรูปแบบ — นิยามรูปแบบทีม 4 แบบ (stream-aligned, enabling, complicated-subsystem, platform) และรูปแบบปฏิสัมพันธ์ระหว่างทีม เพื่อออกแบบองค์กรให้ “ไหล” ไปสู่สถาปัตยกรรมที่ต้องการโดยธรรมชาติ

ตัวอย่างในโลกจริง

การทดลองดั้งเดิมของ Conway (compiler COBOL/ALGOL) — Conway เล่าถึงองค์กรวิจัยตามสัญญาแห่งหนึ่งที่มีคน 8 คน ได้รับมอบหมายให้สร้าง compiler COBOL และ ALGOL หลังประเมินความยากแล้ว มีคน 5 คนถูกจัดไปทำ COBOL และ 3 คนไปทำ ALGOL ผลลัพธ์คือ compiler COBOL ทำงานแบบ 5-phase (5 รอบผ่าน) ส่วน compiler ALGOL ทำงานแบบ 3-phase — จำนวน phase ในตัว compiler สะท้อนจำนวนคนในแต่ละทีมย่อยพอดี เรื่องนี้ภายหลังถูกทำให้ติดหูง่ายขึ้นเป็นมุกตลกในวงการที่ Eric S. Raymond บันทึกไว้ใน The New Hacker’s Dictionary ว่า “ถ้าให้สี่ทีมออกแบบ compiler คุณจะได้ compiler แบบ 4-pass”

Amazon และ “two-pizza teams” — Jeff Bezos วางกฎง่าย ๆ ว่าทีมหนึ่งควรเล็กพอที่พิซซ่าสองถาดเลี้ยงได้ (ราว 7-8 คน) แต่ละทีมเป็นเจ้าของบริการของตัวเองแบบ end-to-end พร้อม API contract ที่ชัดเจนระหว่างทีม ผลลัพธ์ที่ตามมาคือสถาปัตยกรรมของ Amazon กลายเป็น service-oriented / microservices ที่ประกอบด้วยบริการเล็ก ๆ จำนวนมาก ซึ่งสอดคล้องพอดีกับโครงสร้างทีมอิสระขนาดเล็กที่วางไว้ — เป็นตัวอย่างของ Inverse Conway Maneuver ที่ใช้งานจริงและได้ผล

เว็บไซต์องค์กรที่สะท้อนแผนกภายในแทนที่จะสะท้อนผู้ใช้ — นักวิจัยด้าน usability อย่าง Nigel Bevan เคยบันทึกไว้ว่าเว็บไซต์องค์กรจำนวนมากถูกจัดโครงสร้างเมนูตามผังแผนกภายในบริษัท (เช่น “ฝ่ายขาย” “ฝ่ายบริการหลังการขาย” “ฝ่าย IT”) แทนที่จะจัดตามงานที่ผู้ใช้ต้องการทำจริง เป็นตัวอย่างของ Conway’s Law ที่ไม่ได้จำกัดอยู่แค่ซอฟต์แวร์ แต่ลามไปถึงโครงสร้างข้อมูล (information architecture) ใด ๆ ที่หลายทีมช่วยกันสร้าง

บทเรียนที่นำไปใช้

ถ้าอยากได้สถาปัตยกรรมแบบไหน ให้ตั้งทีมแบบนั้นก่อน — การพยายามบังคับให้สถาปัตยกรรม modular เกิดขึ้นในองค์กรที่ยังรวมศูนย์การตัดสินใจ มักจบด้วยระบบที่ “ดูเป็น microservices” แต่ยัง tightly coupled กันภายใน เพราะทีมยังต้องประสานงานกันแน่นเหมือนเดิม
มองรอยต่อการสื่อสารเป็นสัญญาณล่วงหน้าของรอยต่อสถาปัตยกรรม — จุดไหนที่ทีมสองทีมต้องประชุมนัดพิเศษ ขอ sign-off ข้ามทีมบ่อย ๆ หรือสื่อสารผ่านตั๋ว/อีเมลแทนการคุยตรง จุดนั้นมักกลายเป็น interface ที่หยาบและเปราะใน code
ใช้ Common Architectural Vision เป็นเครื่องมือคู่กับกฎนี้ — ทีมที่ share ความเข้าใจสถาปัตยกรรมร่วมกัน (ดู Common Architectural Vision) จะลดโอกาสที่รอยต่อองค์กรกับรอยต่อระบบจะขัดกัน
Bounded Context ควรเดินตามทีม ไม่ใช่ทีมเดินตาม Bounded Context โดยบังเอิญ — ใน DDD การกำหนด Bounded Context และ Context Map อย่างตั้งใจ คือการใช้ Inverse Conway Maneuver ในระดับ domain: ให้ทีมเป็นเจ้าของ context เดียวชัดเจน แทนที่จะปล่อยให้เขตแดน model เลื่อนไหลไปตามใครสื่อสารกับใครในแต่ละวัน
ระวัง class/module ที่ “ทุกทีมแตะ” — code ร่วมที่หลายทีมต้องแก้ไขพร้อมกันมักไม่ได้เกิดจาก design ที่แย่เพียงอย่างเดียว แต่สะท้อนว่าไม่มีทีมไหนเป็นเจ้าของขอบเขตนั้นจริง ๆ ตัวอย่างสมมติ:

// ก่อน: OrderProcessor ถูกแก้โดยทีม Checkout, ทีม Inventory และทีม Billing พร้อมกัน
// เพราะไม่มีขอบเขตความรับผิดชอบที่ชัดเจน -> merge conflict และ deploy ติดกันบ่อย
public class OrderProcessor
{
    public void PlaceOrder(Order order) { /* checkout logic */ }
    public void ReserveStock(Order order) { /* inventory logic */ }
    public void ChargeCustomer(Order order) { /* billing logic */ }
}

// หลัง: แยกตามขอบเขตทีม แต่ละทีมเป็นเจ้าของ service ของตัวเอง
// สื่อสารกันผ่าน contract ที่ชัดเจน สะท้อน Inverse Conway Maneuver
public interface ICheckoutService { void PlaceOrder(Order order); }
public interface IInventoryService { void ReserveStock(Order order); }
public interface IBillingService { void ChargeCustomer(Order order); }

กฎนี้ใช้ได้กับสิ่งที่ไม่ใช่ code ด้วย — เอกสาร ฐานความรู้ เว็บไซต์ หรือแม้แต่ API สาธารณะ ล้วนมีแนวโน้มสะท้อนโครงสร้างองค์กรผู้สร้างเช่นกัน จึงควรตรวจสอบว่าโครงสร้างที่ผู้ใช้ปลายทางเห็นถูกออกแบบเพื่อผู้ใช้ ไม่ใช่เพื่อความสะดวกของแผนกภายใน

flowchart LR
  TeamA[Team A] --> ModuleA[Module A]
  TeamB[Team B] --> ModuleB[Module B]
  TeamC[Team C] --> ModuleC[Module C]
  ModuleA --> ModuleB
  ModuleB --> ModuleC
  TeamA --> TeamB
  TeamB --> TeamC

ที่เกี่ยวข้อง

Brooks’s Law — อีกหนึ่งกฎคลาสสิกเรื่ององค์กรและซอฟต์แวร์ จากหนังสือเล่มเดียวกันที่ตั้งชื่อ Conway’s Law
Bounded Context — การกำหนดขอบเขต model อย่างตั้งใจ คือการใช้ Inverse Conway Maneuver ในระดับ domain
Context Map — เครื่องมือมองความสัมพันธ์ระหว่าง Bounded Context ซึ่งมักสะท้อนความสัมพันธ์ระหว่างทีม
Common Architectural Vision — แนวปฏิบัติที่ช่วยให้ทีมหลายทีมสื่อสารบนความเข้าใจสถาปัตยกรรมร่วมกัน
Whole Team — โครงสร้างทีมที่ครบองค์ประกอบส่งผลต่อรูปแบบการสื่อสารและระบบที่ผลิตออกมา
Separation of Concerns — หลักการแบ่งความรับผิดชอบใน code ที่ควรสอดคล้องกับการแบ่งความรับผิดชอบของทีม

Conway’s Law

ใจความ​สำคัญ

ความหมาย​และ​นัย​ยะ

ตัวอย่าง​ใน​โลก​จริง

บทเรียน​ที่​นำ​ไป​ใช้

ที่​เกี่ยวข้อง

แหล่ง​อ้างอิง

ใจความสำคัญ

ความหมายและนัยยะ

ตัวอย่างในโลกจริง

บทเรียนที่นำไปใช้

ที่เกี่ยวข้อง

แหล่งอ้างอิง