Architecture and Team Topologies (สถาปัตยกรรมกับ Team Topologies)

ดังที่เราได้กล่าวถึงตลอด Part II ของหนังสือเล่มนี้ team topology สามารถส่งผลกระทบโดยตรงต่อสถาปัตยกรรมซอฟต์แวร์ และในทางกลับกันก็เช่นกัน ความสอดคล้องนี้สำคัญมากจนเราได้รวมส่วนเกี่ยวกับ team topology ไว้สำหรับ architecture style แต่ละแบบที่เรานำเสนอในหนังสือเล่มนี้

หนึ่งในวิธีพื้นฐานที่สุดที่ team topology สอดคล้องกับสถาปัตยกรรมคือประเภทของการแบ่งส่วน (partitioning) เช่นเดียวกับสถาปัตยกรรม ทีมสามารถแบ่งตาม domain หรือแบ่งตามเทคนิค ทีมที่แบ่งตาม domain (domain-partitioned) จัดระเบียบตามพื้นที่ domain และมักเป็น cross-functional โดยมีความเชี่ยวชาญกระจายทั่วทั้งทีม ตัวอย่างเช่น ทีมที่แบ่งตาม domain ทีมหนึ่งอาจมุ่งเน้นส่วนที่ลูกค้าเห็นของระบบ และรับผิดชอบการประมวลผลแบบ end-to-end ของ functionality ที่เกี่ยวข้องกับลูกค้า ตั้งแต่ UI ไปจนถึง database ในทางกลับกัน ทีมที่แบ่งตามเทคนิค (technically partitioned) แต่ละทีมจะมุ่งเน้น technical function เฉพาะด้านหนึ่งของสถาปัตยกรรม และมักจัดระเบียบตามหมวดหมู่ทางเทคนิค เช่น ทีม UI, ทีม backend-processing, ทีม shared-services และทีม database ซึ่งจะสอดคล้องกับ layered architecture style ได้ดีมาก อีกทางหนึ่ง ทีมเหล่านี้อาจแบ่งตามเทคนิคเป็นทีม business-function และทีม data-synchronization ซึ่งจะสอดคล้องกับ space-based architectural style ได้ดี

การเข้าใจว่าทีมถูกจัดระเบียบอย่างไรเป็นสิ่งสำคัญยิ่งต่อความสำเร็จของระบบ หาก team topology ขององค์กรไม่สอดคล้องกับสถาปัตยกรรม ทีมจะประสบปัญหาในการ implement และดูแลรักษาสถาปัตยกรรม ซึ่งจะทำให้ไม่น่าจะบรรลุเป้าหมายทางธุรกิจได้