מבחן ההפיכות

🌐 זמין גם ב-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)

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

תורגם בבינה מלאכותית. הקהילה עוד לא בדקה את התרגום. לקריאה באנגלית

יחידה 3 מתוך 7 בפרק לחשוב כמו ארכיטקט נתונים, הפרק הראשון בקורס Data Architect. כל יחידה עומדת בפני עצמה. הקודם: מודל הנתונים הוא השלד · הבא: ארכיטקטורה היא אמנות הפשרות

השאלה שהיחידה הזו עונה עליה: איך מבחינים בין החלטה ארכיטקטונית להחלטה רגילה?

ארכיטקטים מקבלים הרבה החלטות.

אבל לא כל החלטה היא החלטה ארכיטקטונית.

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

אז איך מבחינים ביניהן?

אני אוהב לשאול שאלה פשוטה:

כמה קשה יהיה להפוך את ההחלטה הזו בהמשך?

אני קורא לזה מבחן ההפיכות (Reversibility Test).

ככל שקשה יותר להפוך משהו, וככל שיותר דברים אחרים יהיו תלויים בו, כך מגיעה לו יותר תשומת לב ארכיטקטונית.

יש החלטות שזול לשנות

נתחיל ממשהו פשוט.

אנחנו קוראים לשדה Customer Category. חצי שנה אחר כך העסק מחליט שבעצם כולם קוראים לזה Customer Segment. אנחנו משנים את התווית. אולי יהיה צריך לעדכן קצת תיעוד ולהדריך מעט את המשתמשים, אבל זה לא אירוע ארכיטקטוני גדול. אבל נצטרך לחיות עם שם ה-API המקורי, כי לשנות אותו גורר השלכות גדולות הרבה יותר. אז זה אולי רק אומר להתמודד עם שינוי תווית, ועם הבלבול שיכול לבוא איתו.

קיבלנו החלטה. שינינו את דעתנו. המשכנו הלאה.

עכשיו השוו את זה להחלטה אחרת.

אנחנו יוצרים מזהה ללקוחות. אנחנו מחליטים מה המשמעות שלו, באיזה פורמט הוא משתמש ואיזו מערכת יוצרת אותו. ואז אנחנו מפרסמים אותו.

Salesforce משתמש בו. מחסן הנתונים משתמש בו. פלטפורמת האינטגרציה משתמשת בו. פורטל הלקוחות משתמש בו. חמש אפליקציות אחרות מתחילות לשמור אותו. דוחות וצינורות נתונים משתמשים בו. אולי בסוף גם הלקוחות רואים אותו.

שלוש שנים אחר כך מישהו אומר:

כנראה שלא היינו צריכים לתכנן את המזהה בצורה הזו.

זו שיחה שונה לגמרי.

ההבדל הוא לא שהחלטה אחת טכנית יותר מהשנייה.

ההבדל הוא הפיכות.

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

ארכיטקטורה יוצרת כוח משיכה

החלטה ארכיטקטונית נוטה לצבור דברים סביבה. אני חושב על זה כעל כוח משיכה.

בחרו מודל אובייקטים, ואוטומציה תיבנה סביבו.

בחרו מפתח, ומערכות אחרות יתחילו לשמור אותו.

בחרו היכן יישבו נתוני האב, ואינטגרציות יתחילו לזרום אליהם ומהם.

בחרו מודל שיתוף, ותהליכים עסקיים יתחילו להיות תלויים במי יכול לראות מה.

בחרו תבנית אינטגרציה, ומערכות יתחילו להיות תלויות בתזמון ובהתנהגות שלה.

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

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

בגלל זה חשוב שמודל הנתונים הוא “השלד”. אנחנו לא זהירים כי שינוי הוא דבר רע. אנחנו זהירים כי תלויות הופכות שינוי ליקר.

שאלו שתי שאלות

כשאני מסתכל על החלטת תכנון, אני שואל שתי שאלות:

כמה קשה להפוך את זה?

כמה דברים יהיו תלויים בזה?

הן קשורות, אבל לא זהות. משהו יכול להיות קל לשינוי מבחינה טכנית אבל עם מאות צרכנים. פעם נהגו לשנות תוויות של אובייקטים סטנדרטיים לשם הבהירות, למשל חשבון (Account) כ-”Customer”. קל לעשות. ואז מערכת אחרת רצתה להשתמש בחשבונות עבור שותפים, ולא יכלה. משהו אחר יכול להיות עם מעט צרכנים בלבד אבל לדרוש הגירה עצומה כדי לשנות אותו, כמו שם ה-API של אובייקט שיש אליו הפניות בהרבה מקומות פנימיים. אף אחד מבחוץ לא רואה אותו, אבל שם שגוי ממשיך לבלבל את הצוות. כל אחד מהם ראוי לתשומת לב.

חשבו על כמה החלטות נתונים נפוצות:

• איזה אובייקט של Salesforce מייצג את המושג העסקי הזה?
• מהו המזהה הייחודי?
• איזו מערכת היא מערכת הרשומה (system of record)?
• האם הנתונים האלה מועתקים ל-Salesforce או שניגשים אליהם במקום אחר?
• האם זה אובייקט אחד או כמה אובייקטים קשורים?
• מי הבעלים של הנתונים, וכמה זמן אנחנו שומרים אותם?
• מהם גבולות הגישה שלנו כברירת מחדל?
• איך הנתונים האלה נעים בין מערכות?

אלה שונות מאוד מההחלטה איפה שדה מופיע בדף Lightning. גם עיצוב הדף חשוב. אבל המחיר של טעות שונה.

Click to enlarge

חשבו על רדיוס הפגיעה

דרך נוספת לחשוב על הפיכות היא רדיוס הפגיעה (blast radius): אם אשנה את ההחלטה הזו, מה עוד זז?

נניח שמשהו שמידלנו כשדה בעצם צריך להפוך לאובייקט בן. זה לא רק שינוי סכמה. מה קורה לנתונים הקיימים? לדוחות, לאינטגרציות שמצפות לשדה הזה, ל-Apex ול-Flows שמפנים אליו, לאבטחה, לניתוחים, לסוכן בינה מלאכותית שהפעולות שלו תלויות במבנה המקורי?

ככל שהרדיוס גדול יותר, כך צריך לקבל את ההחלטה המקורית בזהירות רבה יותר.

זו גם הסיבה שארכיטקטים צריכים להסתכל מעבר לחלק שלהם במערכת. מבפנים, מתוך Salesforce, שינוי יכול להיראות קל. מנקודת המבט של הארגון כולו, הוא עלול להשפיע על שתים-עשרה מערכות אחרות.

החלטות ארגוניות והחלטות Salesforce

ארכיטקט נתונים חושב בשתי רמות.

בתוך Salesforce, אנחנו מחליטים על אובייקטים, קשרים, מפתחות, נפח, גישה, אוטומציה, ועל האופן שבו הנתונים מתנהגים בפלטפורמה.

ברמת הארגון כולו, אנחנו שואלים שאלות רחבות יותר. איפה הלקוח (Customer) באמת נמצא? מי הבעלים של המוצר (Product)? איזו מערכת יוצרת הזמנה (Order)? מהו המזהה הסמכותי שלנו? איזה מידע מועתק בין מערכות, ואיזה נשאר במקומו?

שתי הרמות צריכות להתחבר. ראיתי הטמעות Salesforce שבהן המודל הפנימי היה הגיוני לגמרי בפני עצמו, אבל לא התאים לארגון שסביבו. זה לא מספיק. המבנים של Salesforce צריכים להיות מיוצגים ברמת הארגון, והחלטות ארגוניות צריכות לזרום בחזרה אל Salesforce.

ארכיטקטורה היא תנועה דו-סטרית.

Click to enlarge

האטו בהחלטות היקרות

אחת הסכנות בטכנולוגיה היא שההחלטות שהכי קל לממש יכולות להיראות כמו ההחלטות שהכי קל לקבל. זה לא אותו דבר.

ליצור עוד אובייקט מותאם אישית זה קל. ליצור עוד שדה זה קל. לחבר עוד API נעשה קל יותר, ובינה מלאכותית הופכת את כל זה לקל עוד יותר.

אבל קלות המימוש לא אומרת לנו כמעט כלום על המחיר של ההחלטה הארכיטקטונית.

לפני החלטה שקשה להפוך, האטו מספיק זמן כדי לשאול: איזו בעיה אנחנו באמת פותרים? אילו חלופות שקלנו? מה אנחנו מניחים? מה קורה כשהנפח גדל, וכשהעסק משתנה? מה עוד יהיה תלוי בזה? מה קורה אם אנחנו טועים?

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

כתבו למה

יש עוד בעיה עם החלטות חשובות: אנשים שוכחים למה הן התקבלו.

מישהו מסתכל על ארכיטקטורה שלוש שנים אחר כך ושואל: “למה שמישהו יתכנן את זה ככה?” לפעמים התשובה היא שזה היה תכנון גרוע. זה קורה. אבל לפעמים הייתה סיבה טובה מאוד: מגבלה של הפלטפורמה שכבר לא קיימת, דרישה רגולטורית, מערכת אחרת שלא יכלה לתמוך בגישה המועדפת, פשרה שהתקבלה ביודעין כדי לעמוד בדדליין.

אם אנחנו מתעדים רק מה החלטנו ולא למה, לארכיטקט הבא אין שום דרך לדעת.

להחלטות משמעותיות, כתבו את זה. זה לא צריך להיות מסמך של 50 עמודים. רשומת החלטה שימושית יכולה להיות קטנה מאוד:

הקשר: איזו בעיה אנחנו פותרים?

אפשרויות: אילו חלופות מציאותיות שקלנו?

החלטה: במה בחרנו?

השלכות: מה אנחנו מרוויחים, ועל מה אנחנו מוותרים?

בעלים: מי אחראי להחלטה הזו?

סקירה: איזו סיבה או תאריך צריכים לגרום לנו לחזור אליה?

הערך הוא לא המסמך. הערך הוא שמירת הנימוק.

וכשהחלטה משתנה, אל תמחקו את המקורית. החליפו אותה בהחלטה חדשה. ההחלטה שהייתה נכונה ב-2027 אולי לא תהיה נכונה ב-2030, כי הנפחים, העסק, Salesforce וההבנה שלנו משתנים כולם. מה שאני רוצה לשמור הוא הסיפור: זה היה ההקשר, זו הייתה ההחלטה ולמה, זה מה שהשתנה, וזה מה שאנחנו מחליטים עכשיו. זה שווה הרבה יותר מלהעמיד פנים שתמיד ידענו את התשובה.

Click to enlarge

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

דעו אילו החלטות חשובות

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

אל תהפכו כל בחירת קונפיגורציה לפסגת ארכיטקטורה.

אבל גם אל תקבלו כלאחר יד החלטה שהארגון יחיה איתה בעשור הקרוב.

שאלו:

כמה קשה יהיה להפוך את זה?

כמה דברים יהיו תלויים בזה?

אם התשובות הן קשה מאוד והרבה, כנראה מצאתם החלטה ארכיטקטונית.

Click to enlarge

האטו. הבינו את הדרישה. בחנו את החלופות. הפכו את הפשרות לגלויות. קבלו את ההחלטה. וכתבו למה.

המטרה של ארכיטקטורה היא לא לקבל החלטות שלעולם לא ישתנו.

המטרה היא לזהות את ההחלטות שבהן לשנות את דעתכם יעלה ביוקר.

מה הארכיטקט מחליט כאן

• אילו החלטות הן ארכיטקטוניות: קשות להפיכה, והרבה תלוי בהן.
• כמה תשומת לב כל החלטה מקבלת, בפרופורציה למחיר של טעות.
• אילו החלטות נכתבות, עם ההקשר, האפשרויות, ההשלכות, הבעלים ונקודת הסקירה שלהן.
• איך החלטות ה-Salesforce מתיישבות עם החלטות הארגון.

להרחבה

• Object Relationships Overview (opens in a new tab), Salesforce Help (באנגלית, נבדק ב-2026-10-09; נבדק שוב ב-2026-10-12): בקשר master-detail, הגישה והבעלות של רשומת ה-detail נגזרות מה-master, ומחיקת master מוחקת את רשומות ה-detail שלו.
• Considerations for Object Relationships (opens in a new tab), Salesforce Help (באנגלית, נבדק ב-2026-10-09; נבדק שוב ב-2026-10-12): אפשר להמיר lookup ל-master-detail רק כשבכל רשומה יש בו ערך; ההמרה משנה את מודל השיתוף (ל-Controlled by Parent), וסוג הקשר קובע אילו סוגי דוחות סטנדרטיים זמינים.
• Roll-Up Summary Field (opens in a new tab), Salesforce Help (באנגלית, נבדק ב-2026-10-09; נבדק שוב ב-2026-10-12): שדות סיכום מצטבר (roll-up summary) קיימים רק בקשרי master-detail, וצריך למחוק אותם לפני שאפשר להפוך master-detail ל-lookup.