על צורת העבודה של צוות ארכיטקטים בארגון תוכנה

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

יוצא דופן אחד שאני מצליח לחשוב עליו הוא The software architect elevator של גרגור הופ (המחבר של Integration Patterns), וגם הוא דיי ״טהור״ / ״תאורטי״ ופחות ממחיש את היומיום בשטח.

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

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

• כ 150 מהנדסי תוכנה. בישראל, וקצת בארה״ב.
• צוות הארכיטקטים פועל רוחבית על כל הארגון.
• חברת-מוצר (ביטוח לעסקים קטנים)
• מוצר SaaS (מיקרו-שירותים, לצורך העניין)
• קוטלין בצד השרת, TypeScript ואנגולר או ראקט בצד לקוח (לא ממש חשוב).
• חברה בת כשמונה שנים, כאשר האתגר הטכני העיקרי הוא מורכבות עסקית גדולה מאוד (המון business logic שצריך להכיל)

תהליך העבודה של צוות הארכיטקטים

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

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

איך יכולים כמה אנשים, נבונים ככל שיהיו למנוע ממערכת מורכבת עליה עובדים עוד 150 מהנדסים -מלהסתבך?!

הנה סיכום גרפי קצר של תהליך העבודה של צוות הארכיטקטים שלנו, ב high level:

Identify & Study system flaws

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

Insight

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

Design Solutions

• תובנה היא עדיין לא יכולת לפעול. צריך לחשוב ולמצוא את תוכנית הפעולה הטובה והנכונה (בהתאם לנסיבות).
• הארכיטקטים יושבים ועושים תכנון בקנה מידה גדול (Architectural Concept או High Level Design) לפתרון טוב יותר לבעיה.
  • לא פעם, הם היחידים שישקיעו זמן ומאמץ בשלב מוקדם – על בעיה ״כ׳׳כ רחוקה״.
  • בדרך כלל, לא יהיה להם מספיק ידע לתכנון מוצלח. הם יהיו חייבים לעבוד עם הצוותים שמכירים את הפרטים.
  • חשוב מאוד לצלול לקוד, ולחלץ תובנות משמעותיות מה domain experts הרלוונטיים. להתבסס על עובדות והבנה מספיק טובה של המצב.
    • בתכנון high level וארוך טווח שכזה – קל לקחת הנחות אופטימיות (או פסימיות), וליצור פתרון עם פערים מהמציאות בשטח. ראייה מפוכחת, ניסיון, ספקנות, ותקשורת טובה – הם כלים הכרחיים להצלחה בכזו משימה. הצלחה היא לא תוכנית שנראית מבטיחה. הצלחה היא תוכנית שיש לה סיכוי טוב להצליח באמת.
• השלב הזה מתבטא בעדכון שני תוצרים עיקריים:
  • ה Target architecture (בקיצור: TA) הוא סט מסמכים / Architectural Concepts / HLDs שנוצרו ומתארים את השינויים העיקריים שצוות הארכיטקטים מאמין שיש להחיל על המערכת בעתיד הנראה לעין. למשל: להוסיף אחריות חדשה במערכת, לשנות מידול, להחליף טכנולוגיה, להעביר אחריויות ממקום למקום במערכת, או לשנות גישת עבודה בחלקים שונים של המערכת.
    • טכנית, ה TA הוא תיקיה משותפת, עם המסמכים הנ״ל.
    • כמובן שצריך לרענן ולעדכן את התכנים כל הזמן. לא מעט רעיונות יהפכו ללא רלוונטיים עם הזמן.
    • כמובן שמסמכים ארוכים ומפורטים לא משרתים את ה TA היטב. מסמכים תמציתיים, שקל לקרוא, קל לעדכן, לא כואב לארכב – מתאימים יותר. היכולת לתמצת רעיונות למינימום הכרחי – חשובה מאוד.
    • סקירה תקופתית של הרעיונות עם מנהלים בכירים ומהנדסים רלוונטיים – יכולה לעזור מאוד, גם לתקף את הרעיונות, וגם לעזור ולרתום אליהם עוד אנשים.
    • רעיונות ב TA שלא הגיעו מצוות הארכיטקטים, ואפילו לא זכו לתמיכת הארכיטקטים בשלב מוקדם – הם חשובים ל TA. ה TA צריך להיות סיכום / קונצנזוס של הארגון (שהארכיטקטים אחראיים עליו) – ולא דעה אחת, או דעת מיעוט.
  • ישנן תובנות או לקחים שלא מתמפים לשינוי רכיב במערכת, מודל, או Flow במערכת. למשל: איך משדרגים ספריות, משנים סכמה בבסיס הנתונים, או עקרון שאומר שלכל מידע Immutable במערכת נדרש Audit Trail כזה וכזה – לצורכי troubleshooting, למשל.
  • תבנית מתאימה יותר היא ה Best Practices & Guidelines – שורה של כללים ותהליכים הנדסיים שיעזרו למערכת להיות ברת-קיימא (Sustainable) ויעילה יותר. דברים שאם לא נעשה אותם, יש סיכון גובר שנשקע ב״ביצת הסיבוכיות״.
  • גם כאן, הארכיטקטים הם ה Facilitators ואולי האחראים – אבל לא ״המוח״ היחידי להגדיר את אותם כללים.
  • גם כאן, נדרשת עבודה משותפת עם המהנדסים: Guidelines לא טובים, או Guidelines שרק יושבים במגירה – יכולים בהחלט להיות מזיקים.
  • גם כאן, נדרשת התעמקות ומקצועיות על מנת להוביל להחלטות טובות. דיון ״דמוקרטי״ שמנהל ארכיטקט שבו מהנדסים שונים מציעים Guidelines שונים – עתיד להוביל לבינוניות. הארכיטקט צריך להיכנס לעובי הקורה, לאתגר ולחפש שיאתגרו אותו – ולהציע Guideline שלם, הרמוני, ו ״battle tested״ בביקורת עמיתים. עליו יש אחריות שהתוצר הוא נכון ויעיל – ולתקן אותו לאורך הדרך, אם הסיכום הראשוני אינו טוב מספיק.

Driving TA and applying Guidelines through projects

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

• פרויקטים אסטרטגיים – פרויקטים גדולים ומורכבים, המזיזים ומחדשים, בכל מקרה, חלקים במערכת. פרויקטים אלו הם הזדמנות נכונה להתקדם לכיוון ה Target Architecture.
  • ייתכן ששינוי שהיה לוקח 4 חודשי עבודה בעצמו, פתאום משתלב לתוספת של חודש או חודשיים עבודה כחלק מפרויקט אסטרטגי – ולכן זו הזדמנות לבצע אותו.
  • לא פעם, לא להתקדם לכיוון ה Target Architecture משמע להקשות יותר על ההגעה לשם בעתיד (עיבוי החוב הטכני). הפרויקט יהפוך עבודה עצמאית של 4 חודשים – להיות 5 חודשים.
  • פרויקטים אסטרטגיים הם גם הזדמנות להחיל וליישם Best Practices במקומות חשובים במערכת – כחלק מהעבודה.
• ״פרויקטים הנדסיים״ – הוא מונח פנימי בנקסט לפרויקט שלא משרתים ישירות צורך עסקי – אלא שינוי ושיפור ארכיטקטורה. לפעמים נדרש שינוי גדול שלא נכון לקשור או לחכות לפרויקט עסקי אסטרטגי.
• ״פרויקט הנדסי״ הוא כלי משמעותי לקדם את ה TA מהר יותר – היכן שחשוב. לרוב הם יתרחשו רק כאשר נוצר קונצנזוס רחב על הצורך בשינוי המדובר. קונצנזוס שנכון מאוד שארכיטקטים יפעלו ללא ליאות כדי לבנות – אבל נחמד לפעמים לראות שדווקא אנשים אחרים בארגון (ראשי קבוצות, אחרים) הם אלו שמקדמים וגורמים להם לקרות. בסופו של דבר, המערכת היא של כולנו – ומערכת טובה יותר היא אינטרס משותף.

תוצר חשוב נוסף: ה Service Registry

במובן מסוים, ארכיטקטורה היא סדר:

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

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

כלי נוסף ששכללתי לאורך השנים – הוא ה ״Service Registry״: תיאור הארכיטקטורה הנוכחית, על צדדיה הטובים יותר והטובים פחות – במסמך וורד פשוט, ללא תרשימים. הפשטות הזו – היא הכוח של הכלי.

ה Service Registry מתאר בכמה bullets כל מיקרו-שירות במערכת. תיאור שקל לקרוא ולהבין – שצריך להיות מאוד תמציתי ומדויק.

דיסקליימר: בעשור האחרון עבדתי רק עם מידי-שירותים, שירותים בגודל בינוני, ולא המון שירותים קטנים. אני לא יודע לומר כיצד הכלי הזה היה עובד במערכת עם מאות מיקרו שירותים קטנים. בנקסט, יש לנו בעת כתיבת הפוסט כ 50 שירותים (כ 10-15 מהם הם באמת ״מיקרו״-שירותים) על 150 מהנדסים.

לכל שירות במערכת יש קטע קצר (שורות מספר, עד עמוד לשירותים המורכבים ביותר) הכולל 3 חלקים:

• (אופציונלי) רקע – לתאר קצת את ה domain של המיקרו-שירות, אם הוא לא מובן-מאליו.
  למשל: שירות ניהול-מיקום יכול קצת להסביר מהו geolocation ומה מידת הטעות האפשרית באיסוף שלו.
• תחומי-אחריות – תיאור (לרוב בנקודות) של סוגי הפונקציונליות שצריכות לשבת בשירות.
  תחת עקרון ה SRP (single responsibility) – לא אמורים להיות שני שירותים בעלי אותה אחריות.
  • אם יש חריגה משמעותית מהרצוי (היסטוריה) – אנחנו מציינים אותה במפורש.
• תחומי-אי-אחריות – תיאור (לרוב בנקודות) של סוגי הפונקציונליות שלא צריכות לשבת בשירות. זו לא רשימה כוללת (ואינסופית), אלא רשימה קצרה של המועמדים הטבעיים לטעות + הסבר קצר היכן במערכת הם כן צריכים לשבת.

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

הכלי הזה עוזר לצמצם ולפתור ויכוחים טכניים בין צוותים. הוא עוזר למהנדסים לקבל החלטות שיתיישבו עם הארכיטקטורה, והוא עוזר להציף אי-התאמה של הארכיטקטורה ע״י מהנדסים – שאחרת אולי והיינו מבינים רק מאוחר הרבה יותר. כמו שנאמר: Good fences make good neighbours.

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

סיכום

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

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

נ.ב. – אני מגייס ארכיטקט נוסף לצוות. אם את/ה ארכיטקט/ית שרוצה לנסות לעבוד בגישה הנ״ל, בחברה צומחת בעולם המוצר – baronlior[at]gmail.com היא הכתובת.