จากบทความเรื่อง The Elephant in the Architecture นั้น
ทำการอธิบายถึงที่มาที่ไปของปัญหาต่าง ๆ ที่เกิดขึ้นในการออกแบบ software
ว่าเราทำการออกแบบด้วยแนวคิดอย่างไร ?
ซึ่งแนวทางนั้นจะเทียบเคียงได้กับ
สำนวน The Elephant in the room นั่นคือ
เราทุกคนนั้นเห็นปัญหา เห็นข้อเท็จจริงต่าง ๆ อย่างชัดเจน
แต่ทุกคนหลีกเลี่ยงที่จะพูดถึงมัน
เหมือนกับการมีช้างอยู่ในห้อง แต่ทุกคนจะไม่พยายามหรือมองเห็นมันนั่นเอง
คำถามคือ แล้วจะแก้ไขปัญหาได้อย่างไร ?
โดยในบทความจะอธิบายถึง
เหตุผลในการตัดสินใจเลือกแนวทางในการออกแบบ architecture ของ software
ว่า ควรที่จะต้องออกแบบตาม business value เป็นหลัก
เนื่องจากพบว่าส่วนใหญ่แล้ว
ถ้าพูดถึงการออกแบบ architecture ของ software
เรามักจะพูดถึงเรื่องของ Architecture attribute มากกว่า Business attribute
- Performance ของระบบว่าเป็นอย่างไร
- Resilient ของระบบว่า ถ้าเกิดปัญหาแล้วจะนำระบบกลับมาเป็นปกติได้อย่างไร
- ระบบงานต้องรองรับการเปลี่ยนแปลงได้ง่าย
แต่กลับไม่เคยพูดถึงว่า
ระบบที่ออกแบบมามานั้น มีคุณค่าเชิง business อย่างไรบ้าง
สร้างมาเพื่อสนับสนุน business นั้น ๆ จริงไหม
Architecture ที่ออกแบบมามันตอบโจทย์ business อะไรบ้าง
สิ่งที่ตามมาก็คือ การตัดสินใจในการเลือก architecture ต่าง ๆ
อาจจะเป็นทางที่ over-engineering ไป
อาจจะเป็นทางที่ยาก และมีค่าใช้จ่ายเยอะเกินไป
โดยไม่ได้ส่งผลดีต่อ business เลย
โดยช้างตัวนี้ มักจะมีส่วนประกอบต่าง ๆ ดังรูป
สิ่งท่ีน่าสนุกกว่าคือ เมื่อให้เชิญ business เข้ามาคุยกับทาง technical
ผลปรากฏว่า ทาง technical ก็จะถามว่า
จะให้ business เข้ามาพูดคุยกับเราทำไม ?
มันคนละส่วนงานกันนะ ไม่เกี่ยวกัน !!
นี่คือสัญญาณที่อาจจะบอกว่า technical ตัดสินใจในทางของตนเองเท่านั้น
ไม่ได้สนใจ business value เลย
มันคือ ต้นเหตุของปัญหาต่าง ๆ หรือไม่นะ ?
ยกตัวอย่างเช่น ถ้าเราต้องการแยกระบบงานจาก Monolith ที่มีขนาดใหญ่และซับซ้อน
ยากต่อการพัฒนาและดูแลรักษา
ยิ่งทาง business ยิ่งลำบากไปอีก
ดังนั้น จึงตัดสินใจว่าจะแยกส่วนการทำงานต่าง ๆ ออกจากกัน
คำถามคือ
เราจะแยกอย่างไร
เราจะลงเมื่อทำอะไรก่อนหลัง
ถ้าให้สาย technical เลือก ก็คือ แยกทุกอย่างออกจากกัน
แล้วลงมือสร้างใหม่ขึ้นมาทั้งหมดพร้อม ๆ กันหรือ
หรือไปดูก่อนว่า product หรือ service อะไรที่มีคุณค่าในเชิง business
หรือทำเงินได้มากกว่า
จากนั้นจึงเลือกแยกและทำสิ่งนั้นก่อน
แนวทางของการ mapping ระหว่าง business value กับ architecture
ถ้าเรายังไม่เคยทำการสรุปว่า Architecture ของระบบงานกับ business value
มีความสัมพันธ์กันอย่างไรบ้าง
ในบทความแนะนำหลาย ๆ แนวทาง ทั้ง
- Value stream mapping
- ผลกระทบของระบบที่ผิดพลาด ส่งผลต่อ business อย่างไรบ้าง
- ใช้ระบบ monitoring มาช่วยดู business value
เป็นแนวทางการทำงานร่วมกันทั้งสองฝ่าย
ทั้งการพูดคุยและการทำงานร่วมกัน ต่างฝ่ายต้องเข้าใจซึ่งกันและกันเสมอ
มิเช่นนั้นผลที่ตามมาคือ
การลงมือทำอะไรที่มากจนเกินความต้องการ
นั่นคือเสียทั้งเวลาและค่าใช้จ่าย
และได้ระบบงานที่ยากต่อการดูแลรักษา
มีระบบการทำงานที่รองรับ business เยอะ ๆ ไหม ?
เป็นชุดคำถามที่น่าสนใจ
ถ้าระบบเป็นแบบนี้แล้ว
อาจจะมาจากเรื่องของการ sharing
อาจจะมาจากเรื่องของการ reuse
เพื่อลดค่าใช้จ่ายในการพัฒนา แต่สิ่งที่ต้องทำเพิ่มเข้ามาจากแนวทางนี้คือ
- Flexibility หรือความยืดหยุ่น
- Resilience
แต่ก็พบว่า เมื่อมีการเปลี่ยนแปลงหรือเกิดปัญหาขึ้นมาแล้ว
จะกระทบต่อ business ต่าง ๆ ที่ใช้งาน
นั่นคือ กระทบต่อผู้ใช้งาน และแน่นอนคือรายได้ของระบบงาน
คำถามคือ มันควรเป็นแบบนี้จริง ๆ ใช่ไหม ?
หรือถ้าเรานำเอาเรื่องของ bussiness value มาพูดถึงก่อน technical
เราน่าจะได้ระบบงานที่เฉพาะเจาะจงกับ business นั้นเลยหรือไม่
ซึ่งน่าจะมีผลดีต่อ business มากกว่าหรือไม่ ?
ซึ่งตรงนี้ก็น่าคิดนะ
อีกตัวอย่างหนึ่งที่น่าสนใจคือ การย้ายระบบไปขึ้น Cloud !!
คำถามคือ
เราจะย้ายระบบขึ้นไปบน Cloud ทั้งหมดหรือไม่ ?
เราย้ายขึ้นไปเพื่อ หวังว่าระบบงานจะทำงานดีขึ้นหรือไม่ ?
หรือเร้าย้ายขึ้นไป เพื่อช่วยทำให้ business ทำงานได้ดีขึ้น สะดวกขึ้น ?
เราย้ายเพื่ออะไรกันแน่ ?
ก่อนย้ายควรพูดคุยและพิจารณาก่อนหรือไม่
ว่าอะไรควรย้ายหรือไม่ควรย้าย
อะไรควรแก้ไขก่อนที่จะย้าย
อะไรควรทิ้งก่อนย้าย
มันคือ คุณค่าที่เราต้องนำมาพิจารณาหรือไม่ ?
ไม่ใช่จะย้ายเพราะว่า ต้องย้าย แล้วย้ายทั้งหมดเลย
แบบนี้ไม่น่าจะเป็นแนวทางที่ดีและเหมาะสมนะ
เหมือนกับขี้ ไม่ว่าจะอยู่ที่ไหน มันก็คือ ขี้ !!
ที่สำคัญ business value มันเปลี่ยนแปลงอยู่อย่างเสมอ
อะไรที่เคยสำคัญอาจจะไม่สำคัญก็ได้
ดังนั้น architecture ของระบบก็เช่นกัน
สุดท้ายสิ่งที่บทความแนะนำเลยก็คือ ความรู้เชิง business เป็นสิ่งสำคัญของสายงาน techical
ควรต้องทำการเรียนรู้และเข้าใจก่อนเสมอ
ยิ่งคนทำงานใหม่ ๆ ยิ่งต้องเรียนรู้ business domain ที่ทำงานอยู่ให้ชัดเจน
นั่นคือเรียนรู้ทั้ง Hard skill และ Soft skill
ยิ่งเรารู้และเข้าใจมากเท่าไร
เราก็จะพยายามออกแบบและสร้างระบบที่เหมาะสมมากเท่านั้น
เนื่องจากเรื่องนี้เป็นปัญหาหลักของ Business vs IT (Technical) กันเลยทีเดียว
ทำให้ต้องมีคนกลางมาแปลงสารอีก
มันคือการแก้ไขปัญหาด้วยการสร้างปัญหา
มันคือ ช้างอีกตัวที่เราสร้างกันขึ้นมา !!
โดยที่ไม่แก้ไขที่ต้นเหตุ
ดังนั้น ทั้งสองฝั่งต้องปรับตัวเข้าหากัน เดินหน้าไปด้วยกัน
