תגית: BCP

9-1-1, BCP & GCP

Disney+ 9-1-1 זה בית ספר לBCP?

בזמן האחרון אני צופה בדיסני+ בסדרת מכבי אש בשם 9-1-1,הגעתי אליה דרך קליפים קצרים בyoutube shorts ומשחקת בה ג'ניפר לאב היואיט האהובה משולחן לחמישה (כולנו זקנים מספיק כאן בשביל לזכור את שרה משולחן לחמישה?)

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

אז זהירות ספויילר אם אתם צופים כמוני 😊

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

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

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

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

ענן חדש בא לשכונה

אני מרגיש שאני צריך לקצר קצת את זמני התגובה שלי אבל החיים לא תמיד נותנים לי את הבחירה הזו, בכל מקרה לפני שבועיים נערך בוגאס הכנס הטכני השנתי של גוגל, google cloud next,  ובמסגרתו הוכרזו שרתי Bare Metal חדשים. כן, גם אני שמתי לב שגםהכנס הטכני השנתי שלנו בנוטניקס נקרא .next אבל היי אני לא בוחר את השמות ואגב לא מאוחר להרשם אליו, הוא בחודש הבא בברצלונה!

ההכרזה הזו של GCP כוללת בתוכה גם הכרזה על השת"פ הבא של גוגל ושלנו ובקרוב נוכל להשתמש בשרתי ה bare metal החדשים על מנת לספק עליהם את שירות ה NC2 שלנו ולהשלים את "שלושת הגדולים". אני לא חושב שיצא לי לכתוב על NC2 בצורה מסודרת כאן עד היום אז שווה להזכיר, NC2 זו היכולת לפרוס את כלל שכבת התוכנה של Nutanix על גבי שרתים יעודיים בסביבת הענן הנבחרת על ידי הלקוח, AWS, Azure וכאמור בקרוב מאד GCP. ההטמעה נעשית בתוך החשבון של הלקוח, בתוך הפרוייקט ותלוי בבחירת הלקוח יכולה להעשות בתוך ה VPC/VNET של הלקוח. את הרישוי הנדרש ניתן לרכוש ישירות דרך ה App Store/Market Place או לחלופין דרך שותף הנוטקניס האהוב עליכם במודל Bring Your Own ומרבית הרשיונות הקיימים הם Portable כלומר ניתן לשמר השקעה ו"לקחת" רשיונות קיימים איתכם לענן.

NC2 מאפשר את העליה המהירה ביותר לענן הציבורי מכל פתרון אחר, אותם כלים, אותן יכולות, אותם נהלים והגדרות, רק בענן ובקרוב מאד בכל העננים, זו התשתית האמיתית ל Hybrid Multi Cloud כולל כמובן לנייד עומסי עבודה באופן מהיר בין הענן הפרטי והענן הציבורי, התממשקות לסביבות Object שונות לטובת Tiering או DR, ובמרבית המקרים, חסכון עלויות משמעותי בהשוואה בין NC2  ובין IaaS Native.

הסיבה לחסכון הכספי מול EC2  למשל או Compute Engines, היא הגמישות והדחיסות (Density). כשאנחנו צורכים שירותי מחשבו במודל IaaS אנחנו כפופים לגודל ה T Shirt שהספקית בחרה עבורנו והרבה פעמים נאלצים לשלם על זיכרון כדי לקבל מעבד מהיר, על מעבד מהיר כדי לקבל עוד נפח אחסון וכו'. בתשתיות NC2 אנחנו יכולים להגדיר מכונות וירטואליות בהתאם לצרוך האמיתי שלנו ועל ידי זה לבטל את מה שנקרא micro waste, לבטל את כל העודפים האלו שאנחנו משלמים עליהם סתם. איפה שעדיין יש עודפים כאלו, במצב Native אין מה לעשות איתם, ובמודל של NC2 זה "ספייר" שנשאר שלנו במערכת ואפשר באופן דינאמי להקצות אותו למערכות אחרות.

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

כמו שאני רואה את זה, זה פתרון הבסיס לתפישה של Cloud Smart. ראינו כל מיני פתרונות אחרים שמנסים לעשות את זה אבל הם חלקיים, כי הם מטפלים רק ה Data, או רק ב Compute, או שצריך לרכוש רישוי נפרד עבורם או כלי ניהול אחר או שהם לא משמרים את ה Policy הארגוני, כל מיני מגבלות שלא קיימות ה NC2.

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

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

פסח מורכב

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

בברכת בשורות טובות,

שישובו כל החטופים והחטופות במהרה אמן וכל החיילים והחיילות בריאים ושלמים!

שלכם כרגיל,

ניר מליק

הלמה מתה?

זה היה פוסט שמאד אהבתי, בעיקר בגלל הכותרת המתחכמת שלו שהבטיחה למות ובמקום לדבר על בהמת משא דרום אמריקאית שיורקת, עסקה בכלי לשוני פופולרי לביצוע תחקירי RCA או Root Cause Analysis ובכן לא מזמן נתקלתי בציוץ הזה:

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

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

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

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

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

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

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

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

זה מתגלגל לי בראש מאז שראיתי את הציוץ הזה של ג'אסטין וורן:

והניסוח הזה שלו, Always Be Falling מסקרן אותי אבל אני לא מצליח לשים את האצבע על המקור של הניסוח הזה ועל הכוונה המלאה שלו. בתשובה לשאלה שלי, הוא מפנה לחומר קריאה, גם לזה של סידני דקר, ובשורה תחתונה מפנה לחפש חומר על Resilient Design ולכאן ננסה לחזור לדעתי בפוסט הבא כי כאן אני חושב נמצאת הפואנטה, כאן עוברים מהרוח לחומר וכאן יורדים מהפילוסופיה של תכנון שריד חדש אל הארכיטקטורה של MS SQL שמוגדר עם Always ON מעל שרתים של VMware שמוגדרים עם HA מעל מערכות אחסון יתירות עם רפליקציה והכל ארוז בפתרון סטייל Continuity שיודע לוודא עבורנו את הקונפיגורציה של כל ה Stack ארוז ביחד ומוגדר נכון.

מחכה לשמוע מה דעתכם,

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

ניר מליק

רעידת אדמה באיטליה – מחשבות על DRP

רעידת אדמה באיטליה – מחשבות על DRP

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

שלוש המלצות מסוג "אל תעשה" לגבי טיול בחבל ארץ יפה זה:

  1. מומלץ בחום לשכור את הרכב הכי קטן שאפשר, מרבית הכבישים הרריים, צרים ומפותלים אך חשובה מהנהיגה עצמה היא הגמישות, ברכב גדול תקשו על עצמכם סתם לעצור בצד הדרך לצלם משהו, "לגנוב" חניה לרגע בשולי הכפר או להשתחל לחניה מחוץ לחניונים המסודרים הנדירים. אני טעיתי בגדול בנושא זה ושכרתי רכב מסוג פיאט סקודו בן תשעה מקומות ישיבה, מנוע דיזל ותיבת הילוכים ידנית. אתגר מיותר למי שלא חייב את כל המושבים!
  2. למרות שקראתי מאות עמודים כהכנה לטיול, לא הבנתי את המשמעות של עומס בשיא עונת התיירות עד שהגעתי לעירה ראבלו לגלות שהעירה כולה סגורה. פעמיים. פעמיים נסענו במשך שעה וחצי לגלות שאין כניסה לעירה כלל יותר בגלל עומס תיירים. שיא העונה יכולה להיות תקופה מאתגרת לתייר גם בלונדון או בפריז אבל כזה דבר עוד לא ראיתי.
  3. טיילנו עם ילדים בני 4 עד 12. כולנו נהנינו אבל זה אזור פחות מתאים למשפחה בעלת ילדים קטנים. בילינו יום שלם בבריכה של הבית ששכרנו ויום שלם בפארק מים קטן ונחמד אבל באופן כללי האזור אינו משופע אטרקציות שמתאימות לילדים.

italy

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

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

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

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

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

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

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

להלן רשימה של שאלות לדוגמא שיש לספק עבורן מענה על מנת לייצר באופן נכון את רמות ה SLA בארגון:

  1. האם הארגון מסוגל לסבול השבתה חלקית של מערכות המידע? מה הנזק הכספי שיגרם לארגון מהשבתה שכזו?
  2. האם הארגון מסוגל לסבול השבתה מלאה של מערכות המידע? מה הנזק הכספי שיגרם לארגון מהשבתה שכזו?
  3. האם קיימת אפליקציה קריטית שבלעדיה רוב הפעילות העסקית בארגון אינה יכולה להתקיים? מה הנזק הכספי שיגרם לארגון מהשבתה שכזו?
  4. האם הארגון מסוגל לסבול השבתה חלקית של אפליקציה קריטית? מה הנזק הכספי שיגרם לארגון מהשבתה שכזו?
  5. מה משך ההשבתה המקסימלי שהארגון מסוגל לספוג מבלי להיפגע מבחינה עסקית? מה הנזק הכספי שיגרם לארגון בחריגה מפרק הזמן המוגדר?
  6. האם קיימת אפליקציה בארגון שבלעדיה יגרם נזק תדמיתי לארגון מצד הלקוחות? הספקים? בעלי המניות? הרגולטורים הרלוונטיים?

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

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

שלכם,

ניר מליק