ארכיטקטורה vs. טכנולוגיה

כשמדברים עם מישהו על "ארכיטקטורה", השיחה עולה בדרך כלל  על פסים של טכנולוגיות. עדיף Java או אולי C++? נכתוב על Windows או דווקא על לינוקס? נשתמש ב-CORBA או אולי ב- COM? ראיתי אפילו קורסים בכמה מכללות אשר מציעים היכרות כללית עם טכנולוגיות שונות וקוראים לזה "קורס בארכיטקטורה".

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

מה זה "מה"?

• האם עדיף לבנות מערכת מסויימת כאפליקציה עם תהליכים מקביליים או כ-Single Task?
• האם מערכת מבוזרת עדיפה על פני מערכת מונוליטית?
• איך לייצר את התיאום והשיתוף בין שני מודולים במערכת?

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

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

ארכיטקטורה כגישה

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

בפוסטים הבאים שלי, אתייחס בפירוט לכמה דוגמאות המציגות את ה"פרקטל" הזה.