כנס הארכיטקטורה הראשון של 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.

סיכום

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

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

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