השאלה שהיחידה הזו עונה עליה: איך משרטטים מפת מערכות שמראה לאן הנתונים הולכים?
תנו לי תרחיש חדש ולוח מחיק ריק, ואחד הדברים הראשונים שאשרטט הוא מפת המערכות. לא יפה, לא כל API, עוד לא מודל הנתונים. אני רוצה לראות את הארגון: מי המשתמשים, אילו מערכות מעורבות, איפה Salesforce יושבת, מה מקיף אותה, מאיפה הנתונים מגיעים ולאן הם הולכים. ואז אני רוצה לעבור על החצים. מפת מערכות טובה היא לא תמונה של קופסאות. היא דרך לחשוף החלטות ארכיטקטוניות.
אני גורם למועמדים ל-CTA לתרגל את זה. קראו את התרחיש, ואז התחילו לשרטט. אל תחכו עד שפתרתם הכול בראש; השרטוט עוזר לכם לפתור. בגלל זה שיעורי הבית אחרי היום הראשון הם להתחיל את מפת המערכות לפני שמנסים את כוחכם במודל הנתונים. שרטטו קודם את מודל הנתונים, וכבר הנחתם מה שייך ל-Salesforce. שרטטו קודם את מפת המערכות, ותוכלו לראות את המערכות שצריכות לעצב את ההחלטה הזו.
התחילו גבוה, ואז רדו לפרטים: קודם כל הארגון, ואחר כך הפירוט במקום שבו הוא חשוב.
יש הרבה דרכים לשרטט מפת מערכות. זו פשוט הדרך שלי, כזו שליטשתי לאורך הרבה שנים, ואני משתף אותה כדי שתראו איך מרכיבים אחת מהר. אני משתמש בה לכל מפת מערכות של Salesforce, והיא נקראת כמו משפט: האנשים משמאל מגיעים ל-Salesforce שבאמצע, שזוכה לאמון דרך המערכות שמעליה, משרתת דרך הערוצים שמתחתיה, ומחוברת לבק-אופיס שמימין.
האנשים משמאל, מלמעלה למטה: משתמשים פנימיים, שותפים, לקוחות. עוד לא כל פרסונה; מספיק כדי לענות על מי מנסה להגיע לארכיטקטורה הזו? כל קבוצה מצביעה על המקום שבו היא נכנסת: משתמשים פנימיים ל-Salesforce, שותפים לקהילת השותפים, לקוחות לקהילת הלקוחות. מערכות לא קיימות לבד. מישהו, או משהו, מנסה להשתמש בהן.
Salesforce באמצע. קופסה פשוטה אחת. לא כי Salesforce היא מרכז הארגון (הרגע הקדשנו שלוש יחידות לומר שהיא לא), אלא כי זו המערכת שאני מתכנן סביבה. היא העוגן.
הקהילות ממש מתחתיה, נוגעות בה. קהילת שותפים וקהילת לקוחות הן נקודות קצה נפרדות, אז הן מקבלות קופסאות משלהן. אבל הן יושבות צמוד ל-Salesforce, כי לא צריך שום אינטגרציה כדי להגיע אליהן: הן רצות באותו org.
שלב 3 מתוך 6: Salesforce באמצע, הקהילות ממש מתחתיה.
הזהות למעלה. ספקי הזהויות הולכים למעלה, אלה שמפתחים שוכחים: אחד למשתמשים פנימיים, אולי עוד אחד לשותפים. גם חבילות AppExchange הולכות לשם, מוזזות ימינה, כי הן יכולות שמובאות לתוך ה-org ולא מערכות בק-אופיס שמחליפות איתו נתונים. אתרים ציבוריים יושבים למעלה משמאל.
אינטגרציה, ואחריה הבק-אופיס, מימין. שכבת האינטגרציה, ESB או iPaaS (או MuleSoft, כשהיא נקראת בשמה), היא פס גבוה ממש מימין ל-Salesforce. המערכות הפנימיות יושבות מאחוריה: מערכות ה-ERP, הכספים, ניהול ההזמנות, מערכות legacy, מחסן הנתונים. עכשיו הדף נקרא משמאל לימין: אנשים, Salesforce, אינטגרציה, בק-אופיס.
הערוצים למטה. כל מה שיש לו קו ישיר ללקוחות: email-to-case, web-to-lead, טלפון, הודעות.
נתונים נכנסים ויוצאים, למטה מימין. מקורות נתונים חיצוניים, ארכיונים, טעינות נתונים.
Data 360 מימין, מתחת לשכבת האינטגרציה. משתמשים אף פעם לא מתחברים אליו, וה-tenant שלו מתחבר להרבה מערכות back-end, אז הוא יושב עם הצנרת, שם הקווים האלה נשארים קצרים: ליד המערכות הפנימיות, מחסן הנתונים והנתונים שלמטה מימין. צוותי נתונים כן פותחים את המסכים שלו, אבל המסכים האלה נמצאים ב-org: Data 360 הוא קרוב לליבה (near-core), מנוהל על הליבה ומתארח מחוץ לליבה (יחידה 1). קו אחד חזרה ל-Salesforce מראה מי מנהל אותו. המקום שבו אתם שמים את הקופסה צריך לספר את הסיפור של מה שהיא עושה.
שום דבר מהגאומטריה הזו הוא לא קדוש. הערך של מוסכמה הוא שאני לא ממציא מחדש את השפה החזותית בכל פעם, וכל מי שראה אחד מהתרשימים שלי יכול לקרוא את הבא מהר יותר.
שמרו על סימון פשוט. כל מערכת היא כרטיס: השם שלה, התפקיד שלה, ואייקון קטן שאומר איזה סוג דבר היא: ERP, מסד נתונים, ספק זהויות, קבוצת אנשים. האזורים שתיארתי הרגע משורטטים כאזורים חיוורים עם תוויות, כך שהפריסה עצמה גלויה. מקרא בתחתית אומר מה כל אייקון וכל קו מסמלים.
אל תכניסו יותר מדי לתוך קופסה. רק במפת מערכות מסובכת מאוד אני פותח את Salesforce לחלקים שלה (Sales Cloud ו-Service Cloud בתוך ה-org, עם חצים ביניהם). ואל תמציאו חמש עשרה צורות, אלא אם כל אחת מהן אומרת משהו לקורא. אני רוצה שמישהו יסתכל על מפת המערכות שלושים שניות ויתחיל להבין את הארכיטקטורה. מפואר לא עוזר. ברור כן.
אל תחכו לתכנון המפורט כדי לחשוב על נפח. חץ שנושא 500 מוצרים בלילה וחץ שנושא 200,000 קריאות GPS ביום יכולים להיראות בדיוק אותו דבר במפת המערכות. הם לא אותה בעיה. אז לפני שאתם משרטטים חץ אחד, ספרו מה זז. התחילו את המלאי שמאחורי התמונה עם הספירות: שורה אחת לכל מערך נתונים חשוב, עם הנפח שלו. ייתכן שהאפסים לעולם לא יופיעו על החצים, אבל אתם צריכים לדעת מתי אתם עוברים למספרים גבוהים: אלפים או מיליונים בשעה, מאות אלפי תנועות, אפילו עשרות עד מאות תנועות בשנייה.
המספרים האלה מכתיבים את המנגנון. כמה מאות רשומות בלילה זו אצווה. קריאה שמישהו מחכה לה יכולה להיות סינכרונית, אם הנפח מאפשר. עשרות עד מאות בשנייה עשויות לדרוש אירועים, כמו platform events, במקום קריאה לכל רשומה. החץ ייראה אותו דבר; הנפח מחליט מה נושא אותו, אז תעדו אותו במלאי, במקום שבו בוחרים את המנגנון.
המנגנון יכול אפילו לשנות את כיוון החץ. שלחו כמה רשומות בדקה, ו-Salesforce יכולה פשוט לבצע קריאה יוצאת: החץ מתחיל ב-Salesforce. שלחו הרבה יותר, ו-Salesforce עשויה לפרסם במקום זה אירועים ב-event bus; המערכת החיצונית נרשמת אליהם ופונה פנימה כדי לקבל אותם, אז עכשיו החץ מתחיל בצד השני. גדול עוד יותר, נניח סנכרון לילי של מיליוני רשומות, וזה תהליך אצווה. אז הכירו את הספירות שלכם מוקדם, כשאתם מתחילים לתכנן את המנגנונים, כי הספירות יכולות לשרטט מחדש את החצים.
הנפח חשוב בשני מקומות, משתי סיבות. במודל נתונים, אני צריך אותו כדי לשים עין על נפחי נתונים גדולים ולתכנן ארכיון; חלק 2 נכנס לזה לעומק. במפת מערכות, המספרים הגדולים במלאי מכתיבים את הבחירה בדפוס האינטגרציה ובמנגנון. יחידה 6 שמה אפסים אמיתיים על מפת המערכות של Steve Trucking ועל המלאי שלה. עם הספירות ביד, שרטטו את החצים.
כשהמערכות במקומן, חברו אותן, ומפת המערכות הופכת לארכיטקטורה. קופסה היא מערכת; החץ מראה מי יוזם את החיבור. הוא מתחיל במערכת שפותחת את החיבור ומצביע על זו שהיא קוראת לה: מלקוח לשרת. התווית אומרת מה זז, ולאיזה כיוון.
הכלל הזה הוא למפות מערכות, שבהן מערכות מדברות עם מערכות. בתרשים זרימת נתונים החץ הולך אחרי הנתונים, כמו שהייתם מצפים. אל תעבירו את הכלל של מפת המערכות לתרשימים אחרים; זה רק מוסיף בלבול.
החצים נכנסו. כל קופסה נמצאת איפה שהייתה; כל חץ מתחיל במערכת שפותחת את החיבור, והתווית שלו אומרת מה זז ולאיזה כיוון.
אז אם שכבת האינטגרציה דוחפת מוצרים ל-Salesforce, החץ רץ משכבת האינטגרציה ל-Salesforce, עם התווית מוצרים נכנסים. אם Salesforce מבצעת קריאה יוצאת כדי להביא אותם, החץ מתחיל ב-Salesforce, ועדיין עם התווית מוצרים נכנסים. אותם נתונים, שיחה אחרת, וההבדל הזה אומר לי מי צריך את פרטי ההתחברות ומי צריך לטפל בכישלון. Salesforce שולחת את ההזמנה דרך שכבת האינטגרציה: הזמנות יוצאות. האספקה של ה-ERP חוזרת: סטטוס הזמנות נכנס. עכשיו אני יכול לראות מי מתחיל כל שיחה, איפה נתונים נכנסים ל-Salesforce ואיפה הם יוצאים, אילו זרימות חוצות גבולות, איפה הבעלות כנראה יושבת, ואיפה אני צריך לשאול עוד.
ותזכרו את יחידה 1: בכל פעם שאני רואה זרימה אחת בלבד, אני מתחיל לדאוג. ברמה הגבוהה, חץ של הזמנות יוצאות תלוי בזרימות חזרה: לקוחות נכנסים, מוצרים נכנסים, מחירים. הסתכלו עוד יותר לעומק ויש את הדרך חזרה: קבלה, דחייה, סטטוס, מספר חשבונית, ביטול. החצים נותנים לי משהו מוחשי לאתגר.
כאן מפת המערכות מפסיקה להיות אמנות PowerPoint. בוועדת הסקירה (review board), כל חץ יכול לגרור שלוש שאלות, ואני רוצה שיהיו לכם התשובות:
איך הוא מאמת? OAuth, תעודה, named credential, משהו אחר?
האם הוא סינכרוני או אסינכרוני? האם Salesforce מחכה ל-ERP, או מפרסמת וממשיכה הלאה? כמה מהר העסק צריך את התוצאה?
מה המנגנון? קריאת REST, אירוע, קובץ, תור הודעות, דרך MuleSoft או ישירות?
ואז: מה קורה כשהצד השני למטה? לכל חץ צריך מנגנון. אם אתם לא יכולים להסביר אותו, הקו הוא קישוט.
ו-”fire and forget” (שגר ושכח) זו לא תשובה. בדרך כלל זה אומר “לא תכננתי מה קורה אחרי השיגור”. זה הגיע? זה התקבל? זה נכשל? זה ינסה שוב? מי יודע שזה תקוע? מה אם אותה הודעה מגיעה פעמיים? שום דבר מזה לא נכנס למפת המערכות, שהייתה הופכת לבלתי קריאה. אבל החץ צריך לגרום לכם לדעת שהשאלות האלה קיימות.
התקרבו לחץ אחד כלשהו ויש לקוח ושרת, וכל אחד מהם אחראי על החצי שלו. הלקוח פותח את החיבור: הוא צריך את נקודת הקצה ואת הפורט, מקבל קודם טוקן משרת האימות, קורא בפרוטוקול ובחוזה שהשרת מגדיר, ובוחר אם לחכות. רק הלקוח רואה את כל הסיבוב, אז רק הלקוח יכול לנסות שוב. השרת מאזין, מגדיר את הפרוטוקול, את החוזה ואת המטען (payload), מאמת את מה שנכנס, ורואה רק את החלק שלו. כשאני משרטט חץ, אני כבר יודע איזה קצה הוא מה, וזה אומר לי מי הבעלים של כל אחת מהשאלות האלה.
חץ אחד בתקריב: הלקוח מטפל, השרת מגדיר. שום דבר מזה לא נכנס למפת המערכות, אבל לכל חץ זה קיים.
עכשיו הפכו את החץ. כשה-ERP קורא ל-Salesforce, Salesforce היא השרת: היא מגדירה את ממשקי ה-API, מריצה שרת הרשאה (authorization server) משלה, ומחליטה דרך External Client App ומשתמש אינטגרציה מה המתקשר רשאי לעשות. אותן שאלות, מהצד השני.
כאן ארכיטקטים הורסים תרשים טוב: הם גורמים לתוצר אחד לענות על הכול. מפת המערכות מקבלת שמות API, מטענים, ניסיונות חוזרים, תורי שגיאות, המרות, כל callback, ותוך זמן קצר אף אחד לא יכול לקרוא אותה. אל תעשו את זה. מפת המערכות היא התמונה הגדולה: מערכות והזרימות החשובות ביניהן.
כשאני צריך להסביר אינטראקציה, אני משרטט תרשים שני, אבל לא לכל אינטגרציה. אם מערכת A שולחת משהו ל-B, או אפילו שואלת ומקבלת תשובה, החץ עם התווית מספיק. אני רוצה תרשים מסלולים (swim lane) כשהתהליך הופך לשיחה: A קוראת ל-B, B בודקת מול C, C עונה, B יוצרת משהו וקוראת חזרה ל-A, אדם מאשר, מערכת אחרת ממשיכה. כלל האצבע שלי: יותר מהלוך-חזור אחד או שניים, והרצף מקבל תרשים מסלולים משלו. חצים על מפת המערכות; השיחה בתרשים המסלולים.
ושימו לב שלחץ יש שם משמעות אחרת. במפת המערכות, חץ הוא חיבור: מי פותח אותו, ומה זז. בתרשים מסלולים, כל חץ הוא הודעה אחת בשיחה, שנקראת לפי הסדר: בקשה הולכת לכיוון אחד, תשובה חוזרת בכיוון השני, והצעד הבא בא אחריה.
כשמפת המערכות נראית כמעט גמורה, עברו עליה, חץ אחר חץ. ERP ל-Salesforce: מה זז, מי הבעלים שלו, איך הוא מאמת, מה המנגנון, סינכרוני או אסינכרוני, כמה עדכני הוא חייב להיות? ואז החץ הבא, והבא אחריו. כאן מופיעים הפערים. “אה, אף פעם לא סגרנו איך השותף בעצם שולח את זה.” “אנחנו שולחים הזמנות ל-ERP, אבל לא תכננו איך הזמנות שנדחו חוזרות.” טוב. מצאתם את זה על הלוח במקום בייצור.
בגלל זה אני אוהב את התוצר הזה: הוא עוזר לי לחשוב. “איך נדווח על פני Salesforce וה-ERP?” זו השאלה מיחידה 3: איזה מהתרשימים שלי פותר את זה בצורה יפה? מפת המערכות. אם הכול על הליבה, דוחות סטנדרטיים. אם הנתונים ב-ERP ובמחסן הנתונים, רואים את זה מיד. “איפה צריך לנהל כנתוני אב את המאפיין הזה של הלקוח?” הסתכלו אילו מערכות משתמשות בו ואיזו כבר הבעלים של הלקוח. “האם Salesforce צריכה כל קריאת GPS?” מי מייצר אותה, מי צורך אותה, מה עומס העבודה? אולי Salesforce צריכה את המיקום הנוכחי ופלטפורמה אחרת שומרת את ההיסטוריה. מפת המערכות לא נותנת לכם את התשובה. היא נותנת לכם את המבט הנכון על הבעיה.
עוד משמעת אחת. בארגון קיים, שרטטו את מה שקיים, לא את מה שהייתם רוצים שיהיה קיים. הגיליון האלקטרוני שנשלח במייל כל יום שישי: שרטטו אותו. קובץ ה-CSV של השותף על שרת SFTP: שרטטו אותו. האינטגרציה שעוקפת את ה-ESB מסיבות היסטוריות: שרטטו אותה. אנשים שמקלידים מחדש נתונים בין שתי מערכות: הראו את זה. אל תנקו את המציאות בזמן שאתם מתעדים אותה. אתם צריכים את מפת המערכות הנוכחית לפני שאתם מתכננים את מפת היעד, וזה מה שאנחנו עושים ל-Steve Trucking ביחידה 6.
מעבר למבחן: מה הבינה המלאכותית משנה. מפת המערכות הופכת למפה של סוכנים. אם סוכן עונה על “איפה המשלוח שלי?”, מפת המערכות צריכה לומר אם התשובה מגיעה מ-Salesforce, ממערכת של שותף, מהטלמטיקה, מה-ERP, או משילוב. סוכנים לא מבטלים את הגבולות בין מערכות; הם הופכים את הידיעה איזו מערכת סמכותית, ואיך להגיע אליה בבטחה, לחשובה עוד יותר.
אילו מערכות ואוכלוסיות משתמשים שייכות למפת המערכות, ואיך המיקום שלהן מראה את התפקיד שלהן.
אילו זרימות חוצות גבולות בין מערכות, לאיזה כיוון, ומה חוזר.
איך כל חיבור מאמת, איזה מנגנון נושא אותו, והאם הוא סינכרוני, אסינכרוני, אצווה או פדרציה.
מתי חץ עם תווית מספיק ומתי אינטראקציה צריכה תרשים מסלולים משלה.
מה המלאי שמאחורי התמונה מתעד: בעלים, עומס עבודה, נפח, org, תזמון, אימות, והאם להעתיק, להפנות או לבצע פדרציה.
מפת המערכות היא לא משהו שאני משרטט אחרי שהארכיטקטורה גמורה. היא הדרך שבה אני מוצא את הארכיטקטורה. וכשאתם חושבים שהיא גמורה, אל תתפעלו ממנה. עברו עליה. כל חץ שאתם עוד לא יכולים להסביר מראה לכם איפה העבודה.
