להלו מקרים בהם רצוי לשקול את סביבת ה- SBC כך תיתן פתרון חלקי לסביבת המשתמש כלומר חלק מהאפליקציות יעבדו בתצורה של SBC וחלק מהאפליקציות יעבדו לוקלית (במידה והאפליקציה המדוברת הנה האפליקציה היחידה או החשובה ביותר ניתן לעבור לסביבת SBC מלאה) :
גישה לאינטרנט (הרצה של דפדפן) מתוך סביבת הארגון המאובטחת באמצעות טכנולוגיית SBC. מקובל בארגונים שאינם המאובטחים ביותר אך בכל זאת מחזיקים רשת שאינה פתוחה לאינטרנט (דוגמה - בנקים).
במקרה יש אפליקציה שאינה חלק מה- image שקיים בארגון, ולא רוצים לבנות image חדש, אזי נגשים לאפליקציה זו באמצעות טכנולוגיית SBC.
במקרה וישנה אפליקציה שהיא מסובכת להתקנה, ישנם בה הרבה שינויים, או צריכה מחשב חזק או מתנגשת עם אפליקציות אחרות, אזי הגישה לאפליקציה זו באמצעות SBC. דוגמה פופולארית הינה SAP – לקוחות רבים מרצים את ה- client של SAP בצורה כזו (כ- 40% ויותר מהלקוחות הגדולים בישראל). מקרה דומה אחר בו ישנה אפליקציה מסובכת להתקנה אשר מספר המשתמשים בה מועט.
כנ"ל לגבי אפליקציה שבה לא משתמשים הרבה והתמחור הוא לפי concurrent user - זה מאפשר לחסוך רישיונות והתקנה.
במקרה וישנה אפליקציה שצריכה תעבורת תקשורת מאוד חזקה לשרת, תקשורת שאינה קיימת או קיבולת כזו שמפריעה למשתמשים אחרים – SBC מהווה פתרון טוב.
במקרה וישנה אפליקציה שאינה רצה בסביבת Windows אלא לדוגמה רצה בסביבת Unix ופתרון ה- SBC מהווה כאמולציה. ולהיפך – אם רוצים מתוך סביבה שאינה Windows להריצה אפליקציית Windows.
קונסולידציה של אפליקציה (או של סביבת מחשוב שלמה). מדובר על מצב בו ארגון מבוזר העביר אפליקציה ספציפת (או את כל האפליקציות כלומר את כל סביבת המחשוב) מהסניפים. תמיכה של אפליקציה שמבוזרת לסניפים הנה קשה ביותר (עדכוני תוכנה לתחנות העבודה ולשרתים, גיבוי, טיפול בתקלות וכד'). ישנם מקרים בהם מתבצעת קונסולידציה של האפליקציה או סביבת המחשוב כולה למרכז באמצעות טכנולוגיה של SBC.
לגבי אפליקציות סטנדרטיות (דוגמה OFFICE ), אשר מופצות בצורה קלה יחסית לא ברור אם ישנו חסכון כלכלי בשימוש ב- SBC.
גישה לאינטרנט (הרצה של דפדפן) מתוך סביבת הארגון המאובטחת באמצעות טכנולוגיית SBC. מקובל בארגונים שאינם המאובטחים ביותר אך בכל זאת מחזיקים רשת שאינה פתוחה לאינטרנט (דוגמה - בנקים).
במקרה יש אפליקציה שאינה חלק מה- image שקיים בארגון, ולא רוצים לבנות image חדש, אזי נגשים לאפליקציה זו באמצעות טכנולוגיית SBC.
במקרה וישנה אפליקציה שהיא מסובכת להתקנה, ישנם בה הרבה שינויים, או צריכה מחשב חזק או מתנגשת עם אפליקציות אחרות, אזי הגישה לאפליקציה זו באמצעות SBC. דוגמה פופולארית הינה SAP – לקוחות רבים מרצים את ה- client של SAP בצורה כזו (כ- 40% ויותר מהלקוחות הגדולים בישראל). מקרה דומה אחר בו ישנה אפליקציה מסובכת להתקנה אשר מספר המשתמשים בה מועט.
כנ"ל לגבי אפליקציה שבה לא משתמשים הרבה והתמחור הוא לפי concurrent user - זה מאפשר לחסוך רישיונות והתקנה.
במקרה וישנה אפליקציה שצריכה תעבורת תקשורת מאוד חזקה לשרת, תקשורת שאינה קיימת או קיבולת כזו שמפריעה למשתמשים אחרים – SBC מהווה פתרון טוב.
במקרה וישנה אפליקציה שאינה רצה בסביבת Windows אלא לדוגמה רצה בסביבת Unix ופתרון ה- SBC מהווה כאמולציה. ולהיפך – אם רוצים מתוך סביבה שאינה Windows להריצה אפליקציית Windows.
קונסולידציה של אפליקציה (או של סביבת מחשוב שלמה). מדובר על מצב בו ארגון מבוזר העביר אפליקציה ספציפת (או את כל האפליקציות כלומר את כל סביבת המחשוב) מהסניפים. תמיכה של אפליקציה שמבוזרת לסניפים הנה קשה ביותר (עדכוני תוכנה לתחנות העבודה ולשרתים, גיבוי, טיפול בתקלות וכד'). ישנם מקרים בהם מתבצעת קונסולידציה של האפליקציה או סביבת המחשוב כולה למרכז באמצעות טכנולוגיה של SBC.
לגבי אפליקציות סטנדרטיות (דוגמה OFFICE ), אשר מופצות בצורה קלה יחסית לא ברור אם ישנו חסכון כלכלי בשימוש ב- SBC.
אין תגובות:
הוסף רשומת תגובה