חוויות מסדנת הארכיטקטים של Juval, יום שלישי, אחה"צ, טיול בעננים

6 בינואר 2009

אין תגובות

קטע קטן של הדיון הטכנולוגי היום עסק בלהיט החדש "דוט נט Service Bus". מובן שההסתכלות בסדנה היתה מאספקט ארכיטקטוני. הסתכלות מהכיוון הארכיטקטוני שונה לחלוטין מהסתכלות מהכיוון הטכנולוגי כפי שהוצגה המערכת ב PDC. אבל Juval סיפר באותה הזדמנות למשתמשים שההרצאה שלו לקבוצת המשתמשים מחר בערב תיכנס לנושא הזה הרבה יותר עמוק מהבחינה הטכנולוגית. ניצלנו את ההזדמנות ומשתתפי הסדנא ביחד עם Juval תרגלו בפועל את אחת מההדגמות הרבות שהוא יבצע בהרצאה לקבוצת המשתמשים (ואני לא אהרוס לכם את ההפתעה ואספר לכם מה עשינו בענניםעם תשתית ה Azure).

זו הזדמנות טובה להזכיר לכל מי שלא יודע, שמחר ב 17:30, יש מפגש מיוחד של חברי קבוצת המשתמשים עם Juval, בנושא Introducing the .NET Service Bus. להלן הקישור לדף ההרשמה לארוע, למי שרוצה להיות ילד טוב ולהודיע שהוא מגיע, ולא להיות ילד רע ולבוא סתם ככה בלי להודיע.

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

כתיבת תגובה

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

חוויות מסדנת הארכיטקטים של Juval, יום שלישי, בוקר, ארכיטקטורה וטכנולוגיה

3 תגובות

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

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

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

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

כתיבת תגובה

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

3 תגובות

  1. Arnon Rotem-Gal-Oz6 בינואר 2009 ב 21:23

    לגבי ארכיטקטורה וטכנולוגיה אני מסכים חלקית
    ארכיטקטורה וטכנולוגיה מאד קשורות יחד עם זאת לדעתי צריך לתכן את הארכיטקטורה שמתאימה לבעיהף לחפש טכנולוגיה מתאימה ואז לתקן
    אם אתה מתחיל מטכנולוגיה הארכיטקטורה שלך תהיה מוגבלת למפי המגבלות של הטכנולוגיה שנבחרה
    כלומר יש כאן היזון דו כיווני – כתבתי על זה מספר פעמים לדוגמא
    http://www.rgoarchitects.com/nblog/2005/11/11/SAFMappingDontForgetTheTechnology.aspx
    וגם http://www.ddj.com/dept/architect/192600570

    בנושא מרחב הבעיה – גם כאן אני מסכים חלקית אבל פחות
    הדרישות הארכיטקטוניות הן *בעיקרן* לא קשורות לפונקציונאליות הספציפית הן מה שנקרא בטעות "דרישות לא פונקציונאליות" או בשם יותר מתאים מאפייני איכות
    אבל גם חלק מהמבטים על ארכיטקטורה קשורים למרחב הבעיה (כמו חלוקה למודולים/שרותים) ומאפיני האיכות עצמם גם נובעים ממאפייני מרחב הבעיה למשל דרישה לזמינות במערכת צבאית קרבית שונה כנראה ממערכת נוכחות במפעל וכו

    הגב
  2. GadiM6 בינואר 2009 ב 22:29

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

    הגב
  3. Arnon Rotem-Gal-Oz7 בינואר 2009 ב 0:50

    לדעתי לSolution Architect זה נכון
    לProduct line architect פחות ולenterprise architect בכלל לא נכון

    הגב