לקוח מתקשר ומעדכן כתובת. נציג השירות מעדכן אותה במערכת שלפניו. שבוע אחר כך יוצא משלוח לכתובת הישנה, כי מערכת ההפצה מעולם לא שמעה על השינוי.
אף אחד לא טעה. הנציג עשה בדיוק את מה שהתבקש. פשוט היו שתי תשובות לשאלה "איפה הלקוח גר", ורק אחת מהן עודכנה.
זו לא תקלה נקודתית. זה מה שקורה כשארגון מפעיל יותר ממערכת אחת בלי להחליט מי מהן קובעת.
איך נוצרות שתי גרסאות של אותה מציאות
כמעט אף ארגון לא בחר לפצל את נתוני הלקוחות שלו. זה קרה מעצמו, בשלבים.
מערכת המכירות נכנסה ראשונה. אחר כך נוסף כלי לניהול השירות, כי המכירות לא ידעו לטפל בפניות. בהמשך הצטרפה מערכת הפצה, ובצד רץ גיליון של מחלקת הגבייה. כל אחד מהם נבחר בזמנו בהחלטה נכונה ולצורך אמיתי.
אבל בכל אחת מהמערכות האלה נוצר כרטיס לקוח. ומהרגע שיש שני כרטיסים, יש שתי אמיתות.
הסימנים מוכרים. אותו לקוח מופיע פעמיים עם איות שונה. הסטטוס במערכת אחת "סגור" ובשנייה "בטיפול". מישהו שולח דוח ומישהו אחר שולח דוח סותר, ושניהם צודקים ביחס למקור שממנו שאבו.
ואז מגיע השלב שבו הארגון מפסיק לסמוך על המספרים שלו. מנהל מבקש נתון, מקבל אותו, ובודק אותו ידנית לפני שהוא מציג אותו הלאה. הבדיקה הידנית הזו היא העלות האמיתית, והיא לא מופיעה בשום דוח.
ייצוא קובץ הוא לא אינטגרציה
הפתרון הנפוץ הראשון הוא ייצוא. מוציאים קובץ ממערכת אחת, טוענים אותו לשנייה, ומשם מסתדרים. זה עובד, וזה גם מה שגורם לרוב הארגונים לחשוב שהם פתרו את הבעיה.
הם לא. ייצוא הוא צילום מצב, ואינטגרציה היא חיבור חי. ההבדל מתגלה בשלוש נקודות:
- בזמן. קובץ מייצג את הרגע שבו הוא נוצר. מהשנייה שאחריו הוא מתיישן, וכל החלטה שמתבססת עליו מתבססת על עבר.
- בכיוון. ייצוא זורם לכיוון אחד. עדכון שנעשה בצד המקבל לא חוזר לעולם למקור, כך שהפער בין השניים גדל דווקא ככל שמשתמשים במערכת יותר.
- בשגיאות. קובץ שנטען חלקית לא מודיע לאיש. שלוש שורות נפלו, אלף עברו, ואף אחד לא יודע אילו שלוש.
חיבור אמיתי בין מערכות עובד אחרת. הוא מגיב לאירוע ברגע שהוא קורה, יודע להחזיר תשובה, ויודע לצעוק כשמשהו נכשל.
שלוש שאלות שמחליטות אם החיבור יחזיק
לפני שכותבים שורת קוד אחת, יש שלוש החלטות שקובעות אם האינטגרציה תחזיק שנה או תיפול בחודש הראשון.
מי מקור האמת לכל שדה. לא לכל הרשומה, לכל שדה בנפרד. ייתכן מאוד שהכתובת נקבעת במערכת ההפצה, אמצעי התשלום במערכת הגבייה, וסטטוס הפנייה במערכת השירות. מה שאסור הוא ששני צדדים יחשבו ששניהם קובעים את אותו שדה, כי אז כל עדכון דורס את קודמו לסירוגין והמערכת נראית כאילו היא משתגעת.
מה קורה כשהצד השני לא עונה. מערכת נופלת, שרת מתחזק, רשת מתנתקת. השאלה היא לא אם זה יקרה אלא מה קורה אז. חיבור שנבנה נכון שומר את האירוע בתור, מנסה שוב, ומדווח אם לא הצליח. חיבור שנבנה מהר פשוט מאבד את העדכון בשקט.
איך מזהים שזו אותה ישות. שתי מערכות שמחזיקות "ישראל כהן" לא מחזיקות בהכרח את אותו אדם. צריך מפתח מזהה יציב שעובר בין המערכות, ולא התאמה לפי שם. זה הפרט הטכני הכי משעמם ברשימה, והוא זה שמפיל הכי הרבה פרויקטים.
API ו-Webhook: מי שואל את מי
שתי המילים האלה חוזרות בכל שיחה על חיבור מערכות, וההבדל ביניהן פשוט מכפי שהוא נשמע.
API הוא ממשק שמאפשר למערכת אחת לבקש משהו מהשנייה. אתם שואלים, היא עונה. אם רוצים לדעת שמשהו השתנה, צריך לשאול שוב ושוב.
Webhook הופך את הכיוון. במקום שתשאלו, המערכת מודיעה לכם ברגע שקרה משהו. אתם לא בודקים אם הלקוח עדכן כתובת, אתם מקבלים הודעה שהוא עדכן. התקן שמתאר ממשקים כאלה, מפרט OpenAPI, מגדיר את שני הדפוסים זה לצד זה, ולכן ספק שמפרסם מסמך תקני חוסך לכם חצי מעבודת המיפוי.
ברוב הארגונים הפתרון הנכון הוא שילוב: Webhook לאירועים שדורשים תגובה מיידית, וסנכרון תקופתי מלא שרץ ברקע ותופס את מה שנפל בין הכיסאות. השכבה השנייה היא זו שאנשים מוותרים עליה, והיא זו שמונעת סחיפה שקטה של הנתונים לאורך חודשים.
כשאנחנו בונים אינטגרציות ו-API, אנחנו מתחילים ממיפוי של השדות ושל מקורות האמת ורק אחר כך ניגשים לקוד. המיפוי הזה הוא ברוב המקרים גם המסמך הראשון שמראה לארגון כמה כפילויות באמת יש אצלו.
מה עושים כשלמערכת הישנה אין ממשק בכלל
זה המצב הנפוץ יותר משנדמה. המערכת שמחזיקה את הנתונים הכי חשובים היא לרוב גם הוותיקה ביותר, ולעיתים קרובות אין לה API כלל.
זה לא סוף הדרך. אפשר לגשת למסד הנתונים ישירות בקריאה בלבד, לבנות שכבת ביניים שחושפת ממשק מודרני מעל המערכת הקיימת, או להוציא את הנתון בתהליך מתוזמן ולהזרים אותו הלאה. המערכת הישנה ממשיכה לעבוד בדיוק כמו קודם, ומעליה נבנית שכבה שמדברת עם השאר.
זו הנקודה שבה אנחנו לא ממהרים להחליף. עסק שמחליף מערכת ליבה כדי לפתור בעיית תקשורת שילם מחיר גדול בהרבה מהבעיה. לרוב עדיף לבנות מערכות מותאמות אישית סביב מה שכבר קיים, ורק אם המערכת עצמה כבר מגבילה את העסק לגשת לשדרוג מאקסס בשלב נפרד ומתוכנן.
שאלות נפוצות
כמה מערכות זה יותר מדי?
אין מספר. ארגון עם שבע מערכות מחוברות היטב מתפקד טוב יותר מארגון עם שתיים שלא מדברות. השאלה אינה כמה מערכות יש לכם אלא כמה פעמים אותו נתון מוקלד ידנית ביום עבודה רגיל.
האם אינטגרציה מחליפה את המערכות הקיימות?
לא. אינטגרציה נבנית מעל מה שכבר עובד ומשאירה כל מערכת בתפקידה. זו בדיוק הסיבה שהיא לרוב המהלך הזול והמהיר יותר משדרוג, ובמקרים רבים היא דוחה את הצורך בו בשנים.
מה קורה כשספק חיצוני משנה את הממשק שלו?
זה קורה, ולכן חיבור נבנה עם שכבת תרגום משלו במקום להיצמד ישירות למבנה של הצד השני. כשהספק משנה משהו, מתקנים נקודה אחת ולא את כל המערכת. גם ניטור שמתריע על כשל הוא חלק מהבנייה ולא תוספת.
איך יודעים שהחיבור באמת עובד?
לפי כמות ההקלדות הכפולות שנעלמו, ולפי כמה פעמים מישהו עדיין בודק נתון ידנית לפני שהוא מציג אותו. אם אחרי החיבור עדיין מצליבים מספרים בין שתי מערכות, החיבור פתר את התחבורה ולא את מקור האמת.
הבעיה כמעט אף פעם אינה שיש הרבה מערכות. הבעיה היא שאף אחת מהן לא הוכרזה כמי שקובעת, ולכן כולן קובעות. ברגע שיש החלטה מפורשת מי מקור האמת לכל שדה, מה קורה כשצד לא עונה ואיך מזהים שמדובר באותה ישות, החיבור עצמו הופך לחלק הפשוט בסיפור.
השאלה כבר אינה האם המערכות שלכם מדברות. השאלה היא מי מהן אומרת את המילה האחרונה.
לפתרון ספציפי לעסק שלכם:
צרו קשר ע"י השארת פרטים לחזרה, חייגו אלינו או צרו קשר בווטסאפ
נשמח לעמוד לשרותכם!