המבנה הארגוני החדש הוא צעד אסטרטגי, שנועד להתאים את הארגון לסדרה של יעדים מתוכננים. אלו הן מלים גדולות – אך בעלות משמעות קונטרטית: החברה רוצה להשיג כמה יעדים, ומרכיבה קבוצות שיהיו מסוגלות להשיג את היעדים הללו.
בתור הארכיטקט הראשי של החברה, עומדת לפתחי שאלה: האם השינוי הארגוני אמור להשפיע על הארכיטקטורה?
האם סידור אחר של אנשים בצוותים אמור להשפיע על ״מבנה התוכנה הנכון״?
במקרה, התשובה היא: בוודאי שכן!
אם השינוי היה ארגון מחדש של צוותים הנובע מסיבות פרסונליות או, נאמר, גיוס של מספר עובדים חדשים ואיזון הצוותים בין עובדים חדשים לוותיקים – קרוב לוודאי שלא היה צורך להתאים את הארכיטקטורה.
במקרה של שינוי ארגוני אסטרטגי, המשנה את היעדים של הצוותים – יש טעם רב בהתאמת הארכיטקטורה: הצוותים החדשים שיוגדרו יעמדו בפני משימות קונקרטיות מאוד, שעליהם למלא. השגת המשימות תתבצע ע״י שינויי ותוספות קוד.
נתאר את המצב הצפוי הבא, בצוות האחראי על פונקציונליות x:
- את הקוד שהצוות אחראי עליו (להלן: “מודול A”) – יהיה קל ונגיש לשנות.
- את הקוד שאחראי עליו צוות אחר (להלן “מודול B”) – יהיה מורכב יותר לשנות: צריך לתאם, לתקשר יותר, ולהשתלב בעבודה של הצוות השני.
סביר להניח שהמקום בו הצוות יממש את פונקציונליות x, במידה רבה, תהיה על גבי מודול A שבאחריותו – גם אם טכנולוגית זה לא המקום האופטימלי.
הצוות צריך לספק את הסחורה, והוא יעשה מה שנדרש בכדי להשיג את היעד. זה מה שמצופה ממנו.
את העיוות הטכנולוגי – קל יותר לבלוע מחוסר עמידה ביעד.
חוק קונווי
חוק ידוע בעולם התוכנה הוא Conway’s Law שטבע איש מדעי-המחשב מלווין קונווי במאמר משנת 1968. למרות שזמן רב עבר – החוק עדיין נכון ולרלוונטי מתמיד.
החוק אומר כך:
על תכנון של מערכת בארגון נגזר – שהיישום שלה בפועל ישקף את קווי התקשורת בארגון.
אם היה לנו תכנון (משמאל), וניסינו ליישם אותו בארגון עם מבנה מסוים (בירוק במרכז), נגזר עלינו שהתוצאה הסופית / היישום של התכנון יהיה יציר כלאיים בין התכנון המקורי, לצורת התקשורת בארגון (מימין).
בואו ואמקד למה אני מתכוון כאשר אני מדבר על “מבנה התוכנה” או “הארכיטקטורה”:
- חלוקה של הקוד למודולים ברורים – כאשר לכל מודול יש אחריות על פונקציה מסוימת של המערכת.
- הגדרת מגבלות / תלויות על כתיבת הקוד – בכדי לשמר את המבנה הנ”ל לאורך זמן.
למשל: כלל שמודול X לא מורשה לבצע פניות למודול Y, או שמודול Z לא מטפל בכלל במפונציונליות שהוגדרה לאחריותו של מודול X.
ההכרה בחוק מותירה לנו 3 ברירות עיקריות:
- להלחם במציאות הארגונית – בכדי לגרום למימוש “הנכון” של התכנון, כפי שהוגדר. “לא מעניין אותי שזה בצוות אחר. נכון יותר שזה יקרה כך וכך”.
- לשנות את המבנה הארגוני, כשיקוף של התכנון שהוגדר – בכדי לאפשר ולתמוך בתכנון שהוגדר.
- לשנות את תכנון המערכת, כדי שתשתלב במבנה הארגוני הנתון.
אופציה שלישית היא אופציית ברירת המחדל: במקום להלחם בחוקי התכנותיקה (“חוקי הפיסיקה של עולם התוכנה”) – לקבל אותם ולהסתגל אליהם.המצב שלנו היום הוא כזה: יש לנו ארכיטקטורה / מבנה של התוכנה שמתנהל יפה – אך מתאים למבנה הארגון הקיים.
שינוי המבנה הארגוני – יוצר פער: וגורם לארכיטקטורה הקיימת לא לתאום יפה למבנה הארגוני. את התיקון נעשה בצורת התאמות של הארכיטקטורה למבנה החדש.
התאמות כגון:
פיצול של מודול ל-2: חלק שיישאר בצוות a, וחלק שיעבור לצוות b
עקרון זה הוא נפוץ ב Microservices, אבל פחות מקובל בארכיטקטורות ריכוזיות.
הגדרה של שירותים חדשים
זה החלק הקל יחסית. אנו מזהים פונקציונליות חדשה במערכת שעל הצוותים יהיה לפתח – ואנו מוצאים לה “בית חם”. במידה ואין מקום מתאים-מספיק, אנו מגדירים שירותים (microservices) חדשים שיארחו את הפונקציונליות המיועדת, ומתכננים כיצד הם ישתלבו בכלל המערכת.
סיכום
חשוב לזכור שארכיטקטורה של תוכנה היא לא מבנה יציב: הצורך בשינוים מגיע בד בבד, כגלים, מחלקים שונים במערכת. כדאי לחשוב על הארכיטקטורה כגוף חי ומתפתח – המגיב לשינויים ולא להניח שיש “מצב סופי” או “מצב מנוחה” של הארכיטקטורה.
כמו כן, תמיד יהיו עיוותים מוסיימים ביישום הארכיקטורה – וזה טבעי.
הארכיטקטורה היא רעיון של סדר מסוים. סדר שהוא תאורטי, וכנראה לא יכול להתממש בדיוק במציאות. גם אם הרעיון היה מדוייק להפליא ומבוסס על הפרטים הקטנים ביותר במערכת – המערכת היא דינאמית ומשתנה. מרגע שהרעיון נולד ועד שהוא מיושם – המערכת הופכת למערכת קצת אחרת… וארגון – לארגון קצת אחר.
החוכמה היא להתמקד ברעיון שהוא מעט גמיש – ויהיה שימושי וטוב גם כאשר המערכת והצרכים מעט משתנים / רעיון שיוכל להשתנות בעצמו עם הזמן – כי הוא השאיר כמה שיותר “אופציות פתוחות” לעתיד.
שיהיה בהצלחה!
—
לינקים רלוונטיים
מעולם לא חשבתי ששינוי במבנה האירגוני, ידרוש שינוי במבנה הארכיטקטוני,נשמע מעניין ומעורר מחשבה נוספת.אשמח אם תספר לנו מה ה stack אצלכם, איך הארכיטקטורה בנויה ולמה זה נבחר כך.תודה רבה!
פוסט מעולה! מרענן ופותח את הראש לרעיונות חדשים ומעניינים. תודה!
היי אנונימי,ה Stack שלנו מורכב בעיקר מ AWS, רובי on ריילס, קצת golang, רדיס, PostgreSQL וקצת Hadoop.כיצד הוא נבחר? – חלק מסיבות טובות, וחלק במקריות.(תיאור הארכיטקטורה הוא קצת מורכב יותר…)השינוי הארגוני לא השפיע על ה Technology Stack אלא בעיקר בחלוקה לשירותים.ליאור