ארכיטקטורה היא אמנות הפשרות

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

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

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

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

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

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

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

הרבה דרכים לפתור את הבעיה

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

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

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

אפילו משהו פשוט כמו רשימת בחירה (picklist) עובד היום ויכולות להיות לו בעיות כשהנתונים גדלים. רשימת בחירה קלה למשתמשים. אבל שאלו מאיפה מגיעים הערכים, וכמה יכולים להיות. רשימות בחירה עובדות הכי טוב עם פחות מבערך 20 ערכים. לפעמים אנחנו מגיעים ל-50, כמו מדינות ארה”ב, ולעיתים רחוקות מעבר ל-100, כמו מדינות העולם, ואלה כבר נעשות מסורבלות. אז לכל רשימת בחירה, דעו מה הגבול העליון. ושינוי ערכים של רשימת בחירה הוא שינוי מטא-דאטה, לא שינוי נתונים.

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

Click to enlarge

אופטימלי זה לא מושלם

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

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

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

החלטה לא אופטימלית יכולה להיות חלק מארכיטקטורה אופטימלית

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

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

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

דעו על מה אתם מוותרים

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

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

לא כל הדרישות שוות

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

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

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

מגבלות משנות את התשובה

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

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

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

הארכיטקט צריך תמונה של “אופטימלי”

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

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

שרטטו את זה

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

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

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

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

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

הסבירו את הפשרה

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

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

Think Correct. Think Fast.

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

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

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

ארכיטקטורה היא עניין של איזון

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

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

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

זה לא חוסר החלטיות. זו ארכיטקטורה.

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

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