7 เทรนด์การพัฒนาซอฟต์แวร์ในปี 2565 และเหตุผลที่องค์กรควรเปลี่ยนตาม

7 เทรนด์การพัฒนาซอฟต์แวร์ในปี 2565 และเหตุผลที่องค์กรควรเปลี่ยนตาม 

โดย นายเติมศักดิ์ วีรขจรพงษ์ รองประธานภูมิภาคเอเชียตะวันออกเฉียงใต้ เอาท์ซิสเต็มส์

ทุกวันนี้เราทุกคนน่าจะคุ้นเคยกับคำกล่าวที่ว่า “ทุกบริษัทล้วนเป็นบริษัทซอฟต์แวร์” แต่ในความเป็นจริงแล้ว การนำเสนอซอฟต์แวร์ที่มีคุณภาพนับเป็นเรื่องยาก เพราะกระบวนการพัฒนาซอฟต์แวร์มีความซับซ้อนเพิ่มมากขึ้นเรื่อย ๆ ขณะที่เทคโนโลยีมีการเปลี่ยนแปลงอย่างต่อเนื่อง และมีบริการคลาวด์ใหม่ ๆ ผุดขึ้นอย่างไม่รู้จบ แต่จำนวนวิศวกรด้านซอฟต์แวร์กลับมีไม่เพียงพอ โดยไอดีซีประเมินว่าในปัจจุบันมีการขาดแคลนนักพัฒนาที่เป็นพนักงานประจำราว 1.4 ล้านคน (ปี 2564) และคาดว่าตัวเลขดังกล่าวจะเพิ่มเป็น 4 ล้านคนในเวลาเพียงแค่ 4 ปี

ขณะเดียวกัน วิวัฒนาการของการทำงานในรูปแบบไฮบริดและการเร่งปรับเปลี่ยนสู่ดิจิทัล ซึ่งเป็นผลสืบเนื่องจากสถานการณ์การแพร่ระบาดที่เกิดขึ้นทั่วโลก ก่อให้เกิดปัญหาอย่างมากต่อทีมงานฝ่ายพัฒนาซอฟต์แวร์ในทุกแวดวงอุตสาหกรรม และอาจเป็นฟางเส้นสุดท้ายที่ทำให้กระบวนการพัฒนาในรูปแบบเดิม ๆ ต้องพังลงสภาพความเป็นจริงที่เปลี่ยนไปนี้ทำให้ผู้บริหารฝ่ายวิศวกรรมซอฟต์แวร์จำเป็นที่จะต้องทบทวนข้อมูลคาดการณ์สำหรับปี 2565 และวางแผนปรับปรุงทีมงาน แนวทางปฏิบัติ และเครื่องมือต่าง ๆ ให้ทันสมัยมากขึ้น เพื่อรองรับ 4 องค์ประกอบหลักของงานวิศวกรรมซอฟต์แวร์ ได้แก่:

• ประสบการณ์สำหรับนักพัฒนา: มุ่งที่จะลดความซับซ้อนด้านเทคนิค เพื่อให้ทีมงานสร้างสรรค์นวัตกรรมได้อย่างรวดเร็ว
• ระบบอัตโนมัติสำหรับเวิร์กโฟลว์ด้านการพัฒนา: ลดปัญหาการติดขัดและการโอนย้ายระหว่างแพลตฟอร์มและเครื่องมือทั้งหมดในขั้นตอนต่าง ๆ ของการพัฒนา โดยอาศัยการบูรณาการเข้าด้วยกันอย่างกลมกลืน
• การรักษาความปลอดภัยและการปฏิบัติตามกฎระเบียบ: นักพัฒนาคัดแยกสิ่งที่สามารถทดสอบระหว่างการพัฒนา ออกจากสิ่งที่ควรจะทดสอบในภายหลัง เพื่อเพิ่มความสะดวกในการเขียนโค้ดที่ปลอดภัย
• การติดตั้งใช้งานและการดำเนินการ: มุ่งเน้นการปรับใช้ในส่วนของผู้ใช้งาน เพื่อปรับปรุงเสถียรภาพและประสิทธิภาพในการให้บริการ

จากองค์ประกอบหลักดังกล่าว เราได้คาดการณ์ 7 เทรนด์ด้านการพัฒนาซอฟต์แวร์ที่จะมีความสำคัญในช่วงปี 2565 โดยผู้บริหารฝ่ายวิศวกรรมซอฟต์แวร์ควรจะพิจารณาเทรนด์เหล่านี้เพื่อปรับปรุงทีมงานฝ่ายพัฒนา แนวทางปฏิบัติ และเครื่องมือต่าง ๆ ให้ทันสมัย ซึ่งจะช่วยให้บรรลุเป้าหมายทางด้านธุรกิจ:

1. DevSecOps
2. การบูรณาการโดยอาศัย API
3. แพลตฟอร์ม Low-Code สำหรับมืออาชีพ
4. แพลตฟอร์มคลาวด์เนทีฟ
5. DesignOps
6. การตรวจสอบอย่างทั่วถึง
7. การมุ่งเน้น PWA

1. DevSecOps

ประเด็นเรื่องความปลอดภัยยังคงเป็นข้อกังวลใจที่สำคัญที่สุดสำหรับผู้บริหารฝ่ายไอทีและทีมงานด้านวิศวกรรมซอฟต์แวร์ ขณะที่องค์กรต้องรับมือกับภัยคุกคามเพิ่มมากขึ้นอย่างที่ไม่เคยมีมาก่อน ไม่ว่าจะเป็นการโจมตีด้วยมัลแวร์เรียกค่าไถ่ที่เพิ่มขึ้นอย่างต่อเนื่อง การขาดเส้นแบ่งพรมแดนที่ชัดเจนสำหรับข้อมูลขององค์กร ความเสี่ยงที่เพิ่มขึ้นเนื่องจากการพัฒนาซอฟต์แวร์ร่วมกันของผู้ใช้ทั่วไป ความเป็นส่วนตัวของข้อมูล หรือข้อบังคับและกฎระเบียบต่าง ๆ  ทั้งหมดนี้ส่งผลให้เกิดความต้องการเพิ่มมากขึ้นสำหรับ DevSecOps ซึ่งจะช่วยให้มีการตรวจสอบรับรองความปลอดภัยและความสอดคล้องตามกฎระเบียบในทุกขั้นตอนของกระบวนการพัฒนา ด้วยแรงกดดันที่เพิ่มขึ้นสำหรับการปกป้องสภาพแวดล้อมการพัฒนาเพื่อให้รอดพ้นจากภัยคุกคามด้านความปลอดภัยในส่วนต่าง ๆ ของซัพพลายเชน และเสริมสร้างความแข็งแกร่งให้กับช่องทางการนำเสนอซอฟต์แวร์ ส่งผลให้ผู้บริหารฝ่ายรักษาความปลอดภัยสารสนเทศ (CISO) และผู้บริหารฝ่ายสารสนเทศ (CIO) ต้องการให้มีการสร้างเว็บแอปและโมบายล์แอปพลิเคชั่นใหม่ ๆ บนแพลตฟอร์มที่จัดการทุกขั้นตอนของการพัฒนาแอปฯ รวมไปถึงการนำเสนอแอปฯ ใหม่ ๆ แทนที่จะพึ่งพากระบวนการทำงานที่ไม่เป็นระบบของบุคลากรกลุ่มต่าง ๆ ที่ใช้แนวทางที่แตกต่างกันสำหรับการพัฒนา

เป้าหมายสูงสุดของแพลตฟอร์มการพัฒนาคือ เพื่อสนับสนุนและเพิ่มความสะดวกให้แก่ทีมงานฝ่ายพัฒนาในการสร้างโค้ดที่ปลอดภัย ภายใต้แนวทางการรักษาความปลอดภัยแบบ Zero Trust แทนที่จะพึ่งพาการทดสอบด้านความปลอดภัยเป็นหลัก

 2. การบูรณาการแบบไฮบริด

รายงานสถานะการใช้งาน SaaS (The State of SaaS Sprawl) ในช่วงปี 2564 ระบุว่า บริษัททั่วไปมีการใช้งานแอปพลิเคชั่น SaaS โดยเฉลี่ย 254 แอปพลิเคชั่น และในบรรดาแอปฯ SaaS ของบริษัท มีเพียง 45% เท่านั้นที่ถูกใช้งานเป็นประจำ  นอกจากนั้น 56% ของแอปฯ ทั้งหมดนี้ไม่ได้รับอนุญาตอย่างเป็นทางการจากผู้ดูแลระบบไอที หรือไม่ใช่แอปของฝ่ายไอทีและไม่ได้ถูกจัดการดูแลโดยฝ่ายไอที  และที่แย่ไปกว่านั้นก็คือ แอปเหล่านี้ทำงานบนชุดซอฟต์แวร์และระบบบันทึกข้อมูลที่รองรับส่วนงานหลัก ๆ ของธุรกิจ

การที่ผู้ใช้ในสายงานธุรกิจปรับใช้ RPA บนเครื่องมือรุ่นเก่าที่ไม่มี API ถือเป็นทางลัดหนึ่งสำหรับระบบรุ่นเก่า แต่ไม่ใช่วิธีการที่เหมาะสม เพราะโดยธรรมชาติแล้ว ธุรกิจดิจิทัลมีความลื่นไหลอย่างมาก และมีการเปลี่ยนแปลงอยู่ตลอดเวลา  ด้วยเหตุนี้ ธุรกิจที่มีความคล่องตัวสูงจึงหันมาใช้แพลตฟอร์มการพัฒนาแบบ Low-Code ซึ่งช่วยให้สามารถทำการเปลี่ยนแปลงแอปได้อย่างรวดเร็ว

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

3. แพลตฟอร์ม Low-Code สำหรับมืออาชีพ

การปรับเปลี่ยนที่เห็นได้อย่างชัดเจนในช่วงปี 2564 ก็คือ การปรับใช้แพลตฟอร์ม Low-Code อย่างกว้างขวาง โดยเฉพาะอย่างยิ่งแพลตฟอร์มระดับชั้นนำที่รองรับรูปแบบการใช้งานที่ท้าทายสำหรับองค์กร  ทั้งนี้ รายงาน Magic Quadrant สำหรับแพลตฟอร์มแอปพลิเคชั่น Low-Code ระดับองค์กร ระบุว่า “ภายในปี 2568 ราว 70% ของแอปพลิเคชั่นใหม่ที่พัฒนาโดยองค์กรจะใช้เทคโนโลยี Low-Code หรือ No-Code”  การใช้แพลตฟอร์มLow-Code ไม่ได้หมายความว่านักพัฒนาจะถูกแทนที่ด้วยผู้ใช้ในสายงานธุรกิจ (เพื่อให้เข้าใจความแตกต่างระหว่าง Low-Code และ No-Code กรุณาอ่านบล็อกโพสต์นี้)  ที่จริงแล้ว แพลตฟอร์ม Low-Code จะช่วยขจัดความยุ่งยากซับซ้อนบางอย่างที่นักพัฒนามักจะพบเจอในการสร้างแอปฯ หรือระบบ และแพลตฟอร์มที่ดีที่สุดจะช่วยให้วิศวกรซอฟต์แวร์สามารถควบคุมส่วนต่างๆ ได้อย่างละเอียดและครบถ้วน

เป้าหมายหลักคือ เพื่อให้แพลตฟอร์มดังกล่าวทำงานซ้ำ ๆ ที่น่าเบื่อ เช่น การจัดการความเชื่อมโยง การตรวจสอบโค้ด และการสร้างแบบอัตโนมัติ ซึ่งจะช่วยให้นักพัฒนาสามารถโฟกัสการทำงานในส่วนสำคัญ ๆ ที่จะสร้างความแตกต่าง แทนที่จะต้องเสียเวลาไปกับการจัดการดูแลงานทั่วไป

4. แพลตฟอร์มคลาวด์เนทีฟ

ในเรื่องที่เกี่ยวกับ SaaS ความแพร่หลายที่เกิดขึ้นอย่างรวดเร็วของคลาวด์แอปพลิเคชั่นใหม่ๆ ส่งผลให้เกิดความเปลี่ยนแปลงในด้านเศรษฐศาสตร์และจังหวะเวลาของ “การสร้างแอป เมื่อเทียบกับการซื้อ” เนื่องจากการใช้ SaaS อย่างกว้างขวางนอกจากจะต้องใช้งบประมาณเพิ่มสูงขึ้นแล้ว ยังกลายเป็นอีกรูปแบบหนึ่งของหนี้ทางเทคนิค (Technical Debt) กล่าวคือ การที่ผู้ใช้ต้องสลับไปมาระหว่างระบบต่างๆ หลายระบบย่อมจะบั่นทอนประสบการณ์การใช้งาน ทั้งยังส่งผลกระทบต่อธุรกิจอย่างหลีกเลี่ยงไม่ได้ เพื่อปรับปรุงความคล่องตัวของธุรกิจบนระบบที่ถูกใช้งานโดยลูกค้า พาร์ทเนอร์ และพนักงาน จำเป็นที่จะต้องปรับใช้การพัฒนาแอปฯ แบบคลาวด์เนทีฟในรูปแบบใหม่ ซึ่งรองรับการใช้งานแบบกระจัดกระจาย ปรับขนาดได้ตามต้องการ และช่วยให้สามารถสร้างแอประดับองค์กรที่ยืดหยุ่นสำหรับจุดประสงค์การใช้งานที่เฉพาะเจาะจง และช่วยเพิ่มความคล่องตัวให้แก่องค์กร

การเพิ่มขึ้นอย่างรวดเร็วของบริการเว็บที่นำเสนอโดยผู้ให้บริการรายใหญ่ จากเมื่อ 5 ปีที่แล้วที่มีอยู่ประมาณ 30 บริการ ปัจจุบันมีมากถึง 250 บริการที่นำเสนอโดยผู้ให้บริการ IaaS หนึ่งราย นับเป็นอีกหนึ่งอุปสรรคสำคัญสำหรับนักพัฒนาในองค์กรธุรกิจที่ต้องการสร้างแอปพพลิเคชั่นแบบคลาวด์เนทีฟ เพื่อเอาชนะปัญหาท้าทายดังกล่าว แพลตฟอร์มการพัฒนาแบบคลาวด์เนทีฟจะต้องช่วยให้ทีมงานฝ่ายพัฒนามุ่งเน้นการจัดการสายธารคุณค่า (Value Stream) สำหรับผลิตภัณฑ์ดิจิทัลที่นำเสนอ แทนที่จะปล่อยให้บุคลากรฝ่ายวิศวกรรมต้องวุ่นวายอยู่กับการจัดการโครงสร้างพื้นฐานเพียงอย่างเดียว

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

 5. DesignOps

DesignOps จำเป็นต้องอาศัยการประสานงานร่วมกันอย่างใกล้ชิดระหว่างทีมงานฝ่ายออกแบบและนักพัฒนาส่วน Front-End (รวมถึงการใช้คลังข้อมูลและเครื่องมือร่วมกัน และการแลกเปลี่ยนสินทรัพย์ต่าง ๆ) ซึ่งจะช่วยส่งเสริมการทำงานร่วมกันของทีมงานฝ่ายผลิตภัณฑ์ภายในองค์กร และรองรับการนำเสนอประสบการณ์ที่สอดคล้องกันสำหรับการใช้งานผลิตภัณฑ์

ในปี 2565 นับเป็นครั้งแรกที่งบประมาณด้านไอทีและการพัฒนาแอพสะท้อนสภาพความเป็นจริงของการทำงานแบบไฮบริด เพราะประสบการณ์สำหรับพนักงานและพาร์ทเนอร์มีความสำคัญเทียบเท่ากับประสบการณ์สำหรับลูกค้า และจะนำไปสู่จุดที่เรียกว่า Hyperadoption หรือการใช้งานแอปพลิเคชั่นอย่างกว้างขวางและบ่อยครั้ง ซึ่งจะช่วยให้ธุรกิจมีความคล่องตัวเพิ่มมากขึ้น

เนื่องจากองค์กรได้รับแรงกดดันในการนำเสนอผลิตภัณฑ์ดิจิทัลเพิ่มมากขึ้น ควบคู่ไปกับการกระตุ้นให้เกิดการยอมรับในหมู่ผู้ใช้งานตามเป้าหมายที่กำหนด จึงจำเป็นที่จะต้องจัดการการออกแบบในขอบเขตที่กว้างขวาง พร้อมทั้งลดหนี้ทางเทคนิคและหนี้ที่เกิดจากการพัฒนา UX ที่ไม่เหมาะสม และให้ความสำคัญกับแนวทาง DesignOps เป็นหลัก

6. ความสามารถในการตรวจสอบ (Observability)

ควบคู่ไปกับส่วนงาน DesignOps ผู้บริหารฝ่ายวิศวกรควรจะลงทุนในเทคโนโลยีด้านการตรวจสอบ (Observability) เพื่อรองรับการใช้งานของผู้ใช้จำนวนมาก  ระบบตรวจสอบพฤติกรรมของผู้ใช้บนมาตรฐานเปิด เช่น Open Telemetry สำหรับการตรวจสอบบันทึกข้อมูลและดัชนีเพื่อรองรับแผนขยายการใช้งาน จะช่วยให้ทีมงานฝ่ายผลิตภัณฑ์ดิจิทัลสามารถกระตุ้นการใช้งานในหมู่ผู้ใช้ในระดับที่เหนือกว่า ซึ่งในอดีตเป็นเรื่องยากที่จะบรรลุเป้าหมายนี้

7. การมุ่งเน้น PWA

Progressive Web App (PWA) ผสานรวมฟังก์ชั่นของแอปฯ ที่ติดตั้งในอุปกรณ์ เข้ากับความสะดวกในการเข้าถึงของเว็บไซต์ โดยไม่ต้องมีการดาวน์โหลดแอพผ่านทางแอปสโตร์  ทั้งนี้ PWA มีลักษณะคล้ายกับแอปฯ ที่ติดตั้งภายในเครื่อง กล่าวคือ สามารถทำงานแบบออฟไลน์ ส่งข้อความแจ้งเตือน และเข้าถึงฮาร์ดแวร์ของอุปกรณ์ เช่น กล้อง หรือ GPS  นอกจากนี้ ประสบการณ์การใช้งานก็คล้ายกับแอปที่ติดตั้งบนอุปกรณ์มือถือและคอมพิวเตอร์เดสก์ท็อป โดยไม่จำเป็นดาวน์โหลดหรืออัพเดตแอปให้ยุ่งยาก และอีกหนึ่งข้อดีก็คือ สามารถทำงานได้อย่างมีประสิทธิภาพบนการเชื่อมต่อที่ช้าหรือไม่เสถียร

PWA จะกลายเป็นที่แพร่หลายอย่างมากในช่วงปี 2565 เพราะรองรับการเชื่อมต่อได้อย่างยืดหยุ่นและไม่ถูกต่อต้านจากผู้ใช้งาน (ซึ่งไม่ต้องการติดตั้งแอปจำนวนมากบนอุปกรณ์) ที่จริงแล้ว มีข้อโต้แย้งด้านเทคนิคที่สมเหตุสมผลสำหรับการจูงใจให้นักพัฒนาและผู้บริหารฝ่ายซอฟต์แวร์ปรับใช้แนวคิดที่มุ่งเน้น PWA เป็นหลัก แต่ขณะเดียวกันก็มีปัจจัยกระตุ้นการเปลี่ยนแปลงในส่วนที่เกี่ยวกับประสบการณ์ดิจิทัลด้วยเช่นกัน เนื่องจาก:

1. จากมุมมองของผู้ใช้งาน PWA ใช้งานง่ายบนอุปกรณ์มือถือ (ไม่ต้องดาวน์โหลดผ่านแอพสโตร์) และใช้ทรัพยากรในเครื่องเพียงเล็กน้อย
2. จากมุมมองของนักพัฒนา PWA สามารถเปลี่ยนแปลงได้เร็วกว่ามาก เมื่อเทียบกับแอพที่ติดตั้งในเครื่อง และยังดูแลรักษาได้ง่ายกว่าอีกด้วย
3. สำหรับทีมงานฝ่ายพัฒนา PWA มีข้อดีที่ต่างจากแอปที่ติดตั้งในเครื่อง เพราะใช้โค้ดเบสชุดเดียวสำหรับทุกอุปกรณ์ สามารถค้นหาได้ด้วยเสิร์ชเอนจิ้น และมีขนาดเล็ก