בלא מעט מצבים התברר שהארכיטקטורה לוקה במה שאני מכנה “Over Architecture”. במקרים אלו נעשה שימוש מוגזם במתודולוגיות ארכיטקטוניות, לרוב שלא לצורך, ותמיד על חשבון שימושיות היישום. דוגמה קלאסית לכך היא מקרה בו, על מנת להעביר Message בין מספר שלבים ביישום, נבנתה שרשרת שלמה של תורי MSMQ ומנגנוני WF המחליטים על היעד הבא של ה- Message, כאשר בבדיקה פרטנית התברר שאין צורך לא בזה ולא בזה, ושימוש בקריאות ישירות היה מפשט את היישום, מסייע לביצועים ולא פוגע כהוא זה בפונקציונליות המערכת.

מחלת ה- Over Architecture תוקפת לרוב ארכיטקטים צעירים בתחילת דרכם, המניחים שככל שהארכיטקטורה שהם יבנו תהיה מורכבת יותר ותיראה טוב יותר ב- Power Point, כך תעלה קרנם בעיני הבוס ושאר המנהלים. ההנחה הזו מחזיקה מעמד עד הרגע בו יש לממש את הארכיטקטורה, ואז מתגלות כל הבעיות הקיימות בה.

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

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

העיפו מבט כאן – מאוד יתכן שנוכל לסייע לכם. נשמח לעשות זאת!