הבעלים קובעים מדיניות, הארכיטקטים אוכפים אותה

זמין גם ב-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. בגלל זה הפרק ההוא בא קודם: מפת המערכות אומרת לכם עד כמה רחוק ממשל הנתונים צריך להגיע.

מנהל כספים מסביר את מדיניות הנתונים בזמן שהארכיטקט מצמיד את מה שאוכף כל אחת מהן: אימות, שיתוף ושמירה

התמונה נוצרה בבינה מלאכותית.

העמדות בפרק הזה

הפעילו את התוכנית כמו שהחברה עובדת: ריכוזית, פדרטיבית או היברידית; הארכיטקט צריך לדעת מי מאשר מדיניות.
בעלי הרשומה הם לא בעלי הנתונים. שדה Owner מניע הקצאה וגישה; האחריות לנתונים נמצאת אצל העסק.
יצירה פתוחה או נעולה תלויה בממשל שמסביב לנתונים. פתוח זה בסדר לרוב ה-orgs הקטנים והבינוניים; נעלו את זה כשחשבונות מנוהלים כנתוני אב ב-ERP או מסונכרנים איתו; הדרך האמצעית היא סוג רשומה זמני עם המרה מבוקרת לסוג המנוהל.
אם ה-ERP הוא מקור האב של שדה, אתם לא משנים אותו, אתם מבקשים לשנות אותו. רשומת הזהב היא היברידית: שדות האב של ה-ERP נכנסים, השדות של Salesforce עצמו אף פעם לא חוזרים, וזרימות דו-כיווניות צריכות כלל התנגשות.
סווגו את השדות הרגישים, לא כל שדה. תעדו בהרחבה; סווגו במכוון; שמרו גם מטא-דאטה עסקי וגם מטא-דאטה טכני.
למדו את הרגולציות. ארכיטקטים רבים מעולם לא שמעו על החוקים שמחוץ לאזור שלהם, והחוקים האלה מעצבים את תכנון המערכת.
השתמשו במודל ההסכמה המובנה (out-of-the-box) בכל מקום שאפשר, במקום לבנות אותו מחדש.
בזכות להישכח, שלטו קודם כול לאן מידע אישי הולך. מחיקה היא נדירה וקשה; תכננו כך שמידע אישי ינחת בכמה שפחות מקומות, ואז אתרו כל עותק: היסטוריית שדות, ארכיונים, העותקים האנליטיים, אינדקסי חיפוש ושיחות של סוכנים, לפני שהזמן נגמר.
Shield הוא התשובה לדרישות רגולטוריות מרכזיות כמו הצפנה במנוחה (at rest), עם פשרות שמתכננים בשבילן.
Field Audit Trail כשיש רגולציה. היסטוריית השדות הסטנדרטית היא ברירת המחדל.
הגדירו Event Monitoring לפני שאתם צריכים אותו, והזרימו את האירועים למאגר כמו Splunk. לא רוצים להיתקל בבעיה ורק אז לגלות שלא אספתם אותם.

מחזור החיים של נתונים מנוהלים

Click to enlarge

שבע שאלות לאורך חיי הנתונים. הכלים תומכים במדיניות; הם לא מגדירים אותה.

המסלול בפרק הזה

שש יחידות, כל אחת עומדת בפני עצמה.

ממשל הנתונים מתוכנן לתוך ה-org. בעלי נתונים, נאמני נתונים ואפוטרופוסים; ריכוזי, פדרטיבי או היברידי; בעלי הרשומה מול בעלי הנתונים; להפוך כל מדיניות לנקודת אכיפה.
לא להכניס נתונים גרועים. “טוב מספיק” כהגדרה עסקית; יצירה פתוחה מול נעולה, הרשומה הזמנית וסוג רשומה לכל זרימה; רשומת הזהב ההיברידית והזרימות הדו-כיווניות; החלטת איכות בכל גבול של נתונים.
הכירו את הנתונים שלכם: מילון, שושלת וסיווג. מטא-דאטה עסקי וטכני; מה הנתונים אומרים, מאיפה הם הגיעו, איך צריך לטפל בהם, ולמה סיווג בלי אכיפה הוא קישוט.
חוקי הפרטיות מעצבים את התכנון. החוקים שצריך לזהות, מה משותף להם (זכויות, העברות, הודעה על פריצת אבטחה, אחריותיות), והשאלות שיחיו יותר מהם; אנונימיזציה מול פסאודונימיזציה; ציות הוא לא מוצר.
הסכמה והזכות להישכח. הסכמה כנתונים, מודל ההסכמה הסטנדרטי, השעון שמתקתק על כל בקשה, ותכנון המחיקה לפני שהבקשה הראשונה מגיעה.
להגן, לשמור ולהוכיח. הפשרות של הצפנה, סביבות 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).

הבא: נתוני אב וזהות