במשך שנים, השתרשה לה תפיסה ברורה שתחום ה-IT מהווה מודול חשוב בניתוח מערכות, אחרי הכול, הרי כמעט בלתי אפשרי להתקין כמעט שום מערכת בארגון ובמיוחד בארגון גדול, ללא מעורבות של אנשי ה-IT.
התפיסה הזו גורסת כי בעת אפיון של דרישות למערכת מידע חדשה, ישנו צורך לאפיין יחד עם אנשי ה-IT את אופן התקנת המערכת החדשה ואת אופני הפריסה שלה כמו גם הגדרת מתודולוגיית גיבוי וכדו'. בבסיסה של גישה זו קיימת הנחת יסוד שאפיון הוא עניין מודולארי ואשר ניתן לאפיין את המודולים ה-"עסקיים" בנפרד מהמודולים ה-"טכנולוגיים". משום כך, לדידם של אלו המתנהלים לפי תפיסה זו, קיימים מצבים בהם לא נדרש אפיון של המודולים ה-"טכנולוגיים", למשל כאשר מדובר על אפיון של גרסה חדשה למערכת קיימת (Gap analysis) אשר עבדה בעבר ומשום כך, במקרה שמדובר על שדרוג של רכיבים "עסקיים" לא נחוץ, לכאורה, אפיון מחודש לרכיבים הטכנולוגיים.
מאמר זה בא להוכיח כי גישה זו שגויה מעיקרה וכי ניתוח מערכות לפי התפיסה העומדת בבסיסה, עשוי לייצר עלויות שאינן נחוצות לארגון וליצור תקורות משמעותיות בניהול וטיפול בתקלות בגרסתה החדשה של המערכת ואם לא די בכל זה, גישה זו עשויה לגרום לכך שאותן תועלות המתוארות באפיון לא תוכלנה לבוא לידי ביטוי "בשטח" כך שבעצם כל מטרתו של האפיון תסורס.
על מנת להוכיח זאת החלטתי לסקור כל מרכיב ומרכיב באפיון טיפוסי ולהסביר את ההיבטים הטכנולוגיים והעסקיים בכל אחד:
1. ממשק המשתמש – בעת ניתוח המערכות מהפן העסקי בלבד, מאפיין את הפן העסקי בלבד של מערכת כלשהי, יהיה מן הסתם צורך לאפיין את ממשק המשתמש, את הכפתורים הדרושים בו, את ההתנהגות המצופה ממנו כתגובה לפעולות משתמש שונות, תוכנם של רשימות שונות מהן יוכל המשתמש לבחור את הערכים הרצויים לו וכדומה. לכאורה, נדמה כי כל מי שאי פעם עבד עם Windows מסוגל לבצע אפיון כזה ולקבוע מה יעשה כל כפתור על בסיס היכרותו עם מערכת ההפעלה. אלא שלאמיתו של דבר, נדרשת מיומנות טכנית אשר חסרה בדרך כלל למאפיין "העסקי". למשל, כאשר מדובר על מערכת מבוססת דפדפן (המכונה במחוזותינו "Web-ית") דרישות רבות שנשמעות הגיוניות לחלוטין בעולם החלונאי יצריכו משאבים ניכרים על מנת לפתחם בעולם הדפדפנים. לצורך הדוגמא, נניח שקיימת ברשותינו מערכת מידע כלשהי המאפשרת אירכוב של מסמכים ושליפתם, המערכת שלנו מאפשרת סריקה של מסמכים כאשר לאחר הסריקה מעדכנים את פרטי המסמך שנסרק, בעת שליפה יהיה ניתן לשלוף אותו לפי כל אחד מהנתונים שהוזנו לגביו. מאפיין "עסקי" עשוי בתמימות לאפיין שדרוג למערכת זו אשר יכלול תוספת של התכונות הבאות:
– הצגת כל המסמכים שנסרקו בגרסה מוקטנת
– בעת התיוק לאחר הסריקה, תינתן אפשרות למשתמש להקיש חלק משם/ת.ז של הלקוח אליו יש לשייך את המסמך והמערכת תשלים את שארית הת.ז/שם
– הצגת המסמך שנסרק באמצעות תוכנה כלשהי הקיימת כבר כיום בתחנות העבודה
אפיון "עסקי" שכזה נשמע מצויין אלא שתוצאותיו, עשויות להחטיא את המטרה אך ורק בשל העדר הרקע הטכנולוגי הדרוש:
– הצגת מסמכים במערכת מבוססת דפדפן, בהנחה שמדובר במסמכי TIF (הפורמט המקובל לסריקת מסמכים), איננו עניין טריויאלי כלל. במקרה של העדר התייחסות מתאימה באפיון (למשל המרה on-the-fly של המסמך לפורמט JPG) עשויה לגרום לגורם המבצע להבין כי הוא נדרש להתמודד עם האתגר הטכנולוגי של הצגת מסמכי TIF בדפדפן ולשם כך הוא עשוי להשתמש ברכיב ActiveX כלשהו אשר מעצם היותו רכיב נוסף, יגרום למורכבות בתהליך פריסת המערכת בארגון ועשוי בהחלט לגרום לבעיות אבטחת מידע מהותיות מעצם היותו רכיב תוכנתי "אמיתי" (כלו' לא סקריפט המופעל בתוך ה-Sandbox של הדפדפן).
– אפשרות להקשת חלק משם הלקוח או תעודת הזהות שלו והשלמה אוטומטית על ידי המערכת עשויה בהחלט (תלוי במימוש ובארכיטקטורת התשתית הקיימת בארגון) לגרום לעומסים עצומים על מערכות המידע ובכך למעשה ליצור בעיות Performance קשות שיגרמו לאבדן אמון הלקוחות במערכת. אם נחשוב לרגע על ארגון המשרת סדר גודל של 5000 לקוחות כאשר לכל אחד קיימים תעודת זהות, שם פרטי ושם משפחה, בעת ניסיון של המשתמש להקיש כל אות תידרש פניה למערכת (על בסיס Web Service למשל) לצורך קבלת רשימת ההצעות להשלמה אוטומטית עד למצב שבו מוחזרת הצעה אחת בלבד. הרי שבמקרה כזה בסדר גודל של 200 עובדים המפעילים את המערכת וכל אחד מקיש במקביל (פחות או יותר) כ-5 תווים כבר תידרשנה מעל 1000 פניות במקביל לשירות לצורך קבלת הצעות! גם במידה ומדובר על שירות המבצע Caching אוטומטי על בסיס משיכת כלל הנתונים ממסד הנתונים אחת ללילה עדיין מדובר על כמות פניות עצומה אשר תצריך התמודדות מורכבת מבחינת שרת ה-IIS והאפליקציה.
– הגישה מתוך אתר או מערכת מבוססת דפדפן אל תוכנות המותקנות במחשב הלקוח מוגבלת מטעמי אבטחת מידע ברורים ומובנים, עם זאת, מנתחי מערכות "עסקיים" אינם מודעים לנושאים אלו ומשום כך עשויים לאפיין מערכת באופן כזה. הגורם אשר אמון על פיתוח המערכת ינסה לעמוד בדרישות האפיון, ואם אכן יצליח בכך (על ידי שימוש באובייקטי ActiveX למיניהם, Custom Protocols associations, או בעזרת תוכנת Agent המופעלת במחשב הלקוח) הוא עשוי ליצור חורי אבטחה משמעותיים ביותר.
2. אבטחת מידע – מאפיינים "עסקיים" מניחים בדרך כלל (בטעות) כי תחום אבטחת המידע הינו תחום טכנולוגי בלבד וכמו בכדי להוסיף חטא על פשע במקרים של אפיון השלמת פערים (Gap analysis) כמו במקרה של שדרוג מערכת קיימת פעמים רבות לא נראה להם שישנו צורך לעדכן את ההתייחסות לנושאי אבטחת המידע (כל מה ששונה במערכת הוא חלון/כפתור/עיצוב חדש) וכתוצאה מכך אבטחת המידע של המערכת נפגעת באופן משמעותי. הבעיה עם אבטחת המידע היא שהיא נקבעת לפי חוזק החוליה החלשה ביותר בארכיטקטורה הארגונית, קרי, אם מערכת המידע שלך נבנתה על ידי מומחי אבטחת המידע הגדולים ביותר אבל קיימת לך בארגון גם מערכת קטנה וחסרת חשיבות שנבנתה מזמן על ידי מתכנת שכבר עזב – קח בחשבון שייתכן והיא החוליה החלשה ביותר. הבעיה בהנחת היסוד הזו משמעותית שכן כתוצאה מהשימוש בה עלול הארגון להשקיע משאבים רבים באבטחת נתונים שאינם כה מסווגים מחד ולוותר על הטיפול בחשיפתם של נתונים מסווגים הרבה יותר מאידך. הדרך הנכונה להתייחס לאבטחת המידע הלוגית (או הטכנולוגית) בדיוק כפי שמתייחסים לאבטחת המידע הפיזית, אם באבטחה הפיזית, אנשי העסקים קובעים מדיניות הרשאות, קרי, לאיזה חדר מותר להיכנס ולמי והשומרים של חברת השמירה אחראים ליישם את המדיניות שנקבעה על ידי החלטה היכן יוצבו שומרים וכמה, איזו הכשרה צריכה להיות להם, האם תהיה להם מכונת שיקוף וכו'. כך גם באבטחה הלוגית – מאפיין "עסקי" צריך לכל הפחות להגדיר מדיניות ברורה וחד משמעית (כמו בכל נושא באפיון) אילו נתונים יסווגו באיזה סיווג, מהי רמת הרגישות של כל נתון, מי מורשה לראות איזה סיווג של נתונים וכו' כאשר המאפיין "הטכנולוגי" נדרש לאפיין את אמצעי הבקרה והשליטה אשר יסייעו לו לאכוף את המדיניות שנקבעה. בפועל, הנושא מורכב יותר, שכן למאפיין "העסקי" חסרה ההכשרה הטכנולוגית על מנת לדעת אילו דרישות הן הגיוניות בהתחשב בטופולוגיה הטכנולוגית הקיימת אצלו ואילו דרישות תחייבנה היערכות טכנולוגית מקיפה ומשום כך, ייתכן בהחלט כי הדרישות אותן הוא יציג היו יכולות להיות גם מוגדרות באופן מותאם יותר לארכיטקטורה הקיימת באותו ארגון ובכך לחסוך עלויות IT עצומות. מאידך גיסא, גם למאפיין "הטכנולוגי" חסרה ההכשרה העסקית המתאימה ומשום כך הוא עלול כתוצאה ממוטיבציה ולויאליות להגדיר דרישות שמבחינה טכנולוגית הן יקרות מאד וזאת על מנת לשמור על אבטחת המידע של הארגון על אף שהדבר אינו בהכרח עולה בקנה אחד עם מטרותיו העסקיות של הארגון.
3. ממשקים – מאפיינים "עסקיים" בדרך כלל מאפיינים ממשקים באחד מ-2 האופנים הבאים:
(א) טבלה המכילה את רשימת השדות המועברים בממשק
(ב) תיאור ברמת ממשק משתמש ("בחלון זה בשדה XXX יישתל ערכו של השדה YYY ממערכת ZZZZ")
הבעיות עם אפיון ממשקים כזה הן:
(א) הוא לא מכתיב את אופן היישום הטכנולוגי של הממשק. הבעיה בכך היא שהוא לא מאפשר לארגון להשיג תשתית ממשקים מתועדת ובמבנה אחיד, היתרון בבניית תשתית ממשקים מתועדת ובמבנה אחיד הוא בקיצור התהליכים המשמעותי המושג בבניית הממשק הבא. בארכיטקטורות SOA, למשל התפישה היא שהיות והממשקים הם בדרך כלל רבים וקטנים יחסית (מכילים בדרך כלל אפשרויות לביצוע פעולות אטומיות או כמעט אטומיות) פיתוחים הולכים ונעשים זריזים וקלים (Agile) יותר ויותר. בכך טמון חיסכון כלכלי עצום לארגון.
(ב) במקרים רבים, הוא מאפשר כתיבת ממשק ישירות בין הגורמים המעורבים. כתוצאה מכך, הממשק עשוי להיות ספציפי לקישור אותם גורמים בלבד ולא יאפשר או לא יתמוך באופן מיטבי בקישור מערכות אחרות, כתוצאה מכך יהיה הכרח לפתח ממשקים נוספים לאותה מערכת למרות שהפונקציונליות שלהם תהיה לעיתים דומה מאד. בנוסף, לא יהיה ניתן לנהל את הממשקים בין המערכות שכן כל ממשק עובר דרך שרתים אחרים ומתבצע באופנים אחרים ולא מן הנמנע שלא הוגדרו אמצעי שליטה ובקרה לממשק עצמו. אפשרות אלטרנטיבית טובה הרבה יותר תהיה יצירה של "רכזות" מלאכותיות אשר אליהן ינוקזו פניות כל הממשקים.
4. שרידות – כאשר מדברים עם אדם בעל אוריינטציה "טכנולוגית" על נושא השרידות הוא מיד מגיב בפירוט מדוייק של טכנולוגיות RAID ו-DRP המיושמות אצלו, אבל השאלה היא האם כך אפיון אמור להיראות? התשובה היא שלא. כאשר שואלים מאפיין "עסקי" לגבי שרידות הוא ישיב שמדובר בנושא טכנולוגי "נטו" וגם זו טעות מרה. המאפיין העסקי נדרש לאפיין את הדרישות למערכת (או השדרוג) ואת אופן יישומן, חלק בלתי נפרד מהן הוא ההחלטה מהי רמת השרידות הנדרשת למערכת זו, קרי, תוך כמה זמן, מרגע אסון, צריכה מערכת זו להיות זמינה וכמה מידע במושגי זמן ניתן לאבד במקרה כזה. מאפיין עסקי טיפוסי לא יחשוב יותר מדי ויענה: "המערכת צריכה להיות זמינה מיד לאחר האסון ולא לאבד כלום". העניין הוא שמדובר במשהו על גבול הבלתי אפשרי ובכלל, יקר מאד.
מטבע הדברים, ככל שמאפשרים משך השבתה ארוך יותר ו/או אובדן נתונים רב יותר, המחיר יורד באופן דראסטי. בכל זאת – חשוב לזכור מדובר על אסון קולוסאלי לארגון, לא על מקרה של שחזור קובץ בגלל מחיקה אקראית.
5. ביצועים – מאפיינים עסקיים יטענו בדרך כלל כי תחום זה שייך במובהק לתחום הטכנולוגי, שכן כביכול מדובר על סוגי שרתים, קווי תקשורת, נתבים וכו'. לאמיתו של דבר, אין הדבר כך כלל. הביצועים הנדרשים ממערכת הם עניין עסקי לכל דבר, כלומר, הארגון (או יותר נכון, הלקוח) צריך להחליט אילו ביצועים הוא מעוניין לקבל מהמערכת. כל תפקידו של המאפיין ה-"טכנולוגי" הוא לדאוג לאפיין את רכיבי המערכת ואופן מימושה כך שהארגון (או יותר נכון הלקוח) יוכל לקבל את רמת הביצועים הנדרשת. הבעיה היא בכך שהמאפיין ה"עסקי" עשוי בהחלט להציב דרישה לא מציאותית שלא לצורך ובשל כך, עלות המערכת תגדל ללא כל הצדקה, לחילופין, עלול המאפיין ה"עסקי" להציב דרישה נמוכה מדי בעוד שאילו היה לו רקע טכנולוגי מספק הוא היה מסוגל להגדיר את הדרישה המתאימה באופן אופטימלי הן לצורך העיסקי והן ליכולות הטכנולוגיות הקיימות בארגון.
ניתן לומר את אותם הדברים גם בתחומי הטיפול בתקלות שוטפות, אפיון תהליכים וטרנזקציות, אפיון מודל הנתונים ועוד. הפתרון בו משתמשים ארגונים המעוניינים בכל זאת ליישם מחלקות נפרדות לאפיון "טכנולוגי" ואפיון "עסקי" הוא בדרך כלל פגישות תיאום תקופתיות בהן נפגשים מאפיינים מ-2 המחלקות ודנים באפיונים שכתבו ומתקנים לפי הצורך. הבעייתיות בפתרון כזה היא אחת מ-2: או שהאפיון נמשך זמן רב ללא צורך כתוצאה מפגישות תקופתיות אלו או שבנושאים שונים לא נראה למאפיינים השונים כי ישנו צורך ממשי בהתייעצות וכך בסופו של דבר, למרות הניסיונות ליצור אינטגרציה בין שני סוגי המאפיינים, מושג בסופו של דבר תוצר ברמה נמוכה.
לסיכום, ניתן לומר שמילת המפתח בנושא ניתוח המערכות היא אינטגרציה: אינטגרציה בין האספקט הטכנולוגי לעסקי, בין הדרישות הפונקציונליות (FR) לדרישות שאינן פונקציונליות (NFR), בין הלקוח ומשתמש הקצה למתכנת או צוות המתכנתים. הוכחתי, כך אני מקווה, שאכן, רק גורם (או גוף) מאפיין בעל אוריינטציה אינטגרטיבית אשר לו (או במקרה של יחידה – להם) רקע מספק הן בעולם הידע העסקי והן בעולם הידע הטכנולוגי היה מצליח להשיג את הפשרה הטובה ביותר לטובת הארגון. כלומר לאפיין דרישות במישור העסקי כך שבמידה ודרישה מסוימת עשויה להוות בעיה ליישום במישור הטכנולוגי או שבעקבות דרישה כזו או אחרת מתבקשת התייחסות טכנולוגית, לתת מענה הולם, אינטגרטיבי והוליסטי לנושא האפיון.