ข่าวที่สร้างกระแสฮือฮาให้วงการธนาคารในรอบเดือนที่ผ่านมา คือการเปิดตัวแอพ SCB Easy เวอร์ชันใหม่ ที่มีจุดขายคือปรับหน้าตาโฉมใหม่ และการกดเงินจากตู้เอทีเอ็มแบบไม่ต้องใช้บัตร

แต่ในงานแถลงข่าวเปิดตัวแอพ SCB Easy ทางธนาคารไทยพาณิชย์ไม่ได้พูดแต่เรื่องตัวแอพอย่างเดียว เพราะพูดถึง "สถาปัตยกรรม" ฝั่งเซิร์ฟเวอร์ที่ทำงานอยู่เบื้องหลัง ระบบฝั่งเซิร์ฟเวอร์ตัวนี้ถูกเขียนขึ้นมาใหม่ทั้งหมด และใช้แนวทางแบบ microservices ที่กำลังได้รับความนิยมในบริษัทไอทีสมัยใหม่ (แนวทางนี้เอามาจาก Netflix)

ทาง Blognone จึงไม่พลาดโอกาสที่จะขอสัมภาษณ์ SCB ในเรื่องนี้ และเราได้คุยกับ__คุณธนา โพธิกำจร Head of Digital Banking__ ผู้ที่ขึ้นเวทีพรีเซนต์สถาปัตยกรรมนี้ในงานแถลงข่าวนั่นเอง

สถาปัตยกรรมเดิมของ SCB Easy ใช้มานาน 15 ปี!!

คุณธนา เริ่มจากเล่าว่าตัวสถาปัตยกรรมเบื้องหลังเว็บไซต์ SCB Easy ซึ่งเป็น internet banking รายแรกๆ ถูกพัฒนามาตั้งแต่ปี 2001-2002 โดยเริ่มจากการเป็น web frontend ที่เขียนด้วย ASP

ที่ผ่านมา 15 ปี ระบบตัวนี้ไม่เคยถูกเปลี่ยนแปลงใหญ่เลย มีแต่โมกันแล้วโมกันอีก (บวกด้วยอัพเกรดเป็น ASP.NET เท่านั้น) แถมตัวมันเองใช้โครงสร้างแบบ monolithic การแก้ไขอะไรก็ตามจึงเป็นเรื่องยากมาก

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

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

SCB Easy Platform ตามแนวทางเดียวกับ Netflix

โจทย์ของการออกแบบ SCB Easy Platform ไม่มีอะไรสำคัญไปกว่า "ความเรียบง่าย" ทีมงานต้องการให้มันสะอาดที่สุดเท่าที่เป็นไปได้ ส่วนปรัชญาข้ออื่นที่นำมาใช้ก็คือ "microservices" ที่แยกบริการย่อยๆ ออกจากกัน เพื่อให้แก้ไขได้เฉพาะส่วนโดยไม่กระทบส่วนอื่น และรองรับการขยายตัวของทราฟฟิกการใช้งานในอนาคต

ต้นแบบของ SCB Easy Platform มาจากสถาปัตยกรรมของ Netflix ที่เปิดซอร์สต่อสาธารณะ ซึ่งหลายองค์กรก็นำแนวทางของ Netflix มาใช้เช่นกัน

คุณธนา บอกว่าเนื่องจากเป็นการออกแบบสถาปัตยกรรมใหม่หมด และมีต้นแบบที่ใช้งานได้ดีอยู่แล้ว จึงพยายามยึดแนวทางให้สถาปัตยกรรม "สวย" ที่สุดเอาไว้ตั้งแต่แรก

จาก Frontend เข้าสู่ระบบภายใน

ฝั่งของ frontend ใช้เทคโนโลยี Experience API ของบริษัท Backbase ที่ธนาคารทั่วโลกใช้กันสำหรับเป็น Frontend Content Management ส่วนตัวไคลเอนต์ก็เขียนขึ้นเอง มีทั้งเว็บและแอพ

บทเรียนของ SCB ในการสร้างแอพ SCB Easy คือต้องหาความสมดุลระหว่างการเขียนแอพแบบเนทีฟ และการใช้ webview เข้าช่วย จากประสบการณ์คือเนทีฟดีกว่าเว็บมาก เพราะการทำเว็บให้เนียนสวยเท่าเนทีฟเป็นเรื่องยากกว่ามาก แต่การใช้เนทีฟก็มีข้อเสียคือทำให้แอพมีขนาดบวมขึ้นเรื่อยๆ ถ้าเรายัดทุกอย่างลงไป ดังนั้นอะไรที่ใช้ไม่บ่อยนัก นานๆ ใช้ที สร้างเป็นเว็บดีกว่า

เรื่อง UI ของแอพที่มีทั้งคนชอบและไม่ชอบ เรื่องนี้แยกเป็น 2 แนวทางตั้งแต่ช่วงการออกแบบแล้ว คนที่ใช้ฟีเจอร์ทำธุรกรรมบ่อยๆ จะรู้สึกว่ารกไปหน่อย ทีม UX เองก็อยากให้ลูกค้าทำคำสั่งในแอพให้เสร็จเร็วๆ แต่ก็สวนทางกับยุทธศาสตร์ของธนาคารที่อยากเป็นมากกว่าธนาคาร คำถามในเชิงการออกแบบคือจะหาจุดสมดุลอย่างไร

เสียงตอบรับหลังแอพออกไปแล้วคือกลุ่ม power user บ่นว่าใช้งานยากขึ้น แต่ที่ผิดคาดคือกลุ่มลูกค้าทั่วไปกลับชอบ เพราะเกิดความสนใจ เข้าไปดูได้มากขึ้นว่าแอพของธนาคารทำอะไรได้เยอะกว่าที่คิดมากด้วย

API Gateway เปิดการเชื่อมต่อสู่ภายนอก

แพลตฟอร์มตัวนี้มี API Gateway เพื่อให้ระบบ backend สามารถสื่อสารกับ frontend ใดๆ ก็ได้ รวมถึงการเชื่อมต่อจากพาร์ทเนอร์ หรือสตาร์ตอัพสายฟินเทค เข้ามาเรียกใช้ API ได้ด้วย

SCB ให้ความสำคัญกับการเปิด API มาก สังเกตได้จากแอพ SCB Easy ตัวใหม่ใช้การออกแบบแนว tile ที่มีไอคอนเพิ่มขึ้นได้เรื่อยๆ เพื่อเปิดให้พาร์ทเนอร์สามารถเข้ามานำเสนอบริการของตัวเองต่อลูกค้าของ SCB Easy จำนวน 4-5 ล้านคนได้จากตัวแอพเลย

ตอนนี้ frontend ของ SCB เองก็จะเรียกข้อมูลต่างๆ ในฝั่ง backend ผ่าน public API กันอย่างเสมอภาค ทัดเทียมกับแอพภายนอกที่มาเชื่อมต่อ ไม่มีท่าพิเศษให้กับแอพของ SCB โดยเฉพาะ เพื่อสร้างฐานตัว API ให้มั่นคงสำหรับอนาคตเมื่อเปิดการเชื่อมต่อให้คนนอก

Hyper-scalable รองรับการขยายตัวในอนาคต

ฝั่งของตัวระบบหลัก ที่ออกแบบเป็น microservices ตามแนวทางสมัยใหม่ ก็มีโจทย์ว่าทำอย่างไรจะรองรับการขยายตัวแบบ hyperscale ในอนาคตได้

ตรงนี้ทีม SCB ใช้โซลูชันของ Netflix สองตัวคือ Edge Service ที่เอาไว้กระจายงาน (ใช้ Zuul) ส่วนการจัดการโครงสร้างพื้นฐานใช้ Eureka สำหรับ provisioning และ load balancing

บทเรียนของ SCB พบว่าการออกแบบ microservice ดูแลง่ายจริง แต่กินทรัพยากรเยอะ ดังนั้นจะต้องเตรียมจำนวนเครื่องไว้ให้ดี โครงสร้างพื้นฐานทั้งหมด SCB ดูแลโฮสต์เอง ไม่ได้อยู่บนคลาวด์ โดยใช้คลาวด์เฉพาะงานส่วน dev/testing environment เท่านั้น

ส่วนงานอื่นๆ อย่างการทำ logging ใช้ Elasticsearch และการมอนิเตอร์การใช้งานใช้ Firebase ของกูเกิล โดยระวังเรื่องการไม่ส่งข้อมูลที่ระบุตัวลูกค้าออกไปยังกูเกิล เพราะระวังเรื่องการกำกับดูแลจากธนาคารแห่งประเทศไทย

Intelligence ส่วนงานวิเคราะห์ข้อมูล

อีกส่วนที่ SCB ให้ความสำคัญคือการวิเคราะห์ข้อมูล เรื่องนี้เป็นนโยบายที่มาจากซีอีโอโดยตรง ว่าอยากให้ธนาคารมีวัฒนธรรมที่ตัดสินใจบนพื้นฐานของข้อมูล (data-driven culture) ปัญหาในเชิงเทคนิคคือธนาคารมีระบบไอทีหลากหลาย ข้อมูลเก็บอยู่คนละที่

ทางออกจึงเป็นแนวคิด data lake คือเทข้อมูลทั้งหมดมาเก็บรวมกันตรงกลาง โซลูชันที่ใช้ก็เป็น Hadoop ตามมาตรฐานของวงการ (ใช้ของ Cloudera) จากนั้นก็ใส่ตัววิเคราะห์ข้อมูลเข้ามาอีกหลายตัว เช่น Splunk

ส่วนเป้าหมายของการวิเคราะห์ข้อมูล อย่างในแอพ SCB Easy ควรจะวิเคราะห์และพยากรณ์ได้ว่า ลูกค้าจะอยากทำอะไรเป็นลำดับต่อไป เราควรนำเสนอให้ลูกค้าได้เลย ไม่ใช่ว่าให้ลูกค้าต้องมานั่งหาเอง ตอนนี้ก็เริ่มทดสอบฟีเจอร์นี้เป็นการภายในบ้างแล้ว

กระบวนการทำงานก็สำคัญไม่แพ้กัน

นอกจากเรื่องสถาปัตยกรรมแล้ว การทำงานของคนในทีมก็สำคัญไม่แพ้กัน ตอนแรกทาง SCB อยากทำ agile เหมือนคนอื่นๆ แต่พบว่าโครงการนี้ใหญ่มาก เพราะต้องเขียนระบบใหม่หมด ในเวลาที่สั้นมากคือ 10 เดือน การเปลี่ยนวิธีทำงานพร้อมกับเปลี่ยนสถาปัตยกรรมครั้งใหญ่ คงต้องเลือกอย่างใดอย่างหนึ่ง

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

SCB เลือกใช้บริษัทภายนอกหลายรายเข้ามาช่วยพัฒนา แต่แนวทางการจ้างงานแบบเก่าที่จ้างเป็นโครงการใหญ่ๆ ตาม requirement ก็ใช้ไม่ได้แล้วอีกเหมือนกัน เพราะโครงการซอฟต์แวร์ยุคใหม่ requirement เปลี่ยนแปลงตลอดเวลา ต้องปรับตัวกันเร็วมาก ก็ต้องเปลี่ยนวิธีการจ้างมาเป็นแบบตามวันทำงาน (man-day) แทน

บทเรียนของฝ่ายไอทีในธนาคารใหญ่

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

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

บทเรียนของทีม SCB Digital มีด้วยกัน 3 ข้อคือ

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

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