APIs Inside vs. Out Enterprise

Границата между вътрешната и външната ИТ функционалност в предприятието е невярно разграничение. Никой не може да предвиди как ще се използват данни или къде ще тече информация. Дори и да знаете къде са очертани вътрешните / външните линии на вашата компания днес - тези линии почти сигурно ще бъдат движещи се цели в бъдеще.

Вземете Pitney Bowes, компания, с която съм работил в моята роля в екипа на Apigee в Google. Въпреки че голяма част от историята му от близо век се корени във физически решения за изпращане на пощенски услуги като пощенски метри, през годините компанията също разработи възможности за плащания и електронна търговия и придоби огромни количества данни за логистика, доставка и геолокация. Тъй като Pitney Bowes еволюира от аналогови услуги към днешния свят на свързаната търговия, тя извлича стойност от тези активи и компетенции в организацията - но признава, че активите и компетенциите могат да бъдат ценни и извън компанията, за разработчици и партньори, които биха могли да ги използват. за изграждане на нови приложения и услуги.

За да се възползва от тази възможност, Pitney Bowes предлага над 160 публични API чрез облака, отваряйки милиони потенциални нови приходи и помагайки на усилията на компанията за дигитална търговия да станат годишен бизнес плюс 1 милиард долара. Данните и функционалността, които някога са били само вътрешни, сега също са външни.

Тук има урок: мисленето на бизнес решения и стратегии по отношение на „вътрешни“ и „външни“ или по отношение на „интегриране на система А и система Б“ е остаряло. Въпросът не е как ще свържете вътрешните си системи и потребители - тази връзка може да бъде направена по много начини. По-скоро въпросът е какво можете да направите с връзката, след като е направена.

Отговорът зависи от вида на връзката - статична спрямо динамична. В стария свят на точковите решения, например, фокусът често беше просто статична интеграция, получаване на информация от система А в система Б. Използваните монолитни механизми често бяха крехки и сложни, фокусирани само върху текущата A → B траектория, сякаш бъдещите маршрути до C, D или E никога няма да бъдат рискувани.

Но това не е така. Както показва примерът на Pitney Bowes, днешните пътища за данни може да не изглеждат като утрешните. В дългосрочен план всички връзки трябва да бъдат динамични, готови за мащабиране нагоре или надолу според нуждите и готови да взаимодействат с всичко необходимо. За да останете конкурентоспособни, не можете просто да използвате едни и същи технологии и да продължавате да затягате и не можете да разчитате на разпадащи се рамки като „отвътре“ и „отвън“.

По-конкретно, тук са минималните изисквания за вътрешен достъп до система:

  • Сигурност
  • Одитна следа
  • видимост
  • Изпълнение по време на изпълнение (време, продължителност)
  • Разходи (избягване на разходите, икономия на разходи)

По традиция тук са спрени много предприятия. Но има допълнителни точки, които трябва да се вземат предвид в днешния бързо развиващ се свят:

  • Данни за търсене / анализи
  • Лесно използване
  • разтегаемост
  • Опции за внедряване (например контейнери, облаци, мащаб)
  • Осигуряването
  • Финозърнест контрол

Както показват новите изисквания, ако не изградите вашите системи с очакването, че те ще трябва да взаимодействат със системи, които все още не са измислени, рискувате да се заключите. Твърде много хора все още погрешно смятат, че предизвикателството е прехвърлянето на големи парчета данни чрез грубо обезпечена сигурност до дебели клиентски приложения.

Но за напред, приложенията и архитектурата ще трябва да бъдат невероятно подробни и мащабируеми. За да стигнат дотам, предприятията трябва да се развият от интегрален манталитет до по-модерни подходи, които правят системите достъпни подробно, надеждно и мащабируеми, като същевременно осигуряват видимост, прозрения, контрол и сигурност. Основата на повечето от тези атомни, пъргави архитектури ще бъдат продуцирани API - тоест API-та, които не се използват само за излагане на активи, но са проектирани и управлявани като продукти, които дават възможност на разработчиците, независимо дали са вътрешни или външни, да създават нови приложения, разширете обхвата на марката и отворете нови възможности за приходи.

Това разграничение е важно: API-ите днес се използват в много сценарии за интеграция, така че въпросът не е да има API-та - а трябва да имат разработени и управлявани API-и за консумация, повторна употреба и непрекъснато подобряване. Казано по друг начин, с интеграционно мислене API-тата могат да решават краткосрочни проблеми - но щом човек види, че вътрешното / външното разделяне се е сринало и че случаите на използване на интеграцията вече не са достатъчни, управлението на API става най-разумното решение.

[Интересувате се от повече съвети за управление на API и управление на дигитален бизнес? Вижте новата електронна книга на Apigee, „Намиране на продукти на API.“]