רשמים מכנס re:Invent של AWS

זאת הפעם השנייה שהשתתפתי בכנס מעניין זה. מדובר על כנס ענק בו נכחו יותר מ-30 אלף משתתפים.

ניתן היה להרגיש את העוצמה והביטחון העצמי של AWS כמובילים המוחלטים של תחום הענן.

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

מגמה מרכזית שהודגשה בכנס היא תחום ה- AI – Artificial Intelligence.  AWS הרחיבו באופן מהותי את הצעת הפתרונות שלהם בתחום בעיקר סביב machine learning ותשתית לבנייה של Bots. שירות ראשון בתחום זה הנו AWS Polly אשר מתרגם טקסט לדיבור אנושי ב-24 שפות (עברית לא נמצאת בין שפות אלו). שירות שני הוא Amazon Recognition אשר מנתח תמונה וחוזר עם פרמטרים מובנים כגון "האם מרכיב משקפיים", "האם גבר או אישה" "האם שמח" וכד'. שירות מהותי נוסף הוא Amazon Lex  וזהו שירות ניתוח טקסט – ה"מוח" שמבין מה המשמעות (לפי קונוטציה) ומקבל החלטה. זהו הרכיב החכם שנמצא מאחורי Amazon Alexa המותקן ב- Amazon Echo הרמקול החכם שמקשיב ומבצע פקודות.

כחלק ממגמת ה- AI הכריזה AWS גם על שירותי מחשוב חדשים המאפשרים ביצועים משופרים הנדרשים במיוחד לשלב הראשוני של "לימוד" האלגוריתמים של machine learning. מדובר על שימוש במעבדים גרפיים (GPU) ואפילו על תכנות חומרה באמצעות תכנות מעבדי FPGA.

מגמה נוספת היא הרחבת יכולות בתחום ה- IoT. ב AWS הכריזו על רכיב תוכנה בשם AWS Greengrasse  אשר מותקן על התקן ה- IoT על ידי היצרן. רכיב תוכנה זה מתקשר באופן טבעי לשירות ה- AWS IoT platform ואפילו יכול לבצע חלק ממשימות החישוב בהתקן עצמו. בכך מצהירה AWS שהיא מקבלת את העובדה שלא כל החישובים יכולים להתבצע בענן המרכזי – חלקים צריכים להתרחש בסביבת ההתקן (ב- Edge).

המגמה השלישית שנזכיר כאן היא השקעה גדולה יותר של AWS לכיוון ארגוני ה- enterprise. סממן ראשון למגמה זו היא ההסכם האסטרטגי עם VMWARE. ארגון יוכל להעביר שרת בין סביבת ה- vSphere המותקנת אצלו לענן של VMWARE שנמצא ב- AWS. מדובר על הורדת מחסום גדול לצוותי התשתיות אשר יכולים לנצל את יכולות הענן ללא ביצוע שינוי בתשתית (שינוי טכנולוגיית hypervisor) וללא לימוד של טכנולוגיה חדשה  תוך ניצול מלא של ההשקעה הקיימת שלהם בהקשר של ידע ואף בהקשר של רישוי.

נדבך נוסף המצביע על השתדלות AWS לכיוון ה- enterprise הוא האפשרות להריץ את גרסת הלינוקס של AWS באתר הלקוח כך שבעתיד יוכל להעביר את המערכת לענן ללא צורך לבצע התאמות ובדיקות (בהקשר מערכת ההפעלה).

והדבר הכי משמעותי בהקשר זה הנם הפתרונות המאפשרים להעביר כמויות מידע גדולות מתוך ה- enterprise לענן. בכנס הוכרזה גרסה חדשה ובעלת קיבולת גדולה יותר של ה- AWS Snowball Edge – סוג של מזוודה שלתוכה מעתיקים מידע מתוך הארגון. ואז שולחים את המזוודה (המידע בה מוצפן) ל- AWS. פתרון שני בתחום זה הוא ה- AWS Snowmobile שהוא משאית ענקית המאפשרת העברה של 100 PETA  של מידע (בכדי לתת סדר גודל, אני מעריך שבישראל נמכר פחות שטח אחסון לארגוני enterprise בשנה!!).

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

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

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

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

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

– פיני כהן.

רשמים מכנס re:Invent של AWS

שינויים בכישורים, בהכשרות ובמבנה של מחלקת התפעול והתשתיות

 

  • כ"א בתחום התשתיות (אחסון, שרתים, תקשורת DC) יקטן בשיעור של 20%-25%
  • באופן יחסי צוות הסיסטם יגדל, צוות האחסון יקטן
  • על כל חברי הצוות להיות מנוסים בתכנות ולכן יש לגייס כ"א חדש ולהכשיר את כ"א קיים
  • צוות הענן יהיה חלק מצוות התשתיות הכללי

הדרישות העסקיות החדשות, המעבר לענן הציבורי והפרטי וההבשלה ההדרגתית של טכנולוגיות כגון ענן ציבורי, ענן פנימי, SDN, SDS, Containers-Docker ועוד, גורמות לשינוי מהותי בהתנהלות צוותי התשתיות והתפעול.

במסמך זה ננסה לתאר את השינויים שיתרחשו בגודל, במבנה ובכישורים הנדרשים בצוותי תשתיות ה- DC (Data Center):  אחסון, סיסטם ותקשורת DC.

הפוטנציאל של שימוש בענן פנימי \ אוטומציה הוא גדול עד לפקטור של פי 10. לדוגמא, חברת אינטרנט ציינה שלפני 10 שנים (עוד לפני וירטואליזציה\DEVOPS, כאשר עבדו עוד על solaris) זמן ההפעלה/הקמה של 100 שרתים לקח בסביבות 3 חודשים. כעת מבצעים זאת ב- 3 שעות! עם זאת, מספר האנשים בצוות התשתיות\תפעול לא ירד כי כעת מבצעים פי 10 יותר פעולות, כלומר הם מהווים enabler עסקי באופן יותר משמעותי.

אולם על אף הפקטור של פי 10 שהוזכר כאן, כאשר מדברים על ארגוני enterprise, נראה שכאשר מיישמים ענן פנימי אמור להיות פקטור של חסכון של כ- 20%  – 25% ממספר האנשים, כאשר:

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

מבחינת מבנה ארגוני ישנן מספר גישות:

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

גישה אחרת מדברת על שמירת המבנה של אחסון-סיסטם-תקשורת אך מעלה את הצורך להוספת גוף מנחה-מקשר גם בין גורמי התשתיות וגם בין הפיתוח לתשתיות, שניתן לכנותו גוף Devops או "תשתיות Devops- ענן". בתוך כל צוות ספציפי (לדוגמה אחסון) יהיו אנשים אשר יטפלו באחסון "הישן" ואחרים באחסון "החדש" (כלומר ב- SDS). אנשי ה"ענן" מתוך כל הצוותים יוגדרו כ- COE – center of excellence  או "חוליית ענן" ויימדדו על פי הצלחתם.

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

לדוגמה:

  • לבנות "חוליית תקלות" משותפת לצוותים אשר מטפלת בתקלות באופן מאוחד. כלומר, כאשר יש תקלה ב- DC תמיד מתכנסת "חוליית התקלות" ומטפלת ביחד- לא מטפלים בנפרד האחסון, הסיסטם והתקשורת.
  • לבנות "חוליית התקנות" אשר אחראית באופן משותף על התקנה של פרוייקטים חדשים.
  • לבנות "חוליית design" אשר אחראית באופן משותף על design של מערכות חדשות (ביצוע sizing לפרויקטים, הכוונה בטכנולוגיות וכד').
  • לבנות "חוליית בדיקות" אשר אחראית באופן משותף על בדיקות של מערכות שנכנסות לייצור.
  • במידה ויש מערכת גדולה במיוחד, לבנות "חוליית מערכת" אשר תהיה אחראית באופן משותף על המערכת.
  • לבנות "חוליית DR" אשר אחראית באופן משותף על נושא ה- DR ב- DC.

וכד'. כלומר יש להתייחס לאחסון-תקשורת DC וסיסטם באופן מאוחד.

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

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

שינויים בכישורים, בהכשרות ובמבנה של מחלקת התפעול והתשתיות

על 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 עם פלטפורמה חדשה שיכולה להוות תשתית מרכזית בקרב ארגונים רבים.

על LinuxONE

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

To GRC or not to GRC? זאת השאלה!

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

בעולם 54% מהחברות משתמשות בטכנולוגית של GRC אך בישראל השימוש בפתרונות GRC הנו בשיעור של פחות מ –15%!

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

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

שורה תחתונה: GRC הנה מתודולוגיה בוגרת עם כלים יציבים וישראל מוכנה ליישומם

פרויקטי IT – מסיוט ליצירת ערך עסקי אמיתי

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

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

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

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

בניית DC – רק אם אין ברירה!

אם בעבר ארגונים נטו בעיקר לבנות ולתפעל את  אתר ה- DC שלהם באתר החברה ורק לקוחות קטנים השתמשו בשירותי hosting הרי שכעת ישנה נטייה להשתמש יותר ויותר בשירותי hosting הן לצרכי סביבת הייצור והן לצרכי DR ופחות לבנות ולתפעל את ה- DC באתר החברה.

בין המגמות שתרמו לשינוי גישה זו ניתן לציין את הקושי גובר והולך בתכנון וניצול שטחים בתחום והתוצאה היא שישנם ארגונים רבים אשר "נתקעו" עם שטחים רבים לא מנוצלים ואשר מחייבים אחזקה (מערכות האלקטרו-מכניות) יקרה. כמו כן הענן הציבורי שנכון להיום לא תופס נפח גדול בפעילות ארגוני ה- enterprise בישראל מוסיף גם הוא לתחושת האי הוודאות בתכנון ה- DC. במקביל היה שיפור בפתרונות lights out management המאפשרים השתלטות מרחוק על אתר DC ובכך לצור dark site – אתר המנוהל לגמרי מרחוק דבר המקל על שימוש באתר hosting. בנוסף לכך ההיצע והאיכות של פתרונות ה- Hosting בישראל גדל והשתפר –  ישנם יותר שחקנים שמציעים יותר פתרונות בין היתר שירותים מנוהלים כגון NOC (מרכז בקרה) בשעות הלילה שירותי גיבוי, שירותי רפליקציה של מכונות וירטואליות. ספקי ה- hosting הישראליים המתקדמים מציעים פתרונות ענן שעשויים להקל מהותית על שימוש בענן ללקוחותיהם – ענן ציבורי ב- latency של LAN !

שורה תחתונה: שימוש ב- DC ציבורי לצרכי hosting או DR הופך להיות הסטנדרט המקובל בקרב ארגוני Enterprise בישראל.

האתגר הבא בעולם השיווק (הטכנולוגי): Hub שיווקי לניהול אינטראקציות שיווקיות עם הלקוח

מנהלי שיווק ומנהלי חויית לקוח חייבים כיום להתחיל לבחון יישום כלים טכנולוגיים לבניית ה- HUB המרכזי לניהול כלל פעילויות השיווק עם לקוחות הארגון. מספר כוחות המניעים צורך זה: הראשון, במלים פשוטות – פשוט אין למנהלי שיווק ברירה אחרת. הקמפיינים הקלאסיים (והכלים הטכנולוגיים המנהלים אותם) כבר אינם מספקים. כלי שיווק קלאסיים עוצבו על מנת לענות על צרכי טכניקות שיווקיות שכיום כבר אינן רלוונטיות. הזירה השיווקית עברה לדיגיטל וכלי הנשק בזירה זו הנו טכנולוגיה. תוצר לוואי של מעבר זה הנו היכולת למדוד ולנטר כל פעילות שיווקית. אנשי השיווק לא רק הופכים להיות יותר טכנולוגיים (הגדרה חדשה בתחום – CTMO Chief Technology Marketing Officer – מעין CTO לעולם השיווק), אלא הם במידה רבה הופכים להיות אנשי נתונים ואנליטיקה.

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

שורה תחתונה: האתגר העיקרי של מנהלי השיווק, CMOs ומנהלי חויית לקוח יהיה בניית ה- Hub הארגוני שיסייע בקבלת תמונה מלאה ורחבה של האינטראקציות השיווקיות עם הלקוחות ויסייע להן בקבלת החלטות אסטרטגיות (כיצד לעצב חוייה יותר טובה) וטאקטיות (מתי ואיך לפנות ללקוח, באיזה ערוץ ובאיזה רגע) יותר טובות. זוהי הזדמנות מצוינת לחיזוק הקשר בין  IT/CIOs למנהלים אלה, שבמידה רבה תלויים בטכנולוגיה ככלי הנשק העיקרי שלהם באתגרים חדשים אלה.

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