มากกว่า 10 ปีในการทำงานในวงการ software ผมได้เห็นทั้งบริษัทหรือนักพัฒนารวมถึงตัวผมเองให้ความสำคัญกับสถาปัตยกรรม software หรือวิธีการแบ่ง component ต่างๆ อย่างใน microservice และผมยังได้สังเกตจากประสบการณ์ส่วนตัวว่า ถึงแม้จะเปลี่ยนไปใช้ microservice แต่ก็ยังพบปัญหาต่างๆ อีกมาก หลังจากที่ผมได้อ่านหนังสือ “team topologies (การออกแบบโครงสร้างทีม)” ก็ได้พบว่าปัญหาต่างๆ ที่พบนั้นไม่ได้เกิดจากเทคโนโลยีหรือการเลือกสถาปัตยกรรมเพียงอย่างเดียว แต่เกิดจากวิธีการแบ่งทีมพัฒนา software อีกด้วย

ในบทความนี้ ผมอยากจะนำเสนอสิ่งที่ผมได้เรียนรู้ หรือได้รับแรงบันดาลใจ จากหนังสือเล่มนี้

Point 0 - team topologies คืออะไร

Team topologies หรือแปลเป็นไทยว่า การออกแบบโครงสร้างทีม นั้น เป็นแนวทางในการจัดโครงสร้างทีมขององค์กรที่ทำหน้าที่ในการพัฒนา software โดยตั้งอยู่บนกฎของคอนเวย์ หรือ Conway’s law (ดูคำอธิบาย Point 1) แนวทางนี้จะเริ่มต้นจากการจัดทีมเป็นสิ่งแรก ซึ่งจากในอดีตที่เรามักจะเริ่มต้นโดยการออกแบบ software architecture ก่อน และทีมจะมี 4 แบบ ได้แก่ ทีมหลัก (stream-aligned) ทีมสำหรับสร้างทีมหลัก (enabling) ทีมดูแลระบบที่มีความซับซ้อน (complicated subsystem) และทีมแพลตฟอร์ม โดยมีรูปแบบการสื่อสารระหว่างทีม 3 แบบ ได้แก่ แบบทำงานร่วมกัน (collaboration) แบบผู้ให้บริการ (x as a service) และแบบผู้สนับสนุน (facilitating)

Point 1 - Conway’s law

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

Point 2 - ทีมควรจะเป็นอย่างไร

ทีมส่วนใหญ่ควรจะเป็น stream-aligned ทีมหรือทีมหลัก ที่มีหน้าที่พัฒนาและดูแล software ให้กับหน่วยงานและลูกค้ากลุ่มหนึ่งๆ โดยทำงานอย่างอิสระและมีประสิทธิภาพสูง โดยทีมจะต้องเป็นเจ้าของและมีสิทธิกับทุกอย่างที่ใช้พัฒนาเพื่อตอบสนองหน่วยงานและลูกค้าของตัวเอง แนวทางนี้อาจจะทำให้ทีมมีงานที่ต้องทำมากเกินไป จึงเป็นที่มาของทีมแพลตฟอร์ม ที่จะเอามาช่วยแบ่งเบาภาระโดยการนำสิ่งที่ทุกๆ ทีมต้องใช้เหมือนๆ กัน เช่น CI/CD หรือเซอร์วิสบางอย่าง ไปทำเป็นแพลตฟอร์มกลางให้ทุกทีมเรียกใช้ และในกรณีที่มี component ที่ต้องการความสามารถพิเศษ เราก็สามารถแยกออกมาเป็นทีมดูแลระบบเฉพาะ (ทีม complicated subsystem) และหากทีมหลักต้องการความรู้ หรือความสามารถบางอย่าง ทีมสำหรับสร้างทีมหลัก ก็จะเข้ามาทำการสอนหรือแนะแนวทางเพื่อให้ทีมหลักมีความรู้ที่ต้องการ

การสื่อสารระหว่างทีมก็มีความสำคัญไม่แพ้กัน และต้องไม่มากหรือน้อยไป การสื่อสารโดยการทำงานร่วมกัน (Collaboration) จะใช้ในกรณีที่ต้องสร้างที่ใหม่ๆ ที่ซับซ้อนหรือไม่เคยมีมาก่อน ซึ่งทีมจะต้องทำงานร่วมกันอย่างใกล้ชิด แต่อาจจะไม่ตลอดไป และเมื่อเวลาผ่านไป software ของเราได้ถูกใช้งานมาระยะหนึ่ง รูปแบบการสื่อสารแบบผู้ให้บริการ (X-as a service) ก็จะถูกนำมาใช้โดยแบ่งเป็นทีมผู้ใช้บริการ และผู้ให้บริการ ตัวอย่างเช่น ทีมหลักเป็นผู้ใช้บริการเซอร์วิสของทีมแพลตฟอร์มที่เป็นผู้ให้บริการ และสุดท้ายการสื่อสารแบบสนับสนุน ก็จะเป็นรูปแบบที่ทีมผู้สร้างจะใช้สื่อสารกับทีมหลัก

Point 3 - ตัวอย่าง: สถาปัตยกรรม software ที่ไม่ตรงกับโครงสร้างทีม

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

Point 4 - การประยุกต์ใช้ Team topologies

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

Point 5 - สิ่งสำคัญที่สุดก็คือความลื่นไหล (flow)

สิ่งสำคัญที่สุดที่เราควรจะทำให้ดีก็คือ การที่เราสามารถสร้างหรือเปลี่ยนแปลง software ตามความต้องการทางธุรกิจได้อย่างลื่นไหล รวดเร็ว และต้นทุนต่ำ ที่เหลือถือว่าเป็นเรื่องรอง ไม่ว่าจะเป็น สถาปัตยกรรม กระบวนการทำงาน เครื่องมือ หรือการจัดการ สิ่งเหล่านี้จะเป็นเพียงตัวช่วยที่ทำให้เราบรรลุความลื่นไหล หรือ flow ไปกับธุรกิจได้ ตัวอย่างเช่น เราอาจจะเป็นบริษัทเปิดใหม่ ที่มีคนไม่มากนัก การที่เราใช้ microservice อาจจะเป็นการสร้างภาระงานให้กับทีมที่จะต้องดูแลเซอร์วิสจำนวนมากในพร้อมๆ กัน และเป็นการยากกับทีมในการที่จะสร้างงานที่มีคุณภาพและตอบสนองความต้องการลูกค้าได้ดี การใช้สถาปัตยกรรมแบบ monolithic อาจจะเป็นแนวทางที่เหมาะสมกว่าก็เป็นได้ในกรณีนี้

Point 6 - อีกมุมมองของตำแหน่ง software architect

Team topologies ยังได้ให้มุมมองกับผมเกี่ยวกับตำแหน่ง architect ปัญหาที่ผมเห็นบ่อยๆ เกี่ยวกับตำแหน่งนี้คือ การออกแรงอย่างมากในการสร้างต้นแบบของ software ที่ต้องการและเก็บเป็นเอกสารไว้สักที่และหวังให้ผู้พัฒนาหรือ dev จะมาเห็น ทำความเข้าใจและทำตาม แต่ในความเป็นจริงเกิดขึ้นได้ยาก เหตุผลหนึ่งคือ มันเป็นการยากกับ dev ที่จะต้องทำความเข้าใจและปฎิบัติตาม สิ่งที่ Team topologies แนะนำคือ คนในตำแหน่ง architect นั้นนอกจากที่จะออกแบบโครงสร้าง software แล้ว ควรจะมีหน้าที่ในการออกแบบทีม ที่จะสามารถสร้าง software ตามที่ต้องการเป็นไปได้ หรือให้คนในตำแหน่ง architect อยู่ในทีมสนับสนุน (enabling team) ที่จะคอยทำหน้าที่ให้ความรู้และสอนทีมหลัก เพื่อที่จะสร้าง software ในแบบที่ต้องการได้ สิ่งที่ต่างจากเดิมที่สำคัญคือ ทีมหลักจะต้องมีหน้าที่และสิทธิในการตัดสินใจได้ด้วยตนเองที่จะเปลี่ยนแปลง software ให้ตอบสนองธุรกิจได้ดีที่สุด

สรุป

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