יום חמישי, 11 בדצמבר 2014

כנס הארכיטקטורה הראשון של IASA ו ILTAM

עדכון (11 בדצמבר, 2014)

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


------


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

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

ל IASA יש גם קבוצה ב LinkedIn  (דורשת הצטרפות) - בה חברים רבים מהארכיטקטים שאני מכיר. אם אתם ארכיטקטים - אני ממליץ לשקול להצטרף (אני חושב שלא יאשרו לכם להצטרף אם לא כתוב בקורות החיים שלכם שאתם ממש ארכיטקטים באופן רשמי).

את ILTAM, אני אודה - אני לא ממש מכיר לעומק. זו גם קהילה מקצועית, רחבה יותר, המורכבת בעיקר מחברות הייטק גדולות ומבוססות (לא רק חברות תוכנה נטו: אלתא, 3M, וצה"ל למשל - הם חברים) במטרה לקדם ולשתף ידע.

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

אני חושב שלשתי הקהילות יש מה ללמוד אחת מהשנייה. באופן אולי מפתיע, אני חושב שדווקא ל"תעשיה המסורתית" (מסורתית = חברות שחיות 15 שנה או יותר) יש יותר מה ללמוד מסצינת הסטארט-אפים למרות שרבים בתעשיה, לעניות דעתי - עדיין לא מבינים את זה.


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

בחלק השני השתתפתי בפאנל מקצועי (עם ד"ר עירית הדר מאונ' חיפה, עצמון הד-טוב VP R&D בפונטיס, וניר סלע - מנהל פיתוח התוכנה ברפאל) שדן במיומנויות הנדרשות בכדי להיות ארכיטקט, או אולי - ארכיטקט "מוצלח". פעם ראשונה שאני משתתף בכזה פאנל - ואני מקווה שהצלחתי לתרום לדיון ולעניין.

מקור

אני אספר בקצרה על שני sessions שהיו לי מעניינים במיוחד:

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

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

רוב התוצאות שאציג להלהן הן מסקר בו נשאלו מאה ומשהו ארכיטקטים על העבודה שלהם: מה הם עושים מול מה שהם חושבים שהם צריכים לעשות. כל התוצאות הן בסקאלה של 1 עד 5 (כלומר: 3.5 ממוצע) - כאשר המספר המדויק לא ברשותי - אני מספק רק "קריאה" שלי מגרף מסוג Bar Chart. למשל:
  • ארכיטקטים הם חלק מצוות הפיתוח (בערך 3.6) בעוד הם חושבים שהם צריכים להיות פחות חלק ממנו (בערך 3.4).
  • ארכיטקטים מובילים את תהליך פיתוח התוכנה (3.1 = נטיה ל"לא"), אבל הם מאמינים שהם צריכים לעשות זאת (3.9)
  • הם גם משתתפים במידה רבה בישיבות תכנון (3.9) - אבל מאמינים שצריכים להיות שם הרבה יותר (בערך 4.35).
  • בגדול ארכיטקטים מאמינים שהם צריכים להיות:
    • שותפים משמעותיים יותר בפיתוח המקצועיות ומתודולוגיות הפיתוח בארגון.
    • שותפים משמעותיים יותר בהגדרת המוצר / חקר השוק.
    • שותפים משמעותיים יותר בגיוס עובדים.
  • מה הם חושבים שהם צריכים לעשות פחות?
    • קידוד: עושים לא-הרבה (3.1) - אבל רוצים לעשות פחות (3)
    • אחריות על באגים / תחזוקת-קוד: עושים מעט (2.6) - אבל רוצים לעשות משמעותית פחות (בערך 2.3).
ניתן לקרוא את התוצאות ולומר: "ברור! כמו כולם הם רוצים להשפיע יותר, לעשות יותר עבודה כיפית - ופחות עבודה משעממת.". אין לי מדד להשוואה למפתחי תוכנה - אבל אני מניח שהיינו רואים מגמות דומות.

בכל זאת, שימו לב שהשאלה לא הייתה "מה הייתם רוצים לעשות", אלא "מה אתם חושבים שאתם צריכים לעשות (should do)". אני מעריך (היפותזה) שמפתחים ותיקים לא היו חושבים שהם צריכים "להנחות את הארכיטקטורה של כל פעילויות התכנון" ("Provide architectural guidelines for all software design activities" - ההדגשה שלי) - עושים: 4.1, חושבים שצריכים: 4.37.

חשבו על הטיעון הלוגי הבא (שרץ כנראה במוחו של כל ארכיטקט תוכנה, בשלב כזה או אחר):
"אם אני ארכיטקט" וגם "למוצר יש ארכיטקטורה" => "אני צריך להגדיר את הארכיטקטורה".

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

אני חושב שהייתי מעדיף שיקראו לארכיטקט Principal Engineer או System Engineer וכו'...

הערה: לצערי אין לי את הנתונים לשתף (המחקר עוד בעבודה, והאמונים עליו לא מעוניינים לפרסם מידע חלקי).


Wix - להגיע ל n מליון משתמשים (n = כרגע 50 וקצת)
טוב... רציתי לגעת גם במצגת של יואב מ Wix - אבל גם רציתי לכתוב פוסט קצרצר.
אתם יכלים למצוא ביוטיוב את ההרצאה - בגרסה מעט יותר מוקדמת שלה.

כמה נקודות מעניינות שעלו:
  • אם Wix הייתה "עושה ארכיטקטורה נכונה מהתחלה" - היא לא הייתה שורדת את השנים הראשונות.
  • רכיבים במערכת צריכים להיכתב לתקופה קצובה - ואז להיכתב מחדש (טיעון מקובל בעולם ה Micro-Services). כתבו קוד שיהיה קל-להחלפה.
  • לא זקוקים לבסיס נתונים NoSQL בכדי לעשות NoSQL. עברתי, בזמנו, חוויה דומה - וכתבתי על כך פוסט.
  • כל מפתח מחזיק הרשאות ל production servers - אנו מעסיקים רק את מי שאנו סומכים עליו (אני מתרגם זאת לעצמי: אנו לא סומכים על אף-אחד, בנינו תשתית מתאוששת-עצמית - ולכן אנו יכולים "לסמוך על כולם"). זו גישה דיי מקובלת בעולם ה CD.
  • ההעדפה של Wix ל Managed Data Center (דוגמת Rackspace - אני לא יודע עם מי באמת הם עובדים) על פני AWS - שם כמות המשתנים הבלתי ידועים / נשלטים (למשל: מה החומרה שלי, latency) - היא קטנה יותר.
  • הערה: פרופיל השימוש ב Wix הוא דיי חריג בעולם ה Web (המון המון תוכן סטאטי) - ולכן אני מציע לשקלל עובדה זו בכל רעיונות Scalability שאתם לוקחים מהם.
כמו שאמרתי, Wix היא במיינסטרים של עולם ה Start-up Web ו CD.



סיכום


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

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


שיהיה בהצלחה!




3 תגובות:

  1. ליאור,

    תודה על ההתייחסות וההשתתפות התורמת לכנס. אכן המפגש בין התעשיות ה"כבדות" לבין עולם הסטארטאפים סביב ארכיטקטורות תוכנה הוא מרתק, ואני מסכים איתך לחלוטין שיש לתעשיות הגדולות הרבה מה ללמוד מהעולם השני. יחד עם זאת, אני מאד שמח על המסקנה אליה הגעת בסוף, שהמונח הנכון יותר הוא System Engineer - מונח שקיים דווקא שנים רבות בתעשיות הגדולות והרב-דיסציפלינריות. אין שום ספק שתוכנה כבר מזמן לא דיסציפלינה בודדת אלא תחום רחב ועשיר של דיסציפלינות מערכתיות, לפיכך הייתי שמח לעודד, בעזרתך, את קהילת הסטארטאפים והחברות הקטנות יותר לקחת חלק בפעילות העשירה המתקיימת באילטם סביב נושא הנדסת המערכות. בתאריך 24/3/2015 יתקיים הכנס הבינאומי הדו-שנתי של האיגוד הישראלי להנדסת מערכות INCOSE_IL ואני ממליץ לכל מי שרואה את עצמו מהנדסת מערכת (ארכיטקט, לשעבר? :-)) לבוא ולהשתתף. אני מקיים מושב בנושא הנדסת מערכות תוכנה ואני בטוח שתוכנו יהיה רלוונטי לרובכם. להלן הקישור:

    http://www.iltam.org/incose_il2015

    עמיר תומר.

    השבמחק
    תשובות
    1. תודה עמיר!

      עבור קוראים (צעירים) שלא רגילים למינוח, אנסה להסביר:
      מספר לא מבוטל של חברות הייטק ישראליות (אלתא, תע"א, וכו') מפתחות גם תוכנה, גם חומרה, גם כימיה / פיסיקה / אופטיקה / אווירונאוטיקה וכו' - בכדי לתמוך ב"חומרה" המדוברת (נניח: מזל"ט, לווין. כלומר: לא רק סמארטפון או Arudino :) ). בחברות הללו יש כמה גופי פיתוח (תוכנה הוא רק אחד מהם) - וכולם עובדים למען פרוייקט אחד. אם אני מבין נכון, תפקיד מהנדס המערכת (system engineer) הוא סוג של "ארכיטקט" שעוזר לשלב בין התחומים השונים - למען המוצר השלם.

      מדוע תוכנה היא לא דיסציפלינה (בעברית: תחום-ידע) בודדת? מכיוון שיש הרבה מומחיויות (למשל: שרת, מובייל, big-data, וענן). כולם הם "תוכנה", אבל אם תעברו מעיסוק בתחום אחד לתחום לשני - תראו שיש הרבה פערי-ידע ותפיסות שיהיה עליכם להשלים. ניתן לנסות ולהשליך מהלקחים של פיתוח מערכת רב-תחומי (למשל: לווין) על פיתוח תוכנה שמורכבת מתחומים רבים.
      היום, בערך כל סטארט-אפ וובי היום עושה כמה מהתחומים שציינתי. Waze, לדוגמה, זאת לא "אפליקציה" - זו מערכת שמשלבת ענן, big-data, מובייל ופיתוח צד-שרת.
      מה הלקחים שניתן להפיק, וכיצד מעבירים את הידע בצורה יעילה? - קטונתי.
      @עמיר - בכדי לבסס קשר טוב עם הסטארט-אפים, אני מאמין שתהליך העברת הידע צריך להיות מהיר ויעיל. מאוד מהיר ויעיל - כי סטארט-אפים חיים על זמן קצוב, והשקעת זמן ללא תועלת מוחשית, ברורה, וכמעט-מיידית - היא סכנה קיומית עבורם.

      אם כל מה שהוספתי הוא ברור מאליו - אז סליחה :)

      ליאור

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

      מחק