הפער- The Gap

הנושא המרכזי במצגת שלי בכנס השנתי הוא הפער ההולך וגדל לדעתי בין ארגוני ה- IT והמשתמשים הארגוניים לבין הטכנולוגיות שנמצאות מחוץ לעולם זה. לבקשת לקוחות אני מעלה את עקרי הדברים בכתב.
טכנולוגיות שנמצאות בשימוש על ידי NITU – none IT technology users. במצגת שנמצאת בלינק הבא והחל משקף 10 תארתי מספר מימדים מתבטע פער זה כאשר פער זה גודל במהלך השנים ואינו קטן!
לפני מספר שנים ארגוני ה- IT רכשו מחשבי Tier 1 לעומת ה- NITU אשר רכשו Non-Brands, ארגוני ה- IT הגנו על עצמם ב-3 מעטפות אבטחת מידע וה- NITU הסתפקו בשכבה אחת. באופן כללי ה- NITU ניסו לחכות את הפעילות בארגוני ה- IT תוך שימוש במשאבים מצומצמים יותר. אולם כעת התמונה השתנתה באופן דרמתי וה- NITU מוליכים את חזית השימוש בטכנולוגיות. לדוגמה:

• ארגוני ה- IT כמעט ולא משתמשים במחשבי MAC כאשר מחוץ ל- IT יש שימוש נרחב במחשבי MAC.
• ארגוני ה- IT רוכשים את המחשבים עבור המשתמשים שלהם כאשר מחוץ ל- IT ישנה תופעה של BOYPC – Bring Your Own PC – המשתמשים משתמשים במחשבים הביתיים שלהם לצורך הפעילות העסקות.
• ארגוני ה- IT (ולקוחותיהם) משתמשים לתקשורת רק ב- MAIL כאשר מחוץ ל- IT יש שימוש גם ברשתות חברתיות כמנגנון לתקשורת. גם במידה והארגונים מכניסים שימוש ברשתות חברתיות הנושא מטופל ברוב המקרים במחלקת השיווק ולא באחריות ה- IT.
• ארגוני IT נותנים שירותים בתצורה של On-Line ו- Batch כאשר מחוץ ל- IT יש שימוש ב- On-Line בלבד.
• ארגוני ה- IT אינם משתמשים בתוכנות חינמיות או תוכנות Open Source (בהקשר זה של שימוש ללא תשלום Redhat לדוגמא אינם נחשבים כ- Open Source כאשר מחוץ ל- IT יש שימוש נרחב בתוכנות מסוג זה.
• ארגוני ה- IT מקיימים תהליכי החלטות מסורתיים הררכיים כאשר מחוץ ל- IT יש שימוש נרחב ב- Crowdsourcing – רתימת העובדים והלקוחות בצורה בלתי אמצעית לקבלת החלטות מרכזיות.
• ה- NITU משתמשים בשירותים ציבוריים בענן (SAAS PAAS IAAS) בצורה הרבה יותר נרחבת מאשר ארגוני ה- IT הסטנדרטיים.

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

מדיניות ניהול נתונים בארגון - Data Governance

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

על הארגונים להתייחס לנתונים כאל משאב כלומר ולטפל\לנהל אותו בצורה ספציפית:
1. יש להגדיר data owner לכל סוג נתונים. ה- data owner – המנהל העסקי האחראי על סוג הנתונים מגדיר מי יכול לגשת אליהם ולשנותם מגדיר את תדירות עדכון הנתונים ועוד.
2. מעבר לכך יש להגדיר Data Stewards שהנם מה- business ולא מה- IT, אשר מטפלים בעצמם בסוגיות כמו טיוב תמידי, גילוי טעויות, דו-משמעויות ומתקנים אותם. מוודאים שהמידע קונסיסטנטי ועוד.
3. בתחום ה-IT נמצא ה- Data Administrator אשר מטפלים בנתונים ברמת ה- IT כולל בניית Data Models, וכד'.

מחקרים מדברים על כך שארגונים אשר יישמו Data Governance נהנים בין היתר מ-
1. אפשרות לבצע פעולות מורכבות המחייבות עבודה על מערכות מחשב שונות.
2. שימוש לקוחות על ידי קבלת מידע מכל המקורות על אותו הלקוח ופעולותיו – כלומר תמונת לקוח 360 מעלות!
3. שיפור תהליכים עסקיים הממנפים את המידע שכבר קיים על הלקוח\מוצר
4. אפשרות לאחד מידע ממספר מקורות על אותו לקוח\מוצר
5. אפשרות קלה יותר לעמוד בתקינה חיצונית גדול SOX BASELL II
6. מאפשר מיזוג קל יותר עם ארגונים\חברות נוספות
7. מאפשר כניסה קלה יותר לתהליכים עסקיים חדשים
8. מאפשר לנצל תהליכים עסקיים קיימים בצורה טובה יותר על ידי שילובם
9. מאפשר שיתוף טוב יותר עם ארגונים מקבילים
10. יוצר קשר יותר טוב בין הארגון לבין הלקוחות
11. מוריד את מספר הממשקים שנמצאים בארגון
12. מוריד את הוצאות התפעול על ידי ביצוע פעולה "פעם אחת" במקום מספר פעמים.
13. מאפשר גמישות טכנולוגית – החלפת מערכות ושיפורן יותר קלה.
14. מאפשר שינוי במערכות בצורה יותר מהירה.
15. מאפשר זמינות גבוה יותר של מערכות וכתוצאה מכך של תהליכים עסקיים.
16. מאפשר לגלות בעיות תהליכים עסקיים בצורה מהירה יותר (דוגמה ל- לקוח הגדיר KPI לאיכות הנתונים העסקיים ובמידה וה- KPI לא בטווח מזהים שיש בעיה עסקית).

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

הדור שידע את יוסף

לאט לאט, או יותר נכון מהר מהר, צומח דור חדש. דור אשר חושב, מרגיש, מתנהג, ואפילו "נושם" אחרת מהדורות הוותיקים. זהו דור האנשים אשר גדלו עם האינטרנט ועם המחשב משחר ילדותם והולכים אתו 'יד ביד' לאורך כל חייהם הצעירים.
לתופעה זו יש מספר השלכות חשובות, הן על התחום הספציפי של מערכות מחשב והן על תחומים רחבים הרבה יותר. לדוגמה, ברוב המקרים הצעירים אינם צופים בטלוויזיה בלבד, אלא משלבים את הצפייה בטלוויזיה עם התקשרות במחשב עם חברים ב-facebook, icq או מדיום chat אחר, ולעתים גם מוסיפים לכך שימוש ב-SMS או ב-twitter.
ישנם אחרים, המתקדמים יותר, שמבצעים פעולות אלו לא דרך המחשב אלא דרך הטלפון הסלולארי. באופן כללי, מעניינת מאוד התופעה של ריבוי המשתמשים, שמספרם גדל והולך, המבצעים את רוב הפעילות שלהם באינטרנט באמצעות טלפונים סלולאריים (כגון iphone) ולא מול מסך מחשב ומקלדת רגילים.

עולם וירטואלי
הדור החדש חי בעולמות וירטואליים. הקשרים החברתיים שהוא יוצר, נמצאים בחלקם או ברובם בעולם וירטואלי - ללא מפגש פנים אל פנים או שיחה פיזית. דור זה מבצע דברים בעולם שקיים רק באינטרנט, לדוגמה: secondlife או FarmVille בפייסבוק. החומרנות של דור זה היא חומרנות שונה. הצעירים קוראים ספרים, שומעים מוזיקה וצופים בסרטי וידאו מבלי שיחזיקו בחדרם ספרים, תקליטורים או סרטים ממשיים. הם גם מצלמים הרבה יותר תמונות וסרטי וידאו, אך אלה אינם מודפסים על נייר או מונצחים על גבי קלטות.
מאפיין התנהגותי הנגרם כתוצאה מצריכה מודרנית זו, הוא הציפייה לתגובה מיידית. באינטרנט, כאשר לוחצים על משהו - מקבלים תגובה מייד. אז אין פלא, למשל, שאב אחד הלך עם ילדתו המתבגרת לפתוח חשבון בנק בעבורה, והיא לא הצליחה להבין מדוע כאשר הם חזרו הביתה, עדיין לא ניתן היה לפתוח את האינטרנט ולראות מיד מה מצב החשבון.
הסיבה היא שבבנקים, נכון להיום, עוברות מספר שעות (בדרך כלל לילה) בין פתיחה של חשבון לבין הקמת החשבון באינטרנט. עם הציפייה לתגובה מיידית, מגיע גם הקושי להתמודד עם דחיית סיפוקים, קושי עליו מדברים המורים בבתי הספר כבר זמן רב.
ממד נוסף הוא צורת העבודה במקביל על הרבה דברים שונים. הדור החדש אינו מבצע משימה אחת אלא מבצע במקביל מספר רב של משימות. אחר הצהריים טיפוסי בחדרו של צעיר ממוצע היום, כולל צפייה בטלוויזיה, צ'יטוט עם חברים (chat), שליחת SMS ו- Twitter ואפילו גלישה באינטרנט - באתרים שאינם קשורים לתכנית הטלוויזיה שעל המרקע – והכול בעת ובעונה אחת. אוסף הגירויים שעוטף אותנו גדל כל הזמן, והדור הצעיר מגיב לגירויים מקבילים אלה ולומד לחיות אתם בטבעיות מסוימת.. מאידך, נראה כי לדור זה קשה יותר לבצע משימה אחת גדולה מתחילתה ועד סופה בצורה מרוכזת. הצעירים מעדיפים לבצע כמה משימות קטנות יחד מאשר להתרכז במשימה אחת גדולה.
ישנם ממדים רבים נוספים, המאפיינים את התופעה, וביניהם הציפייה של דור זה להיות מחובר לאינטרנט כל הזמן ובאמצעותו להתעדכן ללא הפסקה. משום כך, הצעירים אינם סובלים הפרעות או ניתוקים מהאינטרנט או מהעדכונים השוטפים.

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

וירטואליזציה של שרתים - לא הכל טוב

וירטואליזציה של שרתים הינה best practice ידוע. לקוחות מדווחים בין הייתר על שיפור בשירות הן במימדים של ניצולת ויעילות, הן בהיבט של קלות תפעול, אמינות ועוד ועוד.
עם זאת, ישנן מספר היבטים לא מבורכים בשימוש העצום בשרתים וירטואליים. אם בזמנו הוספת שרת הייתה משימה מייגעת - הזמנת חומרה, הכנת מקום\מיזוג\חשמל באולם המחשב, קבלת החומרה , התקנה ועוד- הרי שכעת לפי דברי לקוח (לדוגמה) מדובר על "8 דקות" ויש שרת נוסף באוויר! לכן, כיום, הוספת שרת או שרתים היא אחת הדרכים המקובלות לפתרון או לייתר דיוק בדרך לבדיקה של פתרון. כאשר ישנה תקלה או האטה לא מוסברת, אחד הדברים שעושים אנשי האפליקציות או התשתיות הוא להוסיף שרתים וזאת בתקווה שהדבר יפתור את התקלה. אולי הדבר יפתור את התקלה או שהתקלה לא תחזור. זאת בדומה לביצוע BOOT בשרתי Windows כפתרון או כניסוי לפתרון לבעיה.
הדבר גורם לירידה ברמת המקצועיות וזאת מכיוון שגם אם התקלה לא חזרה - עדיין לא הוכח שהוספת השרת היא הגורם לפתרון כי לא ברור שיש פתרון. אולי התקלה תחזור "ובגדול" במקרים נוספים או אפילו במערכות אחרות.
מעבר לכך הוספת השרתים הוירטואליים גורמת לסיבוך ולמורכבות רבה יותר (נושא שבו דנתי בהרחבה בכנס השנתי שלנו) וכמו כן ישנן סוגיות של עלויות התוכנות - הן תוכנת הוירטואליזציה (במידה ולא מדובר על hyperV) והן התוכנות הספציפיות- נושא מורכב ועדיין לא סגור. וכמו כן מדובר על הכבדה בדרישות האחסון ובפתרונות הגיבוי.

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

על ניהול נכסי טכנולוגיות מידע

מחקר STKI קובע ששנת 2009 הייתה השנה הגרועה ביותר בתפעול השוטף של מערכות מידע בישראל. בשנה זו היו תקלות רבות במערכות מידע קריטיות אשר גרמו להשבתה של תהליכי עבודה מרכזיים בארגונים בישראל.
גם בנק ישראל עד לתופעה זו ולכן פרסם הוראה בשם "ניהול נכסי טכנולוגיית מידע". בהוראה זו מתאר המפקח על הבנקים את המצב ולאחר מכן נותן מספר הוראות חשובות.
בתאור המצב מאפיין המפקח את הכשלים במערכות המחשב במגוון היבטים (ציטוט מהמסמך):
1. קושי באיתור מיידי של הרכיב שכשל.
2. קושי בזיהוי מיידי של נסיבות התרחשות הכשל- מאפיין התקלה, מקור התקלה וכד'.
3. קושי במיפוי כלל התהליכים העסקיים המושפעים מהכשל.
כאשר התוצאה של מאפיינים אלו היא עיכוב בטיפול בתקלה. (עד כאן הציטוט).

חברת STKI מזהה שני גורמים מרכזיים לתקלות רבות אלו. מצד אחד ישנה סיבוכיות רבה בארכיטקטורות המחשב – חומרה, תוכנה ותפעול. הסיבוכיות גדלה מאוד בשנים האחרונות וממשיכה לגדול. אם בזמנו היה מדובר על מחשב MF המכיל את כל התשתיות וכל התוכניות הרי שהיום מדובר על ארכיטקטורה אשר משלבת גם מערכות MF גם מערכות פתוחות המכילות עשרות מוצרים ורכיבים.
הסיבה השנייה שגרמה לנפילות מחשב היא המשבר הכלכלי שאותו חווינו ובמידה מסויימת עדיין חווים. המשבר גרם לכך שישנו קיצוץ מתמיד בתחום התשתיות ובתחום הניהול והניטור. לקוחות דוחים שדרוגים של חומרה ותוכנה, מעכבים פרוייקטים לשיפור השירות ומצמצמים בכ"א והתוצאה הבלתי נמנעת היא נפילות מחשב.
למניעה או צימצום כשלים אלו מנחה המפקח על הבנקים את הבנקים בצורה זו (שוב ציטוט מההוראה ):
1. למפות עבור כל תהליך עסקי מהותי את נכסי טכנולוגיית המידע שתומכים בו לרבות: מאגרי מידע, מערכות מידע, מערכות הפעלה , תשתיות חומרה, תוכנה ותקשורת וכד'. המיפוי יכלול את כל רכיבי ה- IT הרלוונטיים ברמה הפרטנית ככל הניתן (לדוגמה, עד לרמת נתב, switch וכד').
2. להטמיע כלי ניטור, שליטה ובקרה על כל נכסי ה- IT שמופו כאמור בסעיף הקודם על מנת לוודא תקינותם של נכסי ה- IT ובאופן שיתאפר במקרה של כשל זיהוי הנכס ואף הרכיב הספציפי שכשל, ונסיבות הכשל, סמוך ככל שניתן למועד האירוע.
3. עבור נכסי ה- IT שמופו, יקבעו הסדרי גיבוי שאיפשרו את המשך פעילות התהליך העסקי המהותי שכשל. יש לפעול למניעת מצב של נקודת כשל יחידה (single point of failure). עד כאן הציטוט.
המפקח גם קובע לוח זמנים לטיפול בהנחיות אלו.
יש לציין שהנחיות אלו ברוכות ורצוי שגם ארגונים אחרים אשר מסתמכים בצורה מהותית על מערכות המידע יטמיעו הנחיות אלו. ההנחיה הראשונה היא הנחיה יוצאת דופן וחדשנית. נכון להיום בגלל המורכבות הרבה ישנו ברובם המכריע של הארגונים "ספגטי". קשרים מורכבים בין מערכות כך שלמשל קורה לא מעט פעמים שלקוח מוריד שרת לצורכי תחזוקה ומסתבר שמערכת אחרת ש"לא קשורה" מפסיקה לעבוד. זאת מכיוון שאין בארגונים תמונה עדכנית של המערכות והקשרים ביניהם. ההנחיה הראשונה מורה לבנקים לבצע מיפוי של הנכסים ושל הקשרים בינהם. עם זאת, כבמקרים נוספים, הבנק נותן הנחיה כללית אשר יכולה להתפרש על ידי הבנקים בצורה שונה. כאשר המפקח מורה לבנקים לבצע "מיפוי תהליכים" יכולים הבנקים להציב אפילו "סטודנט" אשר יבצע מיפוי פעם בשנה של המערכות ושל הקשרים בינהם. זאת כמובן בעלות זניחה. עם זאת בנקים אשר רוצים לבצע את ההוראה בצורה עמוקה יותר יכולים לבצע אוטומציה של המיפוי עד למצב של automatic discovery שבו תהליך ממוכן ממפה בעצמו את הרכיבים של כל מערכת מחשב ואת הקשרים בין המערכות. פרוייקטים מסוג זה המוגדרים בתעשיה כ- CMDB עלולים לעלות מליוני דולארים הן ברמת רישוי התוכנה והן ברמת הטמעת המערכות. עם זאת רק ביצוע של מיפוי אוטומטי יכול לעמוד בהוראות המפקח על הבנקים בצורה עמוקה וזאת מכיוון שגם אם מבצעים תהליך ידני של מיפוי – לאחר ערב אחד – שבו בגלל תקלה מבצעים תיקון מיידי ושוכחים לעדכן את התיקון במיפוי המערכות – מקבלים מצב שבו בזמן התקלה הבאה אין תמונה אמיתית של מיפוי המערכות והקשרים ביניהם. רק מיפוי אוטומטי יכול להתקרב למיפוי אמיתי כהנחיית המפקח. עמידה בתנאי זה לעומקו תגרור את הבנקים לפרוייקטים של שנה עד שלוש שנים ולעיתים אף יותר.
לגבי שתי ההנחיות האחרות – ביצוע ניטור וביצוע כלי גיבוי, רובם המכריע של הבנקים ושל ארגוני ה- IT באופן כללי מקיימים הנחיה זו – עם כי קבלת הנחייה רשמית מהמפקח תתרום לקבלת תקציבים ועדיפות גם לתחומים אלו. גם לגבי ביצוע ניטור המפקח נותן הנחייה כללית ולא מפרט באיזה סוג ניטור. כיום קיימים מספר סוגים של מערכות ניטור. מערכות הניטור הותיקות המורכבות מ- agnet שמשדר למרכז קיימות ברוב רובם של הארגונים. אולם לביצוע ניטור אמיתי אשר מגלה גם את הרכיב התקול בצורה המהירה ביותר יש גם להשתמש במערות מהסוג של "ניטור חויית משתמש" ומערכות לגילוי מקור תקלה "root cause" ו- Business Transaction Management הפועלות בין הייתר בטכנולוגיה של sniffing. כלומר גם כאן ישנו חופש פעולה גדול של הבנקים בביצוע הוראת המפקח, חופש פעולה שישפיע על הוצאות הבנקים למילוי הוראה זו.
לסיכום מדובר בהוראה חשובה שרצוי שתהיה על שולחנם של מקבלי החלטות רבים – לא רק בתחום הבנקאי.

עדכון MF

להלן רשמים ממפגש שולחן עגול מרתק בנושא MF.
מערכות ה- MF הן המערכות הגדולות והותיקות ביותר בישראל. המערכות הנן הבשלות ביותר והמורכבות ביותר. לא לחינם נאמר ש"מה שממציאים ב- OPEN כבר שכחו ב- MF". דוגמה מייצגת היא הקונספט של VM שבשל כבר עשרות שנים ב- MF ונכנס רק בשנים האחרונות ב- OPEN.
תחום ה- MF עבר בשנים האחרונות שינויים בעקבות השינויים במשק. דוגמה לכך היא צוואר הבקבוק. אם עד לפני כ- 5 או 10 שנים צוואר הבקבוק המסורתי ב- MF היה מהלכי ה- batch בלילה, הרי שכעת, בעקבות אתרי האינטרנט, מסחר מקוון וכד', הרי שצוואר הבקבוק הוא כעת ב- on line.
בדיון עלו נושאים רלוונטיים כמו עתיד ה- MF ברמה האסטרטגית, כ"א בתחום MF, עלויות וכד'. נקודה ספציפית וחדשנית שעלתה בדיון היא שימוש במעבדים היעודים כגון ה- IFL, zAAP וה- zIIP. עיקר ההתייחסות בסיכום היא בתחום של IFL. בדיון עלתה האפשרות לבצע Rehosting או Offloading. לקוחות מתעניינים בתחום אך לנכון להיום לא בוצעו פרויקטים גדולים בתחום בישראל.
היה מאוד מעניין לראות את השונות בין הארגונים. לדוגמה, בנושא של כ"א , כל הארגונים מודעים לבעייתיות אך ישנם ארגונים אשר לא מרגישים על בשרם את המחסור כי הם מצאו דרך לגייס אנשים ולהכשיר אותם זאת לעומת ארגונים אשר כבר היום חשים על בשרם את המחסור. כנ"ל בתחום של עלויות MF. ישנם ארגונים אשר מודעים לעלויות של MF אך לדעתם שיש תמורה לעלות – זמינות, מרכזיות וכד'. ארגונים אלו משתדלים לחסוך אך רק באמצעים מקובלים. כלומר אין דגש עצום על הורדת עלויות MF. לעומת זאת ישנם ארגונים אשר הנושא של עלויות ה- MF הוא ב"נפשם" ומנסים כל דרך, אפילו דרכים חדשניות, להוריד עלויות בתחום זה.

Cutter Advisor- Java vs. .NET revisited

My article on this major issue was published as Cutter Email Advisor.

This article is general. I will put this shortly in Hebrew with more insight about the Israeli market where .Net is much more dominant.

Five to seven years ago, Java versus .Net was a hot topic. At that time, many organizations were at this important crossroad. Now, they have all made up their minds. But some are reconsidering their previous decision.

Putting it very briefly, .Net currently is more common in smaller, front-end projects, where integration with the desktop is essential, while Java is more common in larger, back-end projects, where legacy platforms run the core business applications and where integration with legacy systems is crucial.

While revisiting this issue, I have made the following interesting observations:

1. It is possible for Java programmers to convert to .Net. However, the reverse -- .Net (mainly C#) programmers that convert to Java -- is not trivial or is even impossible economically for many programmers.
2. Many clients consider Java as a more difficult language and is associated with less productivity than .Net. While our research was not able to prove this, it does appear that Java has more options than .Net. Performing specific tasks or requirements in .Net in many cases is more obvious or straightforward than in Java, where there are many ways and many options to perform the same task. This means that Java organizations have to invest more in standards, guidance, architecture, and software infrastructure. Also, the technical management in these organizations requires more experience and should have more control.
3. A well-known pain point of .Net, and Microsoft solutions in general, is backward compatibility. When upgrading to a new version or technology, there are a lot of rewrites. The Java environment is more mature in this respect, although backward compatibility is always an issue and the acquisitions policies of leaders in the Java ecosystem, such as Oracle and IBM, do not contribute to backward compatibility either.

Conclusion

It is very interesting to return to a specific dilemma and to see how things have evolved over the years. No technology is here to stay forever, though legacy technologies such as Cobol have remained much longer than anyone anticipated.

The latest trend to shake the IT world is cloud computing. While considering Java versus .Net for cloud applications, Java has several advantages. Cloud entrepreneurs try to build their applications on open source that offers much freedom and less expense. However, it appears that many cloud applications are not built on Java but with other languages, such as PHP, Python, and Perl, or even such proprietary languages as Apex from Salesforce. Microsoft also exists in cloud environment with its "S plus S" (software plus services) initiative and Azure Platform.

On the other hand, Oracle's purchase of Sun Microsystems will influence the future of Java. Sun has kept Java part of the open source community. Oracle has less commitment to open source, and it remains to be seen how this will influence Java and its adoption

בשלות VMWARE

שימוש בפתרונות וירטואליזציה להרצת שרתים בייצור כבר הפכה לפני זמן רב ל- best practice בארגוני IT רבים. ספקי תוכנה רבים כבר אישרו את האפליקציות שלהם לעבודה בסביבה וירטואלית. עם זאת ישנם ספקי תוכנה לא מועטים שעדיין לא אישרו את הרצת הפתרונות שלהם בסביבה וירטואלית ובמקרה כזה ישנה דילמה של מנהלי התשתיות בארגון. האם לאשר הפעלה של פתרונות תוכנה בסביבה וירטואלית גם ללא אישור הייצרן? מסתבר שישנם מספר לא מבוטל של ארגונים אשר למרות חוסר האישור - כלומר אי קיום certification לסביבה וירטואלית - בוחרים להריץ את הפתרון בסביבה וירטואלית.
זאת ועוד, לאחרונה ביקרתי בארגון מוביל בישראל אשר ביקש אישור מיצרן תוכנה מוביל להריץ מוצר מסויים בסביבה וירטואלית. יצרן התוכנה ציין שהוא אינו ממליץ להריץ את המוצר בסביבה וירטואלית ולמרות זאת בחר הלקוח להריץ בסביבה וירטואלית. מבחינתי זהו סימן נוסף לכך שלקוחות סומכים יותר ויותר על הפתרונות הוירטואלים ובראשם VMWARE כתשתית בשלה ויציבה.

זריזות מתחילה מלמעלה

דיברתי עם אחד הלקוחות על הנושא של agile software development. הגורם לשיחה זו היה העובדה שבאותו ארגון פרויקטים רבים מסתיימים באיחור ועוד יותר חמור ישנם פרויקטים שפותחו ומסתבר שלא מתאימים לדרישות הלקוחות. מתודולוגיית agile אמורה להקל בצורה משמעותית על שתי בעיות אלו – עד למצב של פיתוח ב- 50% זמן\עלות!
אולם, לאחר שדנו במקצת בעקרונות המתודולוגיה עצר אותי המנהל ושאל- האם מתחלים לפתח קוד "אמיתי" לפני שביצענו אפיון מפורט ואישרנו אותו על ידי כל הגורמים? ובכן התשובה היא – כן. ב- AGILE לא מגיעים לאפיון מפורט לפני תחילת הפיתוח. הלקוח עצר אותי ולא רצה לשמוע יותר. הוא לא מוכן לפתח אם לא ביצע אפיון מפורט וקיבל אישור מכל הגורמים. לא עזרו ההסברים שלי שזאת כל המהות ב- AGILE . שינוי דינאמי של הדרישות והאפיון הספציפי.
ואכן, כפי שאמרתי בכותרת לפוסט – זריזות מתחילה למעלה- בראשו של המנהל. הפחד מסיטואציה שבה "לא קיבל את האישורים מכל הגורמים" עוצר את הלקוח מכניסה לתהליך שעשוי לשפר בצורה משמעותית את תהליך פיתוח התוכנה בארגון.

לרוץ אחרי הטכנולוגיה

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

CC to you my boss

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

מנהל טוב חושב קדימה

עקב המצב הכלכלי רובם המכריע של המנהלים בתעשיית ה- IT משקיעים את כל מרצם בחסכון כאשר במקרים רבים משמעותו של חסכון הוא הקפאת המצב הנוכחי בכל מה שניתן. תחת המנטרה "אם לא חייבם - לא עושים". עם זאת, פגשתי לאחרונה מנהל IT אשר חושב אחרת. בארגון IT זה אחת המערכות המרכזיות מבוססת על פלטפורמת Legacy. פלטפורמה שעדיין נתמכת ועדיין יציבה אך מכיוון שמדובר בחומרה ספציפית אין לקוחות חדשים לפלטפורמה, אין עובדים אשר מתמחים כעת בפלטפורמה זו כלומר מדובר ב- Legacy בהגדרה. המנהל, למרות הלחץ התקציבי החליט לבצע מהלך של רענון המערכת והסבתה לפלטפורמה סטנדרטית - X64. למהלן זה מספר סיבות ארוכות טווח ביניהן רצון לשיפור ביצועים, הורדת תלות בספק ספציפי , הורדת עלויות ועוד. אך הסיבה המרכזית הינה הרצון לגרום לעניין אצל העובדים על ידי הכנסה של טכנולוגיות חדשות ועדכניות. מהלך זה יעודד את העובדים ללמוד ולהתקדם כי נכון להיום העובדים שמתמחים במערכת מרגישים שהם נשארים מאחור. מצד שני כאשר עוברים לפלטפורמה סטנדרטית העובדים גם מבינים שיש לידע שברשותם תחליף ולכן הם יתאמצו יותר.
אין ספק שמהלך זה בטווח הארוך גם יוריד עלויות אולם בתקופה הקרובה הוא מחייב גם השקעה מסויימת - גם אם לא השקעה גבוהה.
לסיכום, למרות שמהלך רענון הפלטפורמה אינו MUST , המנהל חושב קדימה ומחפש דרכים לקדם ול"עורר" את העובדים בארגונו. מבחינתי זאת דוגמה טובה לניהול נכון.

ריקוד כלכלה – IT

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

ציוד צבאי - ציוד אזרחי

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

איזה גודל?

במספר פגישות שקיימתי לאחרונה לקוחות טענו שכאשר נכנסו לפרוייקטים גדולים הם בצעו sizing מסודר עם היצרן\ספק. ובמספר רב של מקרים הסתבר שה- sizing היה מוגזם. כלומר בפועל היה צריך לרכוש הרבה פחות ציוד ממה שהומלץ על ידי ה- sizing. לפיכך, אנו ממליצים ללקוחות לבצע רכישות בצורה השמרנית ביותר, בייחוד בתקופה הנוכחית, ברוב רכיבי המערכת. המקרים היחידים שבהם כדאי לבצע רכישה שמרנית היא בסביבת שרת מסד הנתונים ושרת האחסון. בשאר הרכיבים כגון שרתי האפליקציה ושרת ה- WEB ניתן להסתמך על יכולות של scale out ואפילו על וירטואליזציה בכדי לחסוך בתקציבים יקרים.