תקשורת בין מאגרי מידע דומה קצת לתקשורת בין אנשים.
כשמדובר על חברים טובים, הם ידעו להתגבר על הבעיות וליצור תקשורת טובה, הם יצטרכו מעט מאוד פורמליסטיקה כדי להעביר מידע בינהם, ולא רק בשיחה פנים אל פנים, אלא גם בצ׳אט או תכתובת מיילים(בינינו, מי עוד שולח היום מכתבים?)
חברים יבינו אחד את השני גם כשהקו מקוטע, והמילים נבלעות, וגם כשהשיחה מתקיימת במקום הומה אדם וצריך לדעת לסנן את המילים מתוך הרעש.
לעומת זאת, ככל שהפער בין המתקשרים גדל, כך גדלות הבעיות בתקשורת בינהם. אם אחד הצדדים הוא לקוח והשני ספק, יש בינהם כללי תקשורת שונים מאשר שיחה בין חברים, למילים כבר יש משמעות משפטית, אם הלקוח רוצה משהו, הוא יצטרך לשלם על זה, כנראה שהספק יכול להכתיב חלק מהאילוצים בתקשורת בין הצדדים.
כשמדובר על "שיחה" בין אדם פרטי לרשויות המדינה, אז הפער גדל בהרבה. יש פורמליות רבה, טפסים שצריך למלא, לא כל הסעיפים בטפסים ברורים, יש הנחיות מחייבות מצד הרשות, והאזרח חייב להתיישר לכל ההנחיות. זמני התגובה שמצופים מהפרט שונים מזמני התגובה שמותרים לרשות, וברוב הפעמים, האזרח הקטן הוא זה שצריך להוכיח ש"אין לו אחות…"
תקשורת בין מאגרי מידע מתאפיינת בצורה מאוד דומה – כאשר מדובר על שני מאגרים פרטיים, של אנשים שמכירים אחד את השני ומעוניינים לשתף פעולה למען תועלת משותפת – הם יצליחו ליצור תקשורת הדדית שתעבוד בלי אילוצים מיוחדים, בלי בעיות משפטיות, ולפעמים על-בסיס פתרונות פשוטים, אפילו ברמה של שליחת עדכונים בדוא"ל. אם העברת המידע מתבצעת בצורה אוטומטית – ברוב המקרים מדובר על שפה משותפת ששני הצדדים הסכימו עליה, ומוכנים לעשות את התיקונים המתבקשים בכל פעם שיש שינוי במבנה הנתונים.
כשעולים קומה, ואנחנו מנסים לקיים תקשורת בין מערכת מידע פרטית – נניח אתר אינטרנט שעוסק במכירת ציוד לארועים, לבין מערכת המלאי של הספקים הסיטונאיים – ככל הנראה נקבל מכל ספק מפרט טכני יבש, לפעמים קשה להבנה, של מבנה הנתונים והקבצים. אנחנו נצטרך לבנות את כל הצד שלנו בממשק בהתאמה מלאה לדרישות והאיפיונים של הספקים, ובסבירות גבוהה יתברר שלכל ספק יהיה מפרט שונה. גרוע מכך – כשיהיו שינויים – נצטרך לבצע המרות בצד שלנו, על חשבוננו, תוך עמידה במועדים שלא אנחנו נקבע.
ואם חשבתם שזה היה קשה, אז העברת מידע בין גופים פרטיים לבין מוסדות המדינה, זו הרפתקה מורכבת ומתישה שאין כמוה.
באחד הפרויקטים בהם השתתפתי לאחרונה, הייתי אחראי על אפיון הממשק בין הפרויקט לבין מאגרי מידע של משרד החינוך. המשימה היתה מורכבת משני חלקים – קבלת מידע ממשרד החינוך, והעברת מידע שנוצר במערכת שלנו, אל מאגר המידע המרכזי של משרד החינוך. כשקיבלתי לראשונה את מסמכי אפיון הממשק של משרד החינוך – הבנתי כמה פשוטים וקלים היו החיים בכל המערכות הקודמות איתן עבדתי.
לאחר שכל ההיבטים המשפטיים כבר סוכמו, בוצעה ביקורת אבטחת מידע והתקבלו האישורים הרלוונטיים מכל הדרגים שבדרך – התחלנו במשימה המורכבת של פענוח "מילון הנתונים".
השמות של השדות לא היו זהים בין הפלט והקלט, לא תמיד היתה הגדרה זהה לאותו שדה בשני הממשקים, כמובן שלא היתה לנו כל יכולת להשפיע על הממשק, ולא תמיד היתה אפשרות לקבל משוב מיידי האם המידע שהעברנו התקבל או לא.
אולי הדבר הגרוע ביותר היה שלא את כל המידע שיצרנו, יכולנו לקבל בממשק חוזר, ובעצם לא יכולנו לבצע בקרה שהתהליך שלנו שלם.
תקשרות בין מאגרי מידע אינה בנויה רק על רצונם הטוב של שני הצדדים.
יש היבטים משפטיים שעוסק בהם חוק מאגרי המידע והמטרה היא להגן על המידע שנאגר אודותינו ע"י גורמים שונים. כל מי שרוצה לקבל מידע ממוסד ממשלתי חייב לעמוד בדרישות הגנת המידע, וגם אז – יקבל גישה רק למידע שיוכח שהוא נדרש לצורך קיום הוראות חוק, או הותר לשימוש ע"י חוק אחר (למשל חוק חופש המידע).
יש היבטים טכניים שמחייבים תאום מלא בין שני הצדדים שמעבירים את המידע – תארו לעצמכם שאתם מעבירים למישהו רשימה של אנשי קשר ובה השדות "שם משפחה", "שם פרטי", "כתובת", "מספר טלפון" ו-"תאריך לידה", והצד שמקבל חושב שסדר השדות הוא : "שם פרטי", "שם משפחה", "כתובת", "מספר טלפון" ואילו "תאריך לידה" מופיע במבנה אמריקאי (MM/DD/YY). עם כל הרצון הטוב, ואיכות קווי התקשורת – המידע ביעד יהיה משובש. גם בשיטות "מודרניות" של העברת מידע, שבהן תיאור המידע מופיע במידע עצמו (XML למשל), יש צורך לתאם בין שני הצדדים כדי למנוע אי-הבנה לגבי תוכן שדה ומשמעותו.
בנוסף על אלה – ממשק שכבר עובד בין מאגרי מידע, אינו "שגר ושכח" – זהו תהליך שצריך להיות מבוקר היטב, וככל שיש בו יותר "תחנות" בדרך – כך גדלות נקודות הכשל והצורך לבצע בקרה בכל מקום שתיתכן בו תקלה.
ועוד נקודה חשובה – העברת מידע מתבצעת ברקע, "מאחורי הקלעים", בד"כ פעולה זו אינה זוכה להערכה הראויה. העברות מידע נחשפות בד"כ להנהלה הבכירה רק במקרים שבהם יש בעיות – כל עוד המשכורת נכנסת בזמן לבנק – מנהל הבנק כלל לא מודע להעברת המידע. ביום שבו המשכורת תכנס ללא הספרה הראשונה – אני מניח שמנהל הבנק יחסיר פעימת לב אחת או שתיים.
בפרק הראשון, וגם בפרק השני, נגעתי בנושא מערכות שמדברות (או לא מדברות) בינהן. בפרק הזה ניסיתי להראות שהדברים מורכבים, ומחייבים עיסוק מקצועי ובקרה שוטפת.
בפועל – מערכות רבות מאוד, כנראה הרבה יותר ממה שאנחנו מסוגלים לדמיין, מעבירות מידע בכל רגע ורגע – בנקים, חברות אשראי, מידע פיננסי, בורסה, הוראות חיוב בכרטיסי אשראי, מבצעים בקופה של מועדוני לקוחות, תשלומי ביטוח לאומי, ביקורת הגבולות ורישמות מבוקשים וזו רק תחילתה של הרשימה…
אנחנו מתקרבים לסופה של הסדרה, כרגע אני חושב על שני פרקים נוספים, ופרק סיכום.
אם נהנתם לקרוא פרק זה, אנא הרשמו לעדכונים בדוא"ל כדי לקבל את הפרקים הבאים ופוסטים נוספים מיד עם פרסומם.
וכרגיל – תגובות, ביקורות, הערות, הארות, בקשות ולייקים יתקבלו בברכה.
