Architecture in a Stream-Aligned Organization (สถาปัตยกรรมในองค์กรแบบ Stream-Aligned)

ใน Chapter 15 เรา ได้ดูว่าองค์กรส่งมอบซอฟต์แวร์สมัยใหม่กำลังเปลี่ยนไปสู่โมเดล stream-aligned มากขึ้นอย่างไร โดยที่ทีมอิสระที่พึ่งพาตัวเองโฟกัสไปที่การส่งมอบฟังก์ชันการทำงานแบบ end-to-end ด้วยลำดับความสำคัญที่ขับเคลื่อนโดยผลิตภัณฑ์ เรายังพูดถึง cross-cutting team ด้วย นั่นคือ enabling teams ที่สนับสนุน stream-aligned team แล้วสถาปนิกจะเข้ามาอยู่ตรงไหนในโลกแบบนี้ บางครั้งขอบเขตของ stream-aligned team หนึ่งก็ซับซ้อนพอที่จะต้องมีสถาปนิกเฉพาะ (ตรงนี้เราก็เห็นเส้นแบ่งระหว่างบทบาท technical lead แบบดั้งเดิมกับสถาปนิกเลือนลางอีกครั้ง) แต่ในหลายกรณี สถาปนิกจะถูกขอให้ทำงานข้ามหลายทีม

ความรับผิดชอบหลายอย่างของสถาปนิกสามารถมองเป็นความรับผิดชอบแบบ enabling ได้ นั่นคือการสื่อสารวิสัยทัศน์ทางเทคนิคอย่างชัดเจน เข้าใจความท้าทายที่เกิดขึ้น และช่วยปรับวิสัยทัศน์ทางเทคนิคให้เหมาะสม สถาปนิกช่วยเชื่อมโยงผู้คนเข้าด้วยกัน คอยจับตาดูภาพรวม และช่วยให้ทีมเข้าใจว่าสิ่งที่พวกเขาทำนั้นเข้ากับภาพรวมที่ใหญ่กว่าอย่างไร สิ่งนี้เข้ากันได้ดีกับแนวคิดที่ว่าสถาปนิกเป็นส่วนหนึ่งของ enabling team อย่างที่เราเห็นใน Figure 16-4 enabling team แบบนี้อาจประกอบด้วยคนหลากหลาย บางคนอาจอุทิศเวลาให้ทีมเต็มเวลา ส่วนคนอื่นๆ อาจเข้ามาช่วยเป็นครั้งคราว

Figure 16-4. ฟังก์ชันด้านสถาปัตยกรรมในฐานะ enabling team

โมเดลที่ผมชอบมากคือการมีสถาปนิกเฉพาะจำนวนน้อยในทีมนี้ (บางทีก็แค่หนึ่งหรือสองคนในหลายกรณี) แต่ให้ทีมนี้ได้รับการเสริมกำลังเมื่อเวลาผ่านไปด้วยนักเทคโนโลยีจากแต่ละทีมส่งมอบ อย่างน้อยก็ technical lead ของแต่ละทีม สถาปนิกมีหน้าที่รับผิดชอบให้แน่ใจว่ากลุ่มนี้ทำงานได้ วิธีนี้ กระจาย งานออกไป และทำให้มีระดับความมีส่วนร่วม (buy-in) สูงขึ้น มันยังทำให้ข้อมูลไหลจากทีมต่างๆ เข้าสู่กลุ่มได้อย่างอิสระ ซึ่งส่งผลให้การตัดสินใจมีเหตุผลและมีข้อมูลรองรับมากขึ้น

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

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

จุดที่น่าสนใจ อย่างที่เราจะพูดถึงต่อไปในไม่ช้า คือเมื่อสถาปนิกต้องเข้าไปมีส่วนร่วมในกิจกรรมด้าน governance ด้วย สิ่งนี้อาจก่อให้เกิดความสับสนเกี่ยวกับบทบาทของทีมสถาปัตยกรรมแบบ cross-cutting ใดๆ จะเกิดอะไรขึ้นเมื่อทีมหนึ่งเบี่ยงเบนไปจากกลยุทธ์ทางเทคนิค นั่นโอเคไหม บางทีมันอาจเป็นข้อยกเว้นที่สมเหตุสมผล แต่มันก็อาจก่อให้เกิดปัญหาพื้นฐานมากขึ้นได้เช่นกัน การตัดสินใจระยะสั้นที่ทำเพื่อความรวดเร็วอาจไปกระทบการเปลี่ยนแปลงที่ใหญ่กว่าที่กำลังพยายามทำอยู่ ลองนึกภาพว่ากลุ่มสถาปัตยกรรมกำลังพยายามช่วยให้องค์กรเลิกใช้ข้อมูลแบบรวมศูนย์ เนื่องจากปัญหาเรื่อง coupling และปัญหาด้านปฏิบัติการที่มันก่อขึ้น แต่หนึ่งในทีมกลับตัดสินใจโยนข้อมูลใหม่ลงในฐานข้อมูลที่ใช้ร่วมกัน เพราะอยู่ภายใต้แรงกดดันให้ส่งมอบงานเร็วๆ แล้วจะเกิดอะไรขึ้น

จาก ประสบการณ์ของผม ทั้งหมดนี้ขึ้นอยู่กับการสื่อสารที่ดีและชัดเจน และความเข้าใจในความรับผิดชอบ ถ้าผมเห็น product owner ตัดสินใจในสิ่งที่ผมรู้สึกว่าจะบั่นทอนกิจกรรม cross-cutting บางอย่างที่ผมกำลังพยายามผลักดันอยู่ ผมจะไปคุยกับพวกเขา บางทีคำตอบคือการตัดสินใจระยะสั้นนั้นถูกต้องแล้ว (และอาจถือได้ว่าเป็น technical debt รูปแบบหนึ่งที่เรารับรู้และยอมรับเอาไว้แต่แรก) ในกรณีอื่น บางที product owner อาจสามารถเปลี่ยนแผนที่วางไว้เพื่อให้สอดคล้องกับกลยุทธ์โดยรวมได้ ในกรณีที่แย่ที่สุด ปัญหาอาจต้องถูกยกระดับขึ้นไป

ที่ REA บริษัทอสังหาริมทรัพย์ออนไลน์ที่ผมพูดถึงในบทก่อนหน้านี้หลายครั้ง product owner บางครั้งก็ตัดสินใจจัดลำดับความสำคัญของงานในแบบที่ทำให้เกิด technical debt สะสมขึ้น นำไปสู่ปัญหาตามมา ปัญหาคือ product owner ถูกวัดผลหลักๆ จากความสามารถในการส่งมอบฟีเจอร์และทำให้ลูกค้าพอใจ ในขณะที่ปัญหาเรื่อง technical debt มักถูกโยนให้เป็นความรับผิดชอบของ technical leader มีการเปลี่ยนแปลงเกิดขึ้นโดยให้ product owner รับผิดชอบแง่มุมทางเทคนิคของซอฟต์แวร์ด้วย นั่นหมายความว่าพวกเขาต้องมีบทบาทที่กระตือรือร้นมากขึ้นในการเข้าใจแง่มุมทางเทคนิคของระบบ (เช่น ความปลอดภัยหรือประสิทธิภาพ) และทำงานร่วมกับผู้เชี่ยวชาญด้านเทคนิคมากขึ้นในการจัดลำดับความสำคัญของงาน การทำให้ product owner ที่ไม่ใช่สายเทคนิคต้องรับผิดชอบเรื่องการจัดลำดับความสำคัญของกิจกรรมทางเทคนิคมากขึ้นนั้นไม่ใช่เรื่องง่าย แต่จากประสบการณ์ของผม มันคุ้มค่าอย่างแน่นอน