Conway's Law (กฎของ Conway)

อุตสาหกรรมของเรายังอายุน้อยและดูเหมือนจะปรับเปลี่ยนตัวเองอยู่ตลอดเวลา แต่ถึงกระนั้นก็มี "กฎ" สำคัญไม่กี่ข้อที่ยังคงทนต่อการพิสูจน์ของกาลเวลา ตัวอย่างเช่น กฎของมัวร์ (Moore's law) ที่ระบุว่าความหนาแน่นของทรานซิสเตอร์บนวงจรรวมจะเพิ่มขึ้นเป็นสองเท่าทุกสองปี ซึ่งพิสูจน์แล้วว่าแม่นยำอย่างน่าทึ่ง (แม้ว่าแนวโน้มนี้จะเริ่มช้าลงก็ตาม) อีกกฎหนึ่งที่ผมพบว่าเป็นจริงแทบจะสากล และมีประโยชน์อย่างมากในการทำงานประจำวันของผม ก็คือกฎของ Conway

บทความของ Melvin Conway เรื่อง "How Do Committees Invent?" ซึ่งตีพิมพ์ในนิตยสาร Datamation เมื่อเดือนเมษายน 1968 ได้สังเกตไว้ว่า:

องค์กรใดก็ตามที่ออกแบบระบบ (ในความหมายที่กว้างกว่าแค่ระบบสารสนเทศ) ย่อมสร้างการออกแบบที่มีโครงสร้างเป็นสำเนาของโครงสร้างการสื่อสารขององค์กรนั้นอย่างหลีกเลี่ยงไม่ได้

ข้อความนี้มักถูกอ้างถึงในรูปแบบต่างๆ ในชื่อกฎของ Conway Eric S. Raymond ได้สรุปปรากฏการณ์นี้ไว้ใน The New Hacker's Dictionary (MIT Press) โดยกล่าวว่า "ถ้าคุณมีสี่กลุ่มที่ทำงานเกี่ยวกับ compiler คุณก็จะได้ compiler แบบ 4-pass"

กฎของ Conway แสดงให้เราเห็นว่าองค์กรที่มีความผูกพันแบบหลวมๆ จะนำไปสู่สถาปัตยกรรมที่มีความผูกพันแบบหลวมๆ (และในทางกลับกันก็เช่นกัน) ซึ่งตอกย้ำแนวคิดที่ว่าการหวังจะได้ประโยชน์จากสถาปัตยกรรมไมโครเซอร์วิสแบบ loosely coupled จะเป็นเรื่องยาก ถ้าไม่พิจารณาองค์กรที่สร้างซอฟต์แวร์นั้นไปด้วย

Evidence (หลักฐาน)

เรื่องเล่ากันว่าตอนที่ Melvin Conway ส่งบทความนี้ไปยัง Harvard Business Review นิตยสารดังกล่าวปฏิเสธ โดยอ้างว่าเขายังพิสูจน์ทฤษฎีของตัวเองไม่ได้ ผมเองได้เห็นทฤษฎีของเขาได้รับการพิสูจน์ในหลายสถานการณ์จนยอมรับว่ามันเป็นจริง แต่คุณไม่จำเป็นต้องเชื่อคำพูดของผมเพียงอย่างเดียว เพราะนับตั้งแต่ Conway ส่งบทความต้นฉบับ ก็มีงานวิจัยอีกมากมายในด้านนี้ มีการศึกษาจำนวนไม่น้อยที่สำรวจความสัมพันธ์ระหว่างโครงสร้างองค์กรกับระบบที่พวกเขา สร้างขึ้น

Loosely and tightly coupled organizations (องค์กรแบบผูกพันหลวมๆ และผูกพันแน่น)

ใน "Exploring the Duality Between Product and Organizational Architectures," 2 ผู้เขียนได้ศึกษาระบบซอฟต์แวร์หลายระบบ โดยแบ่งกลุ่มคร่าวๆ ว่าถูกสร้างขึ้นโดย "องค์กรที่มีความผูกพันแบบหลวมๆ (loosely coupled organizations)" หรือ "องค์กรที่มีความผูกพันแบบแน่น (tightly coupled organizations)" สำหรับองค์กรที่มีความผูกพันแบบแน่น ให้นึกถึงบริษัทผลิตภัณฑ์เชิงพาณิชย์ที่มักอยู่ในสถานที่เดียวกันและมีวิสัยทัศน์กับเป้าหมายที่สอดคล้องกันอย่างมาก ในขณะที่องค์กรที่มีความผูกพันแบบหลวมๆ นั้นมีตัวแทนที่ดีคือชุมชนโอเพนซอร์สที่กระจายตัวกัน

ในการศึกษาของพวกเขา ซึ่งจับคู่ผลิตภัณฑ์ที่คล้ายกันจากองค์กรทั้งสองประเภท ผู้เขียนพบว่าองค์กรที่มีความผูกพันแบบหลวมๆ นั้นสร้างระบบที่เป็นโมดูลมากกว่าและมีความ coupled น้อยกว่าจริงๆ ในขณะที่ซอฟต์แวร์ขององค์กรที่มีความผูกพันแบบแน่นกว่านั้นมีความเป็นโมดูลน้อยกว่า

Windows Vista

Microsoft ได้ทำการศึกษาเชิงประจักษ์ 3 โดยดูว่าโครงสร้างองค์กรของตัวเองส่งผลต่อคุณภาพของผลิตภัณฑ์ซอฟต์แวร์ตัวหนึ่งอย่าง Windows Vista อย่างไร โดยเฉพาะอย่างยิ่ง นักวิจัยได้ดูปัจจัยหลายอย่างเพื่อหาว่าคอมโพเนนต์หนึ่งๆ ในระบบมีแนวโน้มจะเกิดข้อผิดพลาดมากน้อยแค่ไหน 4 หลังจากดูตัวชี้วัดหลายตัว รวมถึงตัวชี้วัดคุณภาพซอฟต์แวร์ที่ใช้กันทั่วไปอย่างความซับซ้อนของโค้ด พวกเขาพบว่าตัวชี้วัดที่เกี่ยวข้องกับโครงสร้างองค์กร (เช่น จำนวนวิศวกรที่เคยทำงานกับโค้ดชิ้นหนึ่ง) กลับเป็นตัวชี้วัดที่มีนัยสำคัญทางสถิติมากที่สุด

ดังนั้นนี่คืออีกตัวอย่างหนึ่งที่โครงสร้างองค์กรส่งผลต่อธรรมชาติของระบบที่องค์กรนั้นสร้างขึ้น

Netflix and Amazon

ตัวอย่าง ที่เป็นแบบอย่างชัดเจนที่สุดสองแบบของแนวคิดที่ว่าองค์กรและสถาปัตยกรรมควรสอดคล้องกันก็คือ Amazon และ Netflix ในช่วงแรก Amazon เริ่มเข้าใจถึงประโยชน์ของการให้ทีมเป็นเจ้าของวงจรชีวิตทั้งหมดของระบบที่พวกเขาดูแล บริษัทต้องการให้ทีมเป็นเจ้าของและดูแลระบบที่พวกเขารับผิดชอบ จัดการวงจรชีวิตทั้งหมดด้วยตัวเอง แต่ Amazon ก็รู้ด้วยว่าทีมเล็กสามารถทำงานได้เร็วกว่าทีมใหญ่ นี่นำไปสู่แนวคิดอันโด่งดังอย่าง two-pizza teams ที่ไม่มีทีมไหนควรใหญ่จนพิซซ่าสองถาดเลี้ยงไม่พอ แน่นอนว่านี่ไม่ใช่ตัวชี้วัดที่มีประโยชน์เต็มร้อย—เราไม่มีทางรู้เลยว่ากินพิซซ่ามื้อเที่ยงหรือมื้อเย็น (หรือมื้อเช้า!) หรือพิซซ่าถาดนั้นใหญ่แค่ไหน—แต่แนวคิดโดยรวมก็คือขนาดทีมที่เหมาะสมที่สุดคือ 8-10 คน และทีมนี้ควรเป็นทีมที่ดูแลลูกค้าโดยตรง แรงผลักดันในการมีทีมเล็กที่เป็นเจ้าของวงจรชีวิตทั้งหมดของบริการนี้เอง เป็นเหตุผลสำคัญที่ทำให้ Amazon พัฒนา Amazon Web Services ขึ้นมา บริษัทจำเป็นต้องสร้างเครื่องมือที่ทำให้ทีมของตัวเองสามารถพึ่งพาตัวเองได้

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