Team Topology Considerations (ข้อพิจารณาด้าน Team Topology)

เช่นเดียวกับที่สถาปนิกไม่ได้พิจารณา data topology สำหรับ orchestration-driven SOA เรื่องเดียวกันนี้ก็เป็น จริงสำหรับ team topology เช่นกัน ซึ่งเป็นหัวข้อที่ยังไม่เป็นที่รู้จักในช่วงที่ architecture style นี้ได้ รับความนิยม

อันที่จริง taxonomy ที่เข้มงวดของ style นี้ทำหน้าที่เป็น communication antipattern ที่ นำไปสู่ การที่สถาปนิกพัฒนาหลักการของ team topology เป้าหมาย ของ architecture นี้คือการแยกความรับผิดชอบอย่างสุดขั้ว พร้อมกับการแยกสมาชิกในทีมที่สอดคล้องกัน ในบรรดา บริษัทที่นำมันมาใช้ แทบไม่มีใครที่สร้าง business service เคยได้พูดคุยกับคนที่สร้าง enterprise service เลย พวกเขาคาดหวังให้สื่อสารกันผ่าน technical artifact เช่น contract และ interface ระดับ abstraction ใน style นี้สร้าง integration layer จำนวนมาก แต่ละ layer ถูก implement โดยทีมที่ต่างกัน และใช้ enterprise-level ticketing tool ในการสื่อสาร มันควรจะเห็นได้ง่ายว่าทำไม developer ถึงรู้สึกว่าการสร้าง feature ใน style นี้กินเวลามาก