מיקרוסופט וורד הינו כלי מס’ 1 של כל ארכיטקט – בלי ספק. ברצוני לשתף כאן כמה כלים חיוניים נוספים שלא הייתי יכול לדמיין את היום שלי בלעדיהם.
- Fiddler. כלי ניטור תעבורת HTTP מזווית ראיה של משתמש קצה. הכלי מאפשר לזהות בעיות ארכיטקטוניות כגון העברת נפחים גדולים מדי, פטפטנות ברשת, בניית מבנה ספריות לא אופטימאלי של קבצים סטאטיים.
- Perfmon. כלי ניטור ביצועים של מנועי ריצה כגון ASP.NET, WCF, IIS. הכלי מאפשר לזהות בעיות עיצוב כמו זריקת Exceptions מרובה, טעינת DLLים דינאמיים מיותרים רבים, עיצוב שגוי לפיו ישנה הקצאת שטחי זכרון רבים ובעיות ארכיטקטורה ועיצוב רבים אחרים.
- SQL Profiler. כלי ניטור גישה לבסיס נתונים SQL Server. הכלי מאפשר זיהוי בעיות עיצוב כמו ריבוי שאילתות, מימוש לוגיקה מסובכת בבסיס נתונים.
- Netmon. כלי ניטור רשת. הכלי מאפשר זיהוי בעיות ארכיטקטורה כמו SOA. אהמ…אהמ… כלומר, זיהוי בעיות הנגרמות עקב מימוש SOA לא אופטימאלי.
מה הכלים שאתה משתמש ואיזה בעיות שכיחות אתה מגלה איתם?
חומר רלוונטי
שמי אליק לוין ואני מתרכז ב- Architecture, Security, and Performance באפליקציות Net.
בזמני הפנוי אני מפתח את עצמי בתחומים רבים אחרים.
This template is made with PracticeThis.com plugin for Windows Live Writer
לפני מספר ימים יצא לי להצטרף לפגישת סיכום של עמיתי, אליק, בפעילות שלו בנושא "Performance Gap Analysis", שהוא ביצע על מערכת אינטרנט של לקוח.
בפגישה נכחו כחמישה אנשים מצד הלקוח כשכל אחד מומחה בתחומו -מפתח מוביל ב - asp.net, ארכיטקט, איש system וכיו"ב.
במהלך הפגישה , כאשר אליק הציג את ממצאיו ומסקנותיו, מדי פעם היה מישהו מהם מהנהן בהבנה והסכמה (שכן הדברים ידועים...).
לאחר הפגישה, במהלך הנסיעה, תהיתי - למה הם היו צריכים את אליק? הרי ביחד יש להם את כל הידע שיש לאליק.
מה בעצם היתרון של אליק?
למעשה, אני משוכנע שכל אחד מהנוכחים, יכול ללמד את אליק לא מעט, כל אחד בתחום מומחיותו.
אז מה כל הקסם?
בעיני, הקסם היה ביכולת של אליק, לאתר, למקד ולהאיר את הנקודות היותר כואבות, יותר משמעותיות וכאלו שהלקוח יכול לטפל בהן. (שאפו).
העניין הביא אותי להגיגים עמוקים יותר: מה זה יועץ? הרי רובינו, הארכיטקטים באים מאותם פרויקטים שבכמותם אנחנו מייעצים. מה עושה ארכיטקט ליועץ טוב?
לדעתי, היכולת להבחין בין הדברים החשובים לדברים היותר חשובים.
אני מניח שיש הרבה שיכולים להגיע לפרויקט ולאתר בו את המקומות הדורשים התייחסות וזה יכול להיות נקודות שונות בהיבטים שונים של המערכת - עיצוב, ארכיטקטורה , אבטחת מידע, ביצועים וכו', זה בעצם היתרון של מי שבא מבחוץ.
הבעיה, שנקודות כאלו יכולות להיות לרוב וברוב הפרויקטים שאני מכיר, אין זמן לטפל בכל.
לכן, בעיני, יועץ טוב ידע "לדוג" מתוך כל הנקודות החשובות, את היותר חשובות - אלו שתהיה להם את ההשפעה הגדולה ביותר על ה"עסק", על המקומות הכואבים ללקוח וכאלו שהלקוח גם יכול לטפל בהן.
ותחשבו על זה, האהאהאה.
הנה טיפ קטן שיעזור לך לבנות מסמך ארכיטקטורה עם סיכוי גבוהה שישתמשו בו.
שאלת את עצמך פעם מה מטרת מסמך הארכיטקטורה? שאלה טריויאלית, נכון? התשובה לא תמיד פשוטה. לא מעט יגידו שמטרת מסמך ארכיטקטורה היא לתאר ארכיטקטורה. דאה…
דע מי הולך לצרוך את המסמך שלך – אחרת תבנה משהו שיבלה את “חייו” במגירה
- אם הצרכן המרכזי הוא מפתח – תכניס דוגמאות קוד והפניות למקורות חיצוניים עם עוד קוד
- אם הצרכן המרכזי הוא מנהל פרוייקט – תקל עליו ותוודא שהוא יכול לחשב עלויות ולו”ז
- אם הצרכן המרכזי הוא ארכיטקט אחר – תפוצץ בTLAים, TOGAFים, AGILEים ושאר הירקות שלאף אחד אין מושג אבל הם מופיעים בכל ספר ארכיטקטורה.
- אם הצרכן המרכזי הוא אנשי תשתיות – סרטוטי פריסה פיזית הם חובה
- אם יש הרבה צרכנים – תגבה את המסמך בתרשימים רבים והסבר תמציתי לכל אחד
- בקיצור – דע WIIFM
- ואל תבנה מסמך עם מיליון עמודים – דרך בטוחה אל המגירה
מה הטיפ שלך למסמך ארכיטקטורה טוב?
חומר רלוונטי
שמי אליק לוין ואני מתרכז ב- Architecture, Security, and Performance באפליקציות Net.
בזמני הפנוי אני מפתח את עצמי בתחומים רבים אחרים.
This template is made with PracticeThis.com plugin for Windows Live Writer
בשנים האחרונות אנו נחשפים ליכולות מדהימות של שמירת מידע. חברות ישראליות מובילות את תחום ההקלטות בו מקליטים כמעט כל דבר אפשרי, שילוב של מצלמות ווידיאו ושמירתם לאורך זמן נעשים דבר שבשיגרה, ומקום האחסנה, גם הוא נהיה וירטואלי – cloud computing.
במילים אחרות, אין שיכחה, המערכות מסוגלות להחיות כל אירוע מהעבר ולהזכיר לנו נשכחות. להראות את מעשינו בצורה חיה ומוחשית. כשנראה זאת שוב - לא נוכל להתכחש לעובדות אפילו אם באמת שכחנו אותן.
אז זהו, שזה לא חדש, להלן קטע מתפלת ראש השנה:
אמת כי אתה הוא דיין ומוכיח ויודע ועד וכותב וחותם וסופר ומונה ותזכור את כל הנשכחות ותפתח את ספר הזכרונות ומאליו יקרא וחותם יד כל אדם בו
גמר חתימה טובה לכולנו!!
אחד הפעילויות המרכזיות בבניית הארכיטקטורה (או סקר ארכיטקטורה) היא זיהוי תסריטים/תרחישים מרכזיים. הכללים לזיהוי התרחישים הם פשוטים:
- תרחיש הכי שכיח, למשל, באתר www.bing.com הוא חיפוש.
- תרחישים שמערבים הרבה טכנולוגיות או תרחישים מסובכים , לכן הם מהווים סיכון גבוהה.
- תרחישים שנמצאים בפוקוס של קודקודים – למשל, דוח רווח והפסד שמופק פעם בשנה עבור מנכ”ל.
הנה טיפ קטן שיכול לזהות תרחישים קריטיים מרכזיים – שאל על הנהלים המרכזיים. לדוגמה:
- בבית חולים יש נוהל “מסדר אחיות” בשעה 10:00. בשעה הזו האחיות עוברות בין החולים ורושמות את הנתונים למערכת – בום! עומס “לא צפוי”.
- בבנק יש נוהל פתיחת יום עבודה – בשעה 9:00 בבוקר הפקידים מעברים כרטיס עובד כדי לטעון את הנתונים – בום! עומס “לא צפוי”.
- בצבא… – טוב, זה כבר סודי :)
מה הטיפ שלך לזיהוי תרחישים מרכזיים?
חומר רלוונטי
שמי אליק לוין ואני מתרכז ב- Architecture, Security, and Performance באפליקציות Net.
בזמני הפנוי אני מפתח את עצמי בתחומים רבים אחרים.
This template is made with PracticeThis.com plugin for Windows Live Writer