Loosely Coupled Organizations (องค์กรที่มีความผูกพันแบบหลวมๆ)

ตลอด ทั้งเล่ม ผมได้เสนอเหตุผลสนับสนุนสถาปัตยกรรมแบบ loosely coupled และย้ำว่าการปรับให้สอดคล้องกับทีมที่เป็นอิสระ มีความผูกพันแบบหลวมๆ และเป็น stream-aligned มากขึ้นนั้น น่าจะให้ผลลัพธ์ที่ดีที่สุด การเปลี่ยนไปใช้สถาปัตยกรรมไมโครเซอร์วิสโดยไม่เปลี่ยนโครงสร้างองค์กรไปด้วย จะลดทอนประโยชน์ของไมโครเซอร์วิสลง—คุณอาจต้องจ่ายต้นทุน (ที่ไม่น้อย) สำหรับการเปลี่ยนแปลงสถาปัตยกรรม โดยไม่ได้ผลตอบแทนจากการลงทุนนั้นกลับคืนมา ผมเขียนไว้หลายครั้งเกี่ยวกับความจำเป็นในการลดการประสานงาน (coordination) ระหว่างทีมเพื่อช่วยเร่งความเร็วในการส่งมอบงาน ซึ่งจะทำให้ทีมสามารถตัดสินใจด้วยตัวเองได้มากขึ้น นี่คือแนวคิดที่เราจะสำรวจให้ลึกขึ้นในบทนี้ และเราจะขยายความการเปลี่ยนแปลงด้านองค์กรและพฤติกรรมที่จำเป็นเหล่านี้ แต่ก่อนอื่น ผมคิดว่ามันสำคัญที่จะแชร์วิสัยทัศน์ของผมว่าองค์กรที่มีความผูกพันแบบหลวมๆ นั้นหน้าตาเป็นอย่างไร

ในหนังสือ Accelerate , 1 Nicole Forsgren, Jez Humble และ Gene Kim ได้ศึกษาคุณลักษณะของทีมที่เป็นอิสระและมีความผูกพันแบบหลวมๆ เพื่อทำความเข้าใจให้ดีขึ้นว่าพฤติกรรมแบบไหนสำคัญที่สุดต่อการบรรลุประสิทธิภาพสูงสุด ตามที่ผู้เขียนระบุ สิ่งสำคัญคือทีมสามารถ:

• เปลี่ยนแปลงการออกแบบระบบของตัวเองในระดับใหญ่ได้โดยไม่ต้องขออนุญาตจากคนนอกทีม

• เปลี่ยนแปลงการออกแบบระบบของตัวเองในระดับใหญ่ได้โดยไม่ต้องพึ่งพาทีมอื่นให้เปลี่ยนแปลงระบบของพวกเขา หรือสร้างภาระงานจำนวนมากให้ทีมอื่น

• ทำงานให้เสร็จได้โดยไม่ต้องสื่อสารและประสานงานกับคนนอกทีม

• Deploy และ release ผลิตภัณฑ์หรือบริการของตัวเองได้ตามต้องการ ไม่ว่าจะขึ้นอยู่กับบริการอื่นใดก็ตาม

• ทำ test ส่วนใหญ่ได้ตามต้องการ โดยไม่ต้องพึ่งพา integrated test environment

• ทำ deployment ในช่วงเวลาทำงานปกติได้ โดยแทบไม่มี downtime

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

คุณลักษณะ บางอย่างในนี้ดูเหมือนจะเป็นเรื่องทางเทคนิคมากกว่า—ตัวอย่างเช่น การที่สามารถ deploy ในช่วงเวลาทำงานปกติได้นั้น อาจทำได้ด้วยสถาปัตยกรรมที่รองรับการ deploy แบบ zero-downtime แต่ทั้งหมดนี้แท้จริงแล้วต้องการการเปลี่ยนแปลงด้านพฤติกรรมด้วย เพื่อให้ทีมมีความรู้สึกเป็นเจ้าของระบบของตัวเองอย่างเต็มที่มากขึ้น จำเป็นต้องมีการเปลี่ยนแปลงออกจากการควบคุมแบบรวมศูนย์ รวมถึงวิธีที่การตัดสินใจเชิงสถาปัตยกรรมเกิดขึ้น (เรื่องที่เราจะสำรวจใน Chapter 16 ) โดยพื้นฐานแล้ว การจะบรรลุโครงสร้างองค์กรแบบ loosely coupled ได้นั้น อำนาจและความรับผิดชอบต้องถูก กระจายอำนาจ (decentralized) .

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

ก่อนอื่น เรามาสำรวจความสัมพันธ์ระหว่างองค์กรและสถาปัตยกรรมให้ลึกขึ้นอีกนิดกันก่อน