לחשוב כמו ארכיטקט

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

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

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

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

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

במשך רוב הקריירה שלי הייתי בונה.

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

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

בונה שואל:

איך אני בונה את זה?

ארכיטקט צריך לשאול סדרה אחרת של שאלות:

האם כדאי לבנות את זה?

למה אנחנו בונים את זה דווקא כך?

מהן החלופות?

מה קורה כשזה גדל?

מה קורה כשזה נכשל?

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

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

השינוי הזה בדרך החשיבה הוא מה שהקורס הזה באמת עוסק בו.

Click to enlarge

האדם שמחזיק את התוכנית

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

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

אבל מישהו גם צריך להחזיק את התוכנית.

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

זו ארכיטקטורה.

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

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

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

אל תקבלו את הדרישה כמו שהיא

אחד ההרגלים הראשונים שאני רוצה שארכיטקטים יפתחו הוא פשוט:

שאלו למה.

מישהו אומר לכם:

אנחנו צריכים עוד אובייקט.

למה?

אנחנו צריכים שהשדה הזה יועתק לחשבון (Account).

למה?

אנחנו צריכים שכל הנתונים האלה יישמרו ב-Salesforce.

למה?

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

דרישה מגיעה הרבה פעמים בתחפושת של תכנון.

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

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

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

עבדנו על אפליקציית מכירות, וללקוח היו כמה אישורים, לכל אחד מאשר ותאריך. הבקשה הראשונה שלהם הייתה להוסיף Approver 2 ו-Approver 3, כל אחד עם תאריך, כשדות בהזדמנות (Opportunity). כשחפרנו לעומק, הבנו שיכולים להיות יותר משניים או שלושה. אז העברנו את האישורים לאובייקט בן. הבקשה הייתה לעוד שדות; הדרישה הייתה לעקוב אחרי כל אישור, לא משנה כמה יהיו בסוף.

לחשוב מעבר לדרישה

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

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

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

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

Click to enlarge

הפכו את הנימוקים שלכם לגלויים

ארכיטקט לא אמור פשוט להיכנס לחדר ולהכריז: “זה מה שאנחנו עושים”.

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

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

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

הארכיטקט לא צריך לבנות הכול

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

אתם לא חייבים לבנות הכול בעצמכם.

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

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

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

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

זה חלק מהמסע מבונה לארכיטקט.

התפקיד שלכם הוא לקבל החלטות

בסופו של דבר, ארכיטקטורה עוסקת בהחלטות.

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

אפשר לשנות פריסת עמוד (page layout). אפשר לשנות שם של תווית.

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

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

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

הטכנולוגיה חשובה.

אבל להכיר כל פיצ’ר של Salesforce זו לא המטרה.

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

זו חשיבה כמו של ארכיטקט.

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

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

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