על LinuxONE

יבמ הכריזה בשבוע שעבר על LinuxONE, פלטפורמה חדשה להרצת מערכות לינוקס המבוססת על טכנולוגיית המעבדי ה- Mainframe המתקדמת (מדובר על המעבדים הותיקים ביותר בשוק). מדובר על בחירה טובה של IBM להתרכז בלינוקס. הדבר המדגים את חשיבות לינוקס והמקום המהותי שסביבה זו תופסת הנה שמיקרוסופט תומכים בסביבה זו וגם מתגעים בשימוש הרב של לינוקס בסביבת AZURE.

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

הפלטפורמה הנה שילוב של חומרה ותוכנה המוכנה מראש לעבודה – מה שנקרא בשוק כ- converged infrastructure במימדים גדולים (לעומת hyperconverged המדברת על שילוב של חומרה קטנה במימדים קטנים ואשר מתחברים אחד לשני).

נראה ש- IBM בצעה השקעה מהותית בפלטפורמה זו. בין הייתרונות הישירים ניתן להזכיר את כוח החישוב הגדול – מדובר על המעבדים המהירים ביותר בשוק (5 GHZ) , שימוש ב- 4 רמות של memory cache,  תמיכת חומרה יעודית הן ב- IO והן בביצוע משמימות קריפטוגרפיות.  מדובר על אחת מהמכונות החזקות בשוק, במיוחד למשימות שדורשות הצפנה והרצה של מסדי נתונים מהדור המתקדם. תכונות נוספות של הפלטפורמה היא מערכת אנליטית עצמית אשר מקבלת נתונים על ניצול המשאבים ובריאותם ויכולה לתת המלצות ואף לבצע פעולות הקשורות להרצת המשימות וזמינות המערכת (כאשר מתקבלת התראה המערכת מעבירה יישום מרכיב פיזי אחד לשניה – לפני שהתרחשה התקלה).

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

אכן נראה ש-יבמ מכוונת כאן לחברות מהדור החדש ולמערכות מתקדמות וזאת גם לפי הטכנולוגיות המתקדמות שנתמכות כאן (רשימה חלקית): nodejs scala erlang ruby tomcat ruby python  puppet chef docker chef Openstack vreliaze   mariadb mongodb postgresql Cassandra couchdb  oracle db2 mysql Hadoop infosphere  spark.

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

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

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

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

STKI Market Pulse – עדכונים מהירים על קצה המזלג:

מיהו ה- CTO החדש?

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

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

שורה תחתונה: חלוקת האחריות בין הגורמים המקצועיים לבין ה-CTO  אינה טריוויאלית ומחייבת עבודה בשיתוף פעולה כאשר לעיתים ה-CIO  נאלץ לבצע החלטה כאשר ישנם נושאי מחלוקת. אך ברוב המקרים העבודה מתבצעת בשיתוף פעולה, כאשר כל גורם תורם כמיטב יכולתו.

שימוש במוצרי BI במודל קוד פתוח

לאחרונה קיבלנו כמה פניות מארגונים ששוקלים שימוש בכלי BI קוד פתוח. המניע לשאלות אלה בתחום ה-BI ספציפית הנו ברובו הגדול של המקרים בו אנו נתקלים – חיסכון בעלויות רישוי. חלק מהארגונים מעוניינים להרחיב משמעותית את השימוש בשירותי BI אל מעבר למשתמשי ה-BI הקלאסיים (כיום % משתמשי ה-BI עומד על כ-30% מכלל העובדים), לשותפים חיצוניים או ללקוחות. במקרה זה, ה Business case של שימוש במוצרי קוד פתוח הנו ברור. כאשר בוחנים כלי BI קוד פתוח, מעניין לראות כי בתחום זה ספציפית, כל שלושת המוצרים הבולטים נרכשו על ידי חברות טכנולוגיות:

• Pentaho – אשר נרכשה לפני מספר חודשים על ידי HDS במטרה המוצהרת להיכנס לתחום האנליטיקה ב-IoT analytics
• JasperReport – נקנו על ידי Tibco
• BIRT – חלק מ Eclipse, נדחף על ידי Actuate- כיום חלק מ-Open Text.

רוב השימוש בכלים אלה עד כה הנו לחברות טכנולוגיות המעוניינות לפתח רכיבי BI ולשלבם בתוך האפליקציות שלהם אותן הן מוכרות לשוק (Embedded BI). אולם מודלי הרישוי – המאפשרים גישה למסה של משתמשים, הרבה יותר מותאמים ל Customer facing BI מאשר אלה של רוב ספקי ה-BI המסורתיים. כתוצאה מכך, אנו צופים שארגונים אשר יהיו מעוניינים להציע שירותי BI אל מחוץ לגבולות הארגון יבחנו ברצינות מודל קוד פתוח. ייתכן והדבר יוביל בסופו של דבר לרצון לממש כלי קוד פתוח גם לשימוש של BI פנים ארגוני לעובדים (אך כיום ובעתיד הנראה לעין אנו לא רואים מגמה כזו בארגוני Enterprise).

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

שורה תחתונה: פתרונות במודל קוד פתוח בתחום ה-BI מהוות אלטרנטיבה טובה אשר ראוי לבחון ב use case של שימוש חיצוני כלפי שותפים/ ספקים / לקוחות הארגון, אך יש להיערך לנושא התמיכה ולוודא כי יש גישה לידע הנדרש, בין אם בהתארגנות פנימית או בהסתמכות על כ"א חיצוני.

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

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

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

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

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