API viduje ir už įmonės ribų

Riba tarp vidinio ir išorinio IT funkcionalumo įmonėje yra klaidingas skirtumas. Niekas negali nuspėti, kaip bus naudojami duomenys arba kur bus srautas. Net jei žinote, kur šiandien nubrėžtos jūsų įmonės vidinės / išorinės linijos - šios linijos ateityje tikrai bus judantys taikiniai.

Paimkite Pitney Bowes - kompaniją, su kuria dirbau vykdydama „Apigee“ komandą „Google“. Nors didžioji jos beveik šimtmečio istorijos istorija buvo susijusi su fizinio pašto sprendimais, tokiais kaip pašto skaitikliai, bendrovė bėgant metams taip pat plėtojo mokėjimų ir elektroninės prekybos galimybes ir įgijo daugybę logistikos, gabenimo ir geografinės padėties duomenų. Pitney Bowes'ui išplėtus iš analogiškų paslaugų į šiandieninį susietos komercijos pasaulį, iš šio turto ir kompetencijų organizacijoje atsirado vertė, tačiau ji pripažino, kad turtas ir kompetencijos gali būti vertingi ir už įmonės ribų, kūrėjams ir partneriams, kurie galėtų jais naudotis. kurti naujas programas ir paslaugas.

Pasinaudodamas šia proga, Pitney Bowes per debesį siūlo daugiau nei 160 viešųjų API, atverdamas milijonus naujų pajamų ir padėdamas bendrovės skaitmeninės komercijos pastangoms tapti 1 milijardo dolerių vertės metiniu verslu. Duomenys ir funkcijos, kurie kadaise buvo tik vidiniai, dabar yra ir išoriniai.

Čia yra pamoka: verslo sprendimų ir strategijų mąstymas „vidiniu“ ir „išoriniu“ arba „integruoti A ir B sistemą“ yra pasenęs. Klausimas nėra tas, kaip ketinate sujungti savo vidines sistemas ir vartotojus - tą ryšį galima sukurti keliais būdais. Svarbiausia yra tai, ką jūs galite padaryti naudodamiesi ryšiu.

Atsakymas priklauso nuo ryšio tipo - statinis ir dinaminis. Pvz., Senajame taškų sprendimų pasaulyje dėmesys dažniausiai būdavo tik statinis integravimas, informacijos gavimas iš sistemos A į sistemą B. Naudojami monolitiniai mechanizmai dažnai buvo trapūs ir sudėtingi, orientuoti tik į dabartinę A → B trajektoriją, tarsi būsimi maršrutai į C, D ar E niekada nebus išdrįsti.

Bet, žinoma, taip nėra. Kaip rodo Pitney Bowes pavyzdys, šiandienos duomenų perdavimo keliai gali atrodyti ne tokie, kaip rytoj. Ilgainiui visos jungtys turi būti dinamiškos, paruoštos padidinti ar sumažinti pagal poreikį ir būti sąsajos su visomis reikalingomis priemonėmis. Norėdami išlikti konkurencingi, negalite tiesiog naudotis tomis pačiomis technologijomis ir nuolat varžytis, taip pat negalite pasikliauti trupinančiomis sistemomis, tokiomis kaip „vidus“ ir „išorė“.

Tiksliau, čia yra būtiniausi reikalavimai vidinei prieigai prie sistemos:

  • Saugumas
  • Audito seka
  • Matomumas
  • Runtime performance (uptime, latency)
  • Sąnaudos (išlaidų vengimas, išlaidų taupymas)

Tradiciškai daugelis verslo čia sustojo. Tačiau yra ir papildomų aspektų, į kuriuos reikia atsižvelgti šiuolaikiniame sparčiai besikeičiančiame pasaulyje:

  • Įžvalgos / analizė
  • Lengvas naudojimas
  • Išplečiamumas
  • Diegimo parinktys (pvz., Konteineriai, debesys, mastelis)
  • Pinigų gavimas
  • Smulkiagrūdis valdymas

Kaip rodo nauji reikalavimai, jei nekuriate savo sistemų tikėdamiesi, kad jos turės sąveikauti su dar neišrastomis sistemomis, rizikuojate užsiblokuoti. Per daug žmonių vis dar klaidingai galvoja, kad iššūkis yra didelių duomenų dalių perkėlimas naudojant grubios saugos apsaugą prie storų klientų programų.

Tačiau ateityje programos ir architektūra turės būti neįtikėtinai detalios ir keičiamos. Norėdami ten patekti, verslas turi pereiti nuo integracijos mentaliteto prie modernesnio požiūrio, pagal kurį sistemos tampa prieinamos detaliai, patikimai ir plačiai, kartu užtikrinant matomumą, įžvalgas, valdymą ir saugumą. Daugelio šių atominių, judriųjų architektūrų pagrindas bus gaminamos API - tai yra API, kurios ne tik naudojamos turtams atskleisti, bet yra suprojektuotos ir valdomos kaip produktai, įgalinantys kūrėjus, vidinius ar išorinius, kurti naujas programas, išplėsti prekės ženklo populiarumą ir atverti naujas pajamas.

Šis skirtumas yra svarbus: API yra naudojamos daugelyje integracijos scenarijų, todėl nereikia turėti API - reikia, kad API būtų sukurtos ir valdomos vartojimui, pakartotiniam naudojimui ir nuolatiniam tobulinimui. Kitaip tariant, atsižvelgiant į integracijos mąstymą, API gali išspręsti trumpalaikes problemas, tačiau pastebėjus, kad vidinis / išorinis padalijimas žlugo ir integracijos naudojimo atvejų nebepakanka, API valdymas tampa priimtiniausiu sprendimu.

[Norite sužinoti daugiau patarimų, kaip valdyti API ir skatinti skaitmeninį verslą? Žr. Naują „Apigee“ el. Knygą „API produkto mąstysena“].