New system architect role

หัวข้อนี้อยากเขียนมานานแล้วเพราะมีมิตรท่านนึงโยนคำถามว่า Software architect ในโลกของ Agile จะเป็นอย่างไร เพราะมันไม่ได้มี Design phase อีกต่อไปแล้ว

ทีนี้ผมจะเกริ่นนำก่อนที่จะเสนอโมเดลหน้าที่ความรับผิดชอบใหม่ของ Software architect ผมขออธิบายก่อนละกันว่าผมคิดว่าโมเดลเก่ามันมีปัญหาอะไรเราถึงต้องเสนอของใหม่ (ไม่งั้นจะเสนอทำไม จริงมั้ย?)

What’s wrong with old model?

ผมคิดว่า Software architect ในโลกของ Waterfall model มันมีปัญหาสำคัญที่สุดคือ เขามี Incentive ให้ออกแบบระบบที่มีสถาปัตยกรรมดีที่สุดเท่าที่จะดีได้

หา?? มันเป็นปัญหายังไงเหรอ ฟังดูดีออก เป็น Software architect ก็ต้องออกแบบระบบที่สถาปัตยกรรมดีสิ แปลกตรงไหน ก็ถูกแล้วนี่?

ในโลกของ Waterfall Model เรามองภาพการทำงานเป็นแบบนี้

เรามองว่ามันแยกกันระหว่างการทำ Design ระบบ กับการ Implement ระบบมันเป็นส่วนแยกกัน คือ Design ก็ออกแบบไป แล้วก็ค่อยพัฒนาทีเดียวตามที่ออกแบบ

เมื่อคุณวางให้ Implementor กับ Designer อยู่คนละฝั่งกัน ทำงานแยกกัน ปัญหาที่ตามมาคือทุกคนจะพยายามทำในสิ่งที่ตัวเอง “ดีที่สุด”

คนวาง Architect ของระบบมีแรงจูงใจให้ออกแบบระบบให้ดีที่สุดเท่าที่ตัวเองคิดได้ และ Implementer ก็มีแรงจูงใจให้ทำงานให้เร็วที่สุดเท่าที่เป็นไปได้

ซึ่งบางครั้ง การที่สองฝั่งพยายามทำในสิ่งที่ “ดีที่สุด” ของตนเอง มันไม่ได้การันตีว่าทีมจะ “ดีที่สุด” ด้วย (ถ้าภาษา Math จะเรียกว่า Local optimum not imply global optimum)

เช่น ถ้าคน Implement สามารถทำงานได้เร็วที่สุดบน PHP Stack แต่ในทางสถาปัตยกรรม ระบบที่จะสร้างขึ้นมาไม่เหมาะกับการใช้ PHP Stack เนื่องจากมี Concurrency มากๆ จึงควรไปใช้พวก Functional Language จะทำยังไง?

เราควรจะเชื่อ Architect ที่เขาเลือก “การออกแบบที่ดีที่สุด” หรือเชื่อ Developer ที่เขาเลือก “สิ่งที่ Implement ได้ดีที่สุด” ล่ะ

ดังนั้นในสถานการณ์แบบนี้เราจึงมักจะเห็น Architect กับ Developer ตีกันเสมอ ฝั่งนึงก็จะบอกว่า “คุณเป็น Developer ที่ไม่ได้เรื่อง ทำไมไม่เรียนภาษาใหม่” อีกฝั่งก็บอกว่า “คุณออกแบบมาภาษาอะไร PHP เขาก็ใช้ทำได้กระทั่งสเกล Facebook เลยนะ คุณบอกว่าไม่เหมาะกับระบบแบบนี้ได้ยังไง”

แล้วผู้ชนะคือผู้ที่มี “กำลังภายในทางการเมือง” ในบริษัทมากกว่า เพราะต่างฝั่งต่างพยายาม Push ในสิ่งที่ “ดีที่สุด” ของตัวเอง แล้วทำลายอีกฝั่ง เกิดเป็นดราม่า

และโครงสร้าง Waterfall ก็มีแรงจูงใจให้ทำแบบนั้นเสียด้วยสิ

New role of software architect

ผมคิดว่าสิ่งที่แตกต่างจากยุคเดิมคือ Architect ในรุ่นใหม่ ไม่ใช่แค่ออกแบบระบบที่ดีเท่านั้น แต่ต้องคำนึงถึงทีมและ Trade-off ให้ดีด้วย

ดังนั้นการทำงานจะต้องประสานกับ Developer / Implementer มากขึ้น จนถึงขั้นเข้าใจว่าแต่ละคนมีศักยภาพยังไง เพื่อที่จะออกแบบระบบยังไงให้ดึงศักยภาพของ “ทีม” ได้มากที่สุด ไม่ใช่ระบบที่ “ดีที่สุด” ในกระดาษเท่านั้น

ในปัจจุบัน ที่ Taskworld ผมขอให้เครดิตกับน้อง Thai Pangsakulyanont เป็น Front-end architect ซึ่งผมชื่นชมในการวาง Role ของน้องเขามาก

ก่อนที่เขาจะเอาสถาปัตยกรรมใหม่เข้ามา เขาคำนึงเรื่องที่ว่าทีมสามารถ Execute stack ได้ด้วย แถมเรายังสนใจด้วยว่าถ้าใช้ Stack ซับซ้อนจนเกินไป จะทำให้คนเข้ามาใหม่มี Learning curve เยอะ และเราก็คุยกันและระวังตัวกันในเรื่องนี้เสมอ

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

ผมคิดว่านั่นคือ Architect สมัยใหม่ ที่แตกต่างจากเดิม เราไม่ได้ออกแบบระบบที่ “ดีที่สุดในโลก” อีกต่อไป แต่เราออกแบบเลือก Stack ที่ดีที่สุดสำหรับทีม รวมถึงดูแลการเปลี่ยนแปลงด้วย

ถ้าจะให้สรุปสั้นๆ ผมคิดว่าสิ่งที่เปลี่ยนไปในโลก Software สมัยใหม่ คือ Architect สมัยก่อน รับผิดชอบในการออกแบบและเสนอสถาปัตยกรรมของระบบที่ดี แต่ Architect ยุคใหม่ รับผิดชอบในการทำให้ทีมใช้สถาปัตยกรรมที่ดีครับ

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.