על תפקידו של הארכיטקט כשמרטף ועל סכמות של ארכיטקטורה

1 בדצמבר 2014

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

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

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

השפה הסכמתית מורכבת בדרך כלל מסימנים מוסכמים. בשרטוט החשמלי לא מצויר השקע אלא הסמל שמסמן שקע,  בשרטוט האינסטלציה לא מצויר ברז אלא הסימול של ברז. באופן דומה בשרטוט הארכיטקטוני של התכנה יהיו סימולים מתאימים שאמורים להיות ברורים לכל מפתח.  ובשפה הסכמתית הזו צריך להיות סימול ברור ל Service לעומת Utility. מונחים כמו Security Boundary או Transaction Boundary צריכים להיות מוגדרים היטב בשרטוט. הארכיטקט ביחד עם ה "מהנדסים" יהיו אלה שיגדירו את רמת הפירוט הבאה, כמו למשל הממשקים והמעברים ביניהם.

תכנון ארכיטקטוני סכמתי כזה הוא בעל משמעות רבה יותר מאשר סתם כלי של הסברה ותקשורת. סכמה כזו מאפשרת לנו להריץ את ה Use Cases את ה Scripts  ואת ה Scenarios על הסכמה הארכיטקטונית ולבדוק שהארכיטקטורה מכילה את כל הנדרש לתפעול הנכון של המערכת וזה עוד לפני כתיבת שורת הקוד הראשונה. מה שאומר שאתה יכול לעשות Debugging של הארכיטקטורה לפני שאתה מעביר אותה לפיתוח. תחשבו כמה חסכון ויעילות אנחנו מקבלים רק מהיכולת הזו.

מי שמעוניין לדעת יותר על סכמטיקה של מערכות ארכיטקטוניות מוזמן לעיין בתיעוד ובהסברים באתר של IDesign. ומי שרוצה ללמוד יותר על תפקידו של הארכיטקט מוזמן לסדנת ה Architect's Master Class שתיערך ב 21/12 בארצנו (פרטים בקישור הבא).

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *