ממשקי API בפנים לעומת מחוץ לארגון

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

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

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

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

התשובה תלויה בסוג החיבור - סטטי לעומת דינמי. בעולם הישן של פתרונות נקודתיים, למשל, המוקד היה לרוב רק שילוב סטטי, קבלת מידע ממערכת A למערכת B. המנגנונים המונוליטיים שהופעלו היו לרוב שבירים ומורכבים, והתמקדו רק במסלול A → B הנוכחי, כאילו דרכים עתידיות ל- C, D או E לעולם לא ייעזו.

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

ליתר דיוק, להלן הדרישות המינימליות לגישה פנימית למערכת:

  • אבטחה
  • מסלול ביקורת
  • נראות
  • ביצועי זמן פעולה (זמן הפעלה, חביון)
  • עלות (הימנעות מעלות, חיסכון בעלויות)

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

  • תובנות / ניתוחים
  • קלות שימוש
  • הרחבה
  • אפשרויות פריסה (למשל מכולות, עננים, סולם)
  • מונטיזציה
  • בקרה עדינה

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

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

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

[מעוניין בטיפים נוספים לניהול ממשקי API וניהול עסקים דיגיטליים? עיין בספר האלקטרוני החדש של Apigee, "הלך הרוח של מוצר API."]