הכירו את הכלים שלכם: תשע השאלות

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

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

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

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

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

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

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

תשע השאלות

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

1. מה זה?
2. איפה משתמשים בזה?
3. איך אני משתמש בזה?
4. מהן החלופות שלי?
5. מהן החוזקות שלו?
6. מהן החולשות שלו?
7. איך אני מסביר את זה למפתחים, לעסק ולמנהלים בכירים?
8. איך מתחזקים את זה לטווח ארוך?
9. כמה זה עולה, איזה רישוי זה דורש, ומהן המגבלות שלו?

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

Click to enlarge

1. מה זה?

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

2. איפה משתמשים בזה?

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

3. איך אני משתמש בזה?

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

4. מהן החלופות שלי?

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

5. מהן החוזקות שלו?

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

6. מהן החולשות שלו?

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

7. איך אני מסביר את זה לקהלים שונים?

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

8. איך מתחזקים את זה לטווח ארוך?

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

9. כמה זה עולה, איזה רישוי זה דורש, ומהן המגבלות שלו?

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

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

דוגמה מלאה: Apex sharing

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

עכשיו החולשות שלו (שאלה 6). נניח שיש לנו קהילת לקוחות עם 10 או 20 מיליון חברים, ואנחנו משתמשים ברישיון Customer Community, לא Customer Community Plus. אלה משתמשים בנפח גבוה (high-volume). אין להם תפקידים, והם בכלל לא משתמשים במודל השיתוף: הגישה שלהם מגיעה מ-sharing sets ו-share groups, בהתאמה דרך החשבון ואיש הקשר שלהם. אין רשומת שיתוף ש-Apex יכול לכתוב עבורם, ולכן Apex sharing לא עובד עבורם. ושאלת העלות והרישוי (שאלה 9) היא מה שהביא אותנו לשם: בחירת הרישיון קבעה אילו כלי שיתוף בכלל קיימים.

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

אל תשננו את הפלטפורמה

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

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

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

למדו את השאלות, לא רק את התשובות

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

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

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

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

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

להרחבה

• About High-Volume Community or Site Users (opens in a new tab), Salesforce Help (באנגלית, נבדק ב-2026-10-09; נבדק שוב ב-2026-10-12): למשתמשים בנפח גבוה (הרישיונות External Apps, Customer Community, High Volume Customer Portal ו-Authenticated Website) אין תפקידים; הגישה שלהם מגיעה מ-sharing sets ו-share groups; אי אפשר לכלול אותם בכללי שיתוף מבוססי בעלים, ואי אפשר לשתף ידנית רשומות שבבעלותם.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (באנגלית, נבדק ב-2026-10-09; נבדק שוב ב-2026-10-12): משתמשים בנפח גבוה (Customer Community, High Volume Customer Portal, Authenticated Website) לא משתמשים במודל השיתוף, כי הרישיונות שלהם לא תומכים בתפקידים; הגישה עובדת בהתאמת המשתמש לשדות ה-lookup של החשבון (Account) ואיש הקשר (Contact), דרך sharing sets או share groups. אותו עמוד מפרט מתי Apex managed sharing הוא הכלי הנכון.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), שאלה ב-Trailblazer Community, נובמבר 2024 (באנגלית, נבדק ב-2026-10-09; נבדק שוב ב-2026-10-12): איש מקצוע מדווח שהכנסת רשומות שיתוף עבור משתמשים בנפח גבוה נכשלה עם שגיאה. דיווח מהשטח, לא תיעוד רשמי. (ה-Trailblazer Community המקוונת עוברת למצב קריאה בלבד ב-30 באוקטובר 2026; ייתכן שהקישור ישתנה.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce Help (באנגלית, נבדק ב-2026-10-09): sharing set מעניק גישה לרשומות שקשורות לחשבון או לאיש הקשר של המשתמש.