เจ้าของกำหนดนโยบาย สถาปนิกบังคับใช้

มีให้อ่านอีก 28 ภาษา

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

บทที่ 5 ของ Data Architect ส่วนที่ 1: การเป็นสถาปนิกข้อมูล ก่อนหน้า: ทำความเข้าใจข้อมูลองค์กร

พูดคำว่า “ธรรมาภิบาลข้อมูล” แล้วคนนึกถึงการประชุม: คณะกรรมการ นโยบาย เอกสารที่ไม่มีใครอ่าน ผมถามคำถามที่ต่างออกไปทุกครั้ง: นโยบายถูกบังคับใช้ที่ไหน?

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

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

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

ภาพสร้างด้วย AI

จุดยืนในบทนี้

ดำเนินโปรแกรมตามวิธีที่บริษัททำงาน: แบบรวมศูนย์ แบบกระจาย (federated) หรือแบบผสม สถาปนิกต้องรู้ว่าใครเป็นผู้อนุมัตินโยบาย
เจ้าของเรกคอร์ดไม่ใช่เจ้าของข้อมูล ฟิลด์ Owner ขับเคลื่อนการมอบหมายและการเข้าถึง ความรับผิดชอบต่อข้อมูลอยู่กับฝ่ายธุรกิจ
การสร้างแบบเปิดหรือแบบล็อกขึ้นอยู่กับธรรมาภิบาลรอบข้อมูล แบบเปิดใช้ได้สำหรับ org ขนาดเล็กและกลางส่วนใหญ่ ล็อกเมื่อบัญชีถูกจัดการเป็นข้อมูลหลักใน ERP หรือซิงก์กับ ERP ทางสายกลางคือประเภทเรกคอร์ดชั่วคราวที่แปลงเป็นแบบที่มีธรรมาภิบาลอย่างมีการควบคุม
ถ้า ERP เป็นตัวหลักของฟิลด์ใด คุณไม่ได้กำลังเปลี่ยนมัน คุณกำลังขอเปลี่ยนมัน golden record เป็นแบบผสม: ฟิลด์ข้อมูลหลักของ ERP ไหลเข้ามา ฟิลด์ของ Salesforce เองไม่เคยไหลกลับไป และโฟลว์สองทางต้องมีกฎสำหรับการชนกัน
จัดประเภทฟิลด์ที่อ่อนไหว ไม่ใช่ทุกฟิลด์ จัดทำเอกสารอย่างกว้างขวาง จัดประเภทอย่างตั้งใจ เก็บทั้งเมทาดาทาธุรกิจและเมทาดาทาทางเทคนิค
สอนเรื่องกฎระเบียบ สถาปนิกหลายคนไม่เคยได้ยินกฎหมายนอกภูมิภาคของตัวเอง และกฎหมายเหล่านี้กำหนดรูปการออกแบบระบบ
ใช้โมเดลความยินยอมที่มีมาให้ ทุกครั้งที่ทำได้ แทนที่จะสร้างใหม่
สำหรับสิทธิที่จะถูกลืม ให้ควบคุมก่อนว่าข้อมูลส่วนบุคคลไปที่ไหน การลบเกิดขึ้นไม่บ่อยและทำได้ยาก ออกแบบให้ข้อมูลส่วนบุคคลไปลงในที่ไม่กี่แห่ง แล้วตามล่าสำเนาทุกชุด: ประวัติฟิลด์ ที่เก็บถาวร สำเนาเพื่อการวิเคราะห์ ดัชนีการค้นหา และบทสนทนาของเอเจนต์ ก่อนที่เวลาจะหมด
Shield คือคำตอบสำหรับข้อกำหนดด้านกฎระเบียบสำคัญ อย่างการเข้ารหัสข้อมูลที่จัดเก็บ พร้อมการแลกเปลี่ยนได้เสียที่คุณต้องออกแบบรองรับ
Field Audit Trail เมื่ออยู่ภายใต้กฎระเบียบ ประวัติฟิลด์มาตรฐานคือค่าเริ่มต้น
ตั้งค่า Event Monitoring ก่อนที่คุณจะต้องใช้ และส่งเหตุการณ์ไปยังที่เก็บอย่าง Splunk คุณไม่ควรเจอปัญหาแล้วเพิ่งพบว่าไม่ได้เก็บมันไว้

วงจรชีวิตข้อมูลที่มีธรรมาภิบาล

Click to enlarge

เจ็ดคำถามตลอดชีวิตของข้อมูล เครื่องมือสนับสนุนนโยบาย แต่ไม่ได้กำหนดนโยบาย

เส้นทางผ่านบทนี้

หกโมดูล แต่ละโมดูลอ่านแยกกันได้

ธรรมาภิบาลถูกออกแบบไว้ใน org เจ้าของ ผู้ดูแลข้อมูล และผู้ปฏิบัติการระบบ แบบรวมศูนย์ แบบกระจาย หรือแบบผสม เจ้าของเรกคอร์ดเทียบกับเจ้าของข้อมูล การเปลี่ยนทุกนโยบายเป็นจุดบังคับใช้
กันข้อมูลไม่ดีออกไป “ดีพอ” ในฐานะคำนิยามทางธุรกิจ การสร้างแบบเปิดเทียบกับแบบล็อก เรกคอร์ดชั่วคราว และประเภทเรกคอร์ดสำหรับแต่ละโฟลว์ golden record แบบผสมและโฟลว์สองทาง การตัดสินใจเรื่องคุณภาพที่ทุกขอบเขตข้อมูล
รู้จักข้อมูลของคุณ: พจนานุกรม สายที่มา และการจัดประเภท เมทาดาทาธุรกิจและเมทาดาทาทางเทคนิค มันหมายถึงอะไร มาจากไหน ต้องปฏิบัติต่อมันอย่างไร และทำไมการจัดประเภทที่ไม่มีการบังคับใช้จึงเป็นแค่ของตกแต่ง
กฎหมายความเป็นส่วนตัวกำหนดการออกแบบ กฎหมายที่ควรรู้จัก สิ่งที่กฎหมายเหล่านั้นมีร่วมกัน (สิทธิ การโอนข้อมูล การแจ้งเหตุข้อมูลรั่วไหล ความรับผิดชอบ) และคำถามที่อยู่ได้นานกว่ากฎหมาย ข้อมูลนิรนามเทียบกับข้อมูลแฝง การปฏิบัติตามกฎไม่ใช่ผลิตภัณฑ์
ความยินยอมและสิทธิที่จะถูกลืม ความยินยอมในฐานะข้อมูล โมเดลความยินยอมมาตรฐาน นาฬิกาที่เดินอยู่บนทุกคำขอ และการออกแบบการลบก่อนที่คำขอแรกจะมาถึง
ปกป้อง เก็บรักษา และพิสูจน์ การแลกเปลี่ยนได้เสียของการเข้ารหัส sandbox การเก็บรักษา ประวัติฟิลด์และ Field Audit Trail และ Event Monitoring ที่ตั้งค่าไว้ล่วงหน้า

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

สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้

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

บทนี้เป็นแนวทางด้านสถาปัตยกรรม ไม่ใช่คำแนะนำทางกฎหมาย ทีมกฎหมายและการปฏิบัติตามกฎเป็นผู้ตัดสินว่ากฎหมายใดใช้บังคับและกำหนดอะไร สถาปนิกเปลี่ยนข้อกำหนดเหล่านั้นเป็นการออกแบบ

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

ศึกษาเพิ่มเติม

Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
Regulation (EU) 2016/679 (GDPR) (opens in a new tab), EUR-Lex (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)

ถัดไป: ข้อมูลหลักและตัวตน