TLDL;
ประเด็นต่าง ๆ ที่เราในฐานะ Software Architect ควรจะพิจารณา:
- การนำเอา Small language model (SLM) และ Agentic AI มาใช้ในองค์กร หลังจากที่หลายคนเอา LLM มาใช้งานแล้ว
- Retrieval-augmented generation (RAG): การปรับปรุงผลลัพธ์ LLM ให้ดีขึ้น ทำให้ระบบรองรับ RAG ได้ง่ายขึ้น
- AI-assisted development tools: เรื่องการเอาเครื่องมือ ยกตัวอย่างเช่น cursor, claude, etc มาใช้แล้ว ในมุมของ architect จะรู้ได้ยังไง ว่าเราเพิ่มประสิทธิภาพการทำงานของนักพัฒนา โดยไม่ลดทอนเรื่องของคุณภาพ
- Green software: การออกแบบซอฟต์แวร์ที่ลดผลกระทบต่อสิ่งแวดล้อมและลด carbon footprint
- การกระจายอำนาจการตัดสินใจ: เพื่อลดปัญหาคอขวดที่ software architect
Crossing the Chasm model
ในทุกปีทาง InfoQ จะออกรายงานที่บอกถึงเทรนด์ที่เกิดขึ้นในปีนั้น ๆ โดยการแบ่งกลุ่มของเทรนด์จะใช้โมเดล “Crossing the Chasm” ของคุณ Geoffrey A โดยฝั่ง InfoQ จะแสดงแค่ 4 ตัวคือ
- Early Market
- Innovators
- Early Adopters
- Mainstream Market
- Early Majority
- Late Majority
ภาพจาก: https://smithhousedesign.com/models-predicting-future-geoffrey-moores-crossing-chasm/
ในส่วนของ Innovators และ Early Adopters เป็นสิ่งที่ทีมผู้เขียน InfoQ trends จะโฟกัสในปีหน้า ซึ่งให้คนอ่านเป็นไอเดียวางแผนในการศึกษาเทคนิค และเครื่องมือ ในการเอามาปรับใช้กับงาน
ยกตัวอย่างเช่น ถ้า technology ตัวนั้นข้ามเส้นจากฝั่ง Early Adopters มาฝั่ง Early Majority บอกเป็นสัญญาณได้ว่ามีหลายบริษัทนำ technology นั้นมาใช้งานแล้ว เราอาจจะตัดสินใจที่จะเอามาใช้ด้วยเหมือนกันก็เป็นไปได้ถ้า technology นั้นตอบโจทย์สิ่งที่องค์กรกำลังเจออยู่
ภาพจาก InfoQ
Theme AI มาแร๊งส์
AI trends for architects
ถ้าดูจาก report จะเห็นว่า LLM เป็นตัวนึงที่ไม่ได้แค่ “ข้ามเหว” (cross the chasm) เฉย ๆ แต่เลยไปไกลถึง late majority เป็นนัยได้ว่า LLM เป็น norm ของอุตสาหกรรมเราแล้ว ใครที่ไม่ได้ใช้อาจจะต้องพิจารณาว่าทำไมเราถึงยังไม่ได้เอามาใช้กันนะ
แต่การที่ข้ามไปฝั่ง late majority ก็ไม่ได้ความว่าทุกคนมาถูกทาง เพราะเราอาจจะเอาเครื่องไปใช้งานผิดได้ 😂 อารมณ์เหมือนกับการที่เราเอาค้อนไปใช้แก้ปัญหาทุกอย่าง ซึ่งมันไม่ใช่
Agentic AI — Innovator
Agentic AI หรือ ที่ก่อนหน้านี้ถูกเรียกว่า “AI Agents” ไอเดียของสิ่งนี้คือการที่ AI สามารถคิดและตัดสินใจงานบางอย่างได้ด้วยตัวมันเอง บางครั้งเราก็เอา agents หลายตัวมาทำงานร่วมกันเพื่อให้ได้ผลลัพธ์ที่ดีกว่าเดิม
ทำไมสิ่งนี้ถึงยังเป็น Innovator ล่ะ?
เพราะว่ายังมี gap ในหลายองค์กรที่ยังไม่ได้เชื่อใจ AI ที่เป็น nondeterministic software ให้มาตัดสินใจสิ่งที่สำคัญ
หาก architects เอาเรื่อง agentic ไปประยุกต์ใช้ในงาน หรือต้องออกแบบระบบที่เกี่ยวกับ agentic ก็สามารถอ้างอิงเอาแนวทางการออกแบบ microservices มาใช้ได้เหมือนกัน นั่นคือแต่ละ agentic จะต้องมี clearly defined boundaries และรูปแบบที่เชื่อมหากัน
Small language models (SLMs) — Innovator
เนื่องจาก architects หลายคนอยากนำเอา LLM มาปรับใช้กับองค์กร แต่ติดปัญหาเรื่องของ cost, การตั้ง server ต่าง ๆ small language models ที่กินทรัพยากรน้อยกว่า ใช้ carbon footprint ที่น้อยกว่า ก็ส่งทำให้ง่ายที่จะเอามาใช้แถมค่าใช้จ่ายถูกกว่า LLM เยอะมาก บางทีเราสามารถติดตั้ง SLMs ลงใน hardware เครื่องเดียว หรือกระทั่งการจะเอามาใช้กับโทรศัพท์พกพา แต่ก็ต้องดูอีกว่า small language models ตัวนั้นถูกปรับแต่งมาให้เก่งในเรื่องอะไร และเราเอาไปใช้ตรงจุดประสงค์หรือเปล่า
Retrieval-augmented generation (RAG) – Early adopter
ตามที่ trend LLM มา RAG เองก็มาเช่นกันเพราะเมื่อเราอยากทำให้ LLM ได้ผลลัพธ์ที่แม่นยำมากขึ้นก็ต้องอาศัยการดึงข้อมูลที่ดี RAG เลยเป็นคำตอบสำหรับใครหลายคนที่จะเอามาใช้คู่กับ LLM
โดยในอนาคตคาดว่าเราจะได้เห็นการออกแบบระบบที่ data ที่จะถูกส่งให้ RAG เพิ่มมากขึ้น ซึ่งเกี่ยวข้องกับการทำ data-driven architecture ที่ได้รับความนิยมในปัจจุบัน
AI-assisted development – Early majority
เทรนด์ของ low-code/no-code ในช่วงก่อนหน้าตอนนี้ถูกแทนที่ด้วย AI-assisted development ซึ่งถูกใช้โดยคนที่ไม่ได้เป็นโปรแกรมเมอร์
สิ่งที่ architects และ engineers กังวลคือเรื่องของคุณภาพของโค้ดที่ถูกสร้างโดย AI เพราะเนื่องจากผลลัพธ์ขึ้นอยู่กับคุณภาพของ “prompt” ที่ใส่ให้กับเครื่องมือ architect จึงต้องมองหาการเขียน prompt ที่ดีที่ช่วยให้มั่นใจได้ว่า code และ architecture guideline ยังไปในทิศทางเดียวกันอยู่
มีเครื่องมือหลายตัวที่น่าจะช่วยให้การใช้ AI-assisted development อยู่ในร่องรอย แต่ก็ยังไม่มีของที่มี standard ที่เรียกว่าเทียบเคียง linting หรือ editorconfig เลย
Non-AI Topics
หลุดจากเรื่อง AI กันบ้าง 😂
Green software – Innovators
ภาพจาก Unsplash
Carbon-efficient และ carbon-aware software ถือว่าเป็นฝั่ง innovators ที่น่าจับตามอง เพราะอย่างที่เรารู้กันบริษัท tech ยักใหญ่ตื่นตัวกับการทำให้ carbon neutral เนื่องจากปัญหาก๊าซเรือนกระจกที่เพิ่มขึ้นจะส่งผลต่อการเพิ่มขึ้นของอุณหภูมิโลก ที่ผู้นำกว่าหลายร้อยประเทศหารือและตั้งเป้าว่าจะต้องช่วยกันลดปริมาณก๊าซเรือนกระจก
ฝั่งของการทำ software ไม่ใช่การคิดแค่ว่าลดส่วนที่ไม่ใช้ ลด cost จะตอบเรื่อง green software ได้ แต่ยังต้องพิจารณาถึง การใช้ทรัพยากรที่ใช้ซ้ำซ้ำได้ พลังงานสะอาด การเลือกใช้ cloud ที่ใช้พลังงานสะอาด
ส่งผลให้ต้องพิจารณาไปถึงเรื่องของ “สถานที่และเวลา” โดยเลือกใช้พลังงานจาก data center ตามที่ที่มีพลังงานแสงอาทิตย์อยู่ “Follow the sun”
รวมไปถึงการใช้งาน server ให้เต็มประสิทธิภาพดีกว่าการที่ปล่อยให้ server อยู่ในสถานะ idle state
นอกจากนี้ก็คือเรื่อง network traffic ที่กินพลังงานเช่นเดียวกัน จะทำยังไงได้บ้างที่จะทำให้ data อยู่แบบ locally มากที่สุดเท่าที่จะเป็นไปได้ ก็เป็นเรื่องที่ต้องพิจารณา
Privacy engineering – Innovators
สิ่งนี้ถูกใส่มาใน trend เมื่อปีที่แล้ว 2024 เพื่อบอกว่ามีองค์กรที่คิดเรื่องของ “privacy” เป็น feature หลัก
บางกรณีการมาถึงของ AI (LLM) ที่ยิ่งต้องพิจารณาถึง privacy ของข้อมูล ที่จะถูกใช้ในอนาคต
ในการที่จะพัฒนา LLM ทาง architect ก็ต้องคิดเรื่องที่ data จะต้องวิ่งผ่าน network ที่จะถูกเอาไป train model ในอนาคตได้ ก็ต้องดูว่ามันยังเป็นไปตาม terms of use ที่เราระบุไว้ก่อนหน้านี้ไหม
Socio-technical architecture – Early adopter
การออกแบบระบบที่มีความซับซ้อน คนที่ออกแบบจำเป็นจะต้องเป็นกลุ่มคนเดียวกันกับที่จะ “พัฒนา” “ดูแล” “วิวัฒนาการ” ตัว software นั้น
การเคลื่อนไหวของเรื่อง “Shift-left” ถูกนำเอามาปรับใช้กับหลายมุมมอง ยกตัวอย่างเช่น DevOps หรือ Testing
การทำ “Shift-left” ไม่ใช่การมุ่งไปหาการทำงานแบบ Waterfall หรือการออกแบบล่วงหน้าแบบใหญ่หรือทั้งหมด (big design up front) — architect มุ่งเน้นกับการพูดคุยกับ stakeholders ล่วงหน้าถึง concern ต่าง ๆ และออกแบบระบบให้สามารถที่วิวัฒนาการ ปรับเปลี่ยนได้ในอนาคต และหลีกเลี่ยงการแก้ในนาทีสุดท้าย (last-minute work)
Innovator architects ยังมองไปถึงการทำให้ตัวเองไม่เป็นคอขวดในเรื่องการของการตัดสินใจ architects จึงต้องมีสกิลที่จะ facilitate “architecture decision” ที่ทำให้สมาชิกทีมคนอื่นเป็นผู้ตัดสินใจได้ โดยการให้คำแนะนำและช่วยสมาชิกคนอื่นรู้ถึงกระบวนการที่ใช้ในการ “ตัดสินใจ” เพื่อให้ทีมงานทำงานได้รวดเร็วขึ้น การตัดสินใจเหมาะสมกับบริบท รวมถึงสมาชิกมีความเข้าใจและมั่นใจกับการออกแบบมากขึ้น
ทำให้สิ่งนี้เป็นประโยชน์อย่างมากกับคนที่กำลัง เขียน, deploy, และดูแล software นั้น ๆ
ขอบคุณข้อมูลจาก InfoQ
เพิ่มเติม
หากสนใจปรึกษาเรื่องการ "ทำอย่างไรให้ Architect ไม่เป็นคอขวด” หรือ “การตัดสินใจ software architecture อย่างมีหลักการ” ก็ติดต่อมาทางเพจได้นะครับ 😀