ข่าวที่สร้างกระแสฮือฮาให้วงการธนาคารในรอบเดือนที่ผ่านมา คือการเปิดตัวแอพ 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 มีฐานเทคโนโลยีใหม่ๆ ให้ลองเล่นเยอะมาก
บวกกับมีลูกค้าขนาดใหญ่ระดับหลายสิบล้านคน
ซึ่งมีองค์กรไม่กี่แห่งในไทยที่มีลูกค้าระดับนี้
ดังนั้นการเข้ามาใช้เทคโนโลยีใหม่ๆ รองรับลูกค้าจำนวนมากขนาดนี้
จึงเป็นปัจจัยที่ดึงดูดคนเข้ามาได้ เพราะมันท้าทายนั่นเอง
ที่มา: Blognone
ไม่มีความคิดเห็น:
แสดงความคิดเห็น