Data Mesh Platform

ความหวังในการแชร์ข้อมูลร่วมกันในอนาคต

JUN 22, 2020

ปีที่ผ่านมามีกระแสเกี่ยวกับ Data Lake หรือ การรวบรวมข้อมูลไว้ที่คลังเก็บข้อมูลกลาง ซึ่งใช้เป็นพื้นที่สำหรับบันทึกข้อมูลได้ทุกชนิด ไม่ว่าจะเป็น Database ภาพ เสียง หรือตัวหนังสือ เพื่อที่จะนำไปต่อยอดทำการวิเคราะห์ (Analytics) หาข้อมูลเชิงลึกต่าง ๆ เกิดขึ้นในหลายองค์กรทั้งภาครัฐและเอกชน แต่ที่ผ่านมาถือว่ายังไม่ประสบความสำเร็จเท่าไหร่นัก เพราะมีหลาย องค์กรที่เกี่ยวข้องกับการจัดเก็บรวบรวมข้อมูล ยังไม่สามารถแชร์ข้อมูลร่วมกันได้ ผมจึงขอจำแนกปัญหาที่เกิดขึ้น ดังนี้

 

  1. ขาดเจ้าภาพในระดับผู้บริหารและกลยุทธ์ภาพกว้าง (Lack of Strategic Vision/ Leadership Support) มีการจัดตั้งโครงการขึ้นเพื่อจัดซื้อระบบเก็บข้อมูลมากกว่าการนำมาใช้เป็นยุทธศาสตร์ที่ขับเคลื่อนองค์กร อีกทั้งยังขาดผู้บริหารและผู้นำที่มีความชัดเจนที่จะนำข้อมูลไปใช้เพื่อประโยชน์ในมิติต่าง ๆ เราจึงควรร่วมมือกันวางแผนยุทธศาสตร์ให้รอบด้าน เพื่อสื่อสารให้ทุกภาคส่วนได้เข้าใจถึงประโยชน์ที่จะได้จากการร่วมมือกัน

  2. จุดประสงค์ไม่ชัดเจน (Unclear Objective) จึงเกิดเป็นคำถามว่า “รวมข้อมูลไปทำไม เก็บไปทำไม” เราจึงควรตั้งโจทย์ในการนำไปใช้ให้ชัดเจน เพื่อเกิดความเข้าใจและความร่วมมือในการรวบรวมข้อมูล

  3. การควบคุมจัดการและการเข้าถึงไม่ชัดเจน (Transparent Governance) องค์กรและหน่วยงานภายในองค์กรต่างมองว่า ข้อมูลเป็นทรัพย์สินที่แต่ละหน่วยงานเองก็ไม่อยากสูญเสียอำนาจในการเป็นเจ้าของ ดังนั้นควรมีการจัดการและสื่อสารขอบเขตของการนำไปใช้อย่างโปร่งใสและชัดเจน ทั้งในแง่ว่าใครสามารถเข้าถึงข้อมูลได้บ้าง ข้อมูลจะถูกนำไปใช้งานอะไร รวมทั้งให้หน่วยงานที่เป็นเจ้าของข้อมูลมีสิทธิ์กำหนดขอบเขตการใช้งานได้เอง จะยิ่งช่วยสร้างความอุ่นใจให้กับเจ้าของข้อมูลนั้น ๆ

  4. ขาดความเข้าใจและการเห็นประโยชน์ของการนำข้อมูลหลากหลายมิติจากที่ต่าง ๆ มาใช้ (Weak Data Literacy Culture) องค์กรควรสร้างวัฒนธรรมการเรียนรู้ในการใช้ข้อมูล รวมทั้งสร้างความร่วมมือของหน่วยงานเพื่อนำไปสู่เป้าหมายเดียวกัน ช่วยให้ผู้มีส่วนร่วมเห็นว่าการแบ่งปันข้อมูลจะสามารถสร้างประโยชน์ได้มากขึ้น แก้ปัญหาหรือมีส่วนช่วยบรรลุเป้าหมายของบริษัทในระดับที่ใหญ่ขึ้น เช่น เพื่อทำให้การทำงาน การขาย การหาลูกค้า การลดต้นทุน หรือทำให้ประสบการณ์ของลูกค้าดีขึ้น เป็นต้น

  5. ความไม่คุ้นชินกับโครงสร้างสถาปัตยกรรม (Lack of Data Lake Architecture knowledge) โครงสร้างสถาปัตยกรรมของ Data Lake (Data Lake Architecture) เป็นการรวมข้อมูลทั้งหมดเข้าสู่ศูนย์กลาง (Centralized) ซึ่งค่อนข้างฝืนกับความเคยชินขององค์กรและหน่วยงานต่าง ๆ ในการดูแลข้อมูลอยู่พอสมควร เพราะโดยปกติแล้ว องค์กรส่วนใหญ่จะมีการจัดเก็บข้อมูลแบบกระจาย (Distributed) ต่างคนต่างเก็บข้อมูลที่จำเป็นต่อการใช้งานในส่วนของตนเท่านั้น 

แผนผังด้านบนเป็นตัวอย่างของโครงสร้างสถาปัตยกรรม Data Mesh ของ ThoughtWorks ซึ่งมีแนวความคิดที่ตรงกันในการจัดการข้อมูล ที่แสดงให้เห็นว่ามีการแชร์ข้อมูลระหว่างแผนกที่มีข้อมูลแตกต่างกัน ได้แก่ แผนกดูแลข้อมูลลูกค้า (Customer Domain) แผนกปฏิบัติการ (Operation Domain) และแผนกการตลาด (Marketing Domain)           ซึ่งทำให้แต่ละแผนกสามารถดึงข้อมูลจากแผนกต่าง ๆ มาใช้ในการวิเคราะห์ (Analytics) และสร้างโมเดลหรือ Visualization ได้เอง

 

Data Mesh มีองค์ประกอบดังนี้

 

  1. Data product/ Service: เจ้าของข้อมูลจะคงสถานะความเป็นเจ้าของและมีสิทธิ์ในการดูแลข้อมูลโดยผู้ที่จะนำข้อมูลไปใช้ประโยชน์สามารถเข้าถึงได้ด้วย API (Application Programming Interface - การเรียกใช้โปรแกรมแบบพูดคุยกันได้) ซึ่งในทางปฏิบัติ ข้อมูลอาจถูกเก็บไว้ใน cloud หรือ storage โดยให้หน่วยงานที่ต้องการนำข้อมูลไปใช้ เข้าถึงได้ด้วย URL แต่ไม่สามารถแก้ไขข้อมูลหรือเป็นเจ้าของได้

  2. Discoverable data catalog: ต้องมีโครงสร้างพื้นฐานที่ช่วยทำให้การค้นหาข้อมูลภายในองค์กรมีประสิทธิภาพยิ่งขึ้น

  3. Self-serve platform: แพลตฟอร์มควรจะเอื้อประโยชน์ให้เจ้าของข้อมูลสามารถแชร์ข้อมูลและทำงานได้ง่าย สำหรับประเทศไทยอาจจะเพิ่มให้มีการบริหารจัดการหรือพัฒนา data product จากส่วนกลาง หากบางหน่วยงานไม่มีความสามารถที่จะทำได้ในเบื้องต้น

  4. Service Level; Objective (SLO) & Standardization: มีการกำหนดมาตรฐานข้อมูลและการให้บริการของข้อมูลที่ถูกต้องเชื่อถือได้ มีการจัดระเบียบข้อมูล (cleaning) และมีรายละเอียดอธิบายที่มาที่ไปของข้อมูล (Metadata) เพื่อให้ลูกค้าเข้าใจและใช้งานได้อย่างเหมาะสม

  5. Global access control: ควรมีการกำหนดมาตรการการเข้าถึงข้อมูล และการดูแลความปลอดภัยของข้อมูล เพื่อสร้างความเชื่อมั่นให้กับผู้เป็นเจ้าของข้อมูลในการแชร์ข้อมูลที่เป็นประโยชน์สำหรับการนำไปใช้แก้โจทย์ให้กับองค์กรต่าง ๆ

 

สุดท้ายนี้ แม้โครงสร้างทางเทคนิคจะทำได้ เช่น จัดเก็บข้อมูลให้อยู่ใน Cloud เดียวกัน แต่สิ่งสำคัญที่สุดคือ การสื่อสารและกระบวนการที่จะสร้างให้เกิดชุมชนของผู้ร่วมงาน (Community of Practice หรือ CoP) ที่จะช่วยให้เกิดการประสานงานในการแลกเปลี่ยนข้อมูลระหว่างกัน รวมทั้งการสร้างองค์ความรู้ในการนำข้อมูลไปใช้เพื่อตอบโจทย์งานต่าง ๆ และการสร้างกระบวนการที่จะช่วยกระตุ้นให้คนเห็นประโยชน์จากการแชร์ข้อมูล เพื่อทำให้การตัดสินใจแก้ปัญหาได้ดีขึ้น โดยสิ่งเหล่านี้จะเกิดขึ้นไม่ได้ถ้าไม่ได้รับการสนับสนุนจาก 2 ภาคส่วน ทั้งผู้มีอำนาจระดับบนไม่ว่าจะเป็นผู้บริหารหรือเจ้ากระทรวง และคนทำงาน เพื่อนำข้อมูลที่ได้จากการร่วมมือกันนี้ไปใช้แก้ปัญหาขององค์กรต่าง ๆ อย่างมีประสิทธิภาพสูงสุด

 

References:

https://martinfowler.com/articles/data-monolith-to-mesh.html

https://towardsdatascience.com/data-mesh-applied-21bed87876f2

https://softwareengineeringdaily.com/2019/07/29/data-mesh-with-zhamak-deghani/

https://www.youtube.com/watch?v=os5qkpoWKhQ

บทความโดย
คุณจรัล งามวิโรจน์เจริญ
Chief Data Scientist & VP of Data Innovation Lab
บริษัท เซอร์ทิส จำกัด

Related Posts

Sertis-x-Thaipub_organizational_resilien

CONTACT US

Bangkok Office

Sertis Co.,Ltd. 

Suite No.302, 3rd Floor

597/5 Sukhumvit Road,

Khlong Tun Nuea, Wattana, Bangkok, Thailand 10110

Singapore Office

Sertis International Pte. Ltd.

3 Pickering Street

#03-05 Singapore 048660

© 2020 Sertis Co.,Ltd. All rights reserved.

  • Sertis Facebook
  • Sertis Linkedin
  • Sertis Channel
Sertis-Logo_2020.png