API-ji znotraj in zunaj podjetja

Meja med notranjo in zunanjo IT funkcionalnostjo v podjetju je napačna razlika. Nihče ne more napovedati, kako bodo uporabljeni podatki ali kam se bodo pretakale informacije. Tudi če veste, kje so danes narisane notranje / zunanje črte vašega podjetja - bodo te linije skoraj zagotovo ciljne točke v prihodnosti.

Vzemite Pitney Bowes, podjetje, s katerim sem sodeloval pri svoji vlogi pri Googlovi ekipi Apigee. Medtem ko je bil velik del zgodovine skoraj stoletja vkoreninjen v rešitve fizične pošte, kot so poštni števci, je podjetje v preteklih letih razvilo tudi možnosti plačil in e-trgovine ter pridobil ogromno podatkov o logistiki, pošiljanju in geolokaciji. Ko se je Pitney Bowes razvijal od analognih storitev do današnjega sveta povezane trgovine, je iz teh sredstev in kompetenc znotraj organizacije pridobival vrednost - vendar je ugotovil, da so sredstva in pristojnosti lahko koristna tudi zunaj podjetja, razvijalcem in partnerjem, ki bi jih lahko uporabljali ustvariti nove aplikacije in storitve.

Da bi izkoristil to priložnost, Pitney Bowes ponuja več kot 160 javnih API-jev prek oblaka, ki odpirajo milijone potencialnih novih prihodkov in pomagajo družbenim prizadevanjem za digitalno trgovino postati letno podjetje, ki presega milijardo dolarjev. Podatki in funkcionalnosti, ki so bile nekoč samo notranje, so zdaj tudi zunanje.

Tukaj je lekcija: razmišljanje poslovnih rešitev in strategij v smislu "notranjega" in "zunanjega" ali v smislu "integriranja sistema A in sistema B" je zastarelo. Vprašanje ni v tem, kako boste povezali notranje sisteme in uporabnike - to povezavo je mogoče izvesti na več načinov. Namesto tega je vprašanje, kaj lahko storite s povezavo, ko je vzpostavljena.

Odgovor je odvisen od vrste povezave - statična v primerjavi z dinamično. V starem svetu točkovnih rešitev, na primer, je bil poudarek pogosto na statični integraciji, pridobivanju informacij iz sistema A v sistem B. Uporabljeni monolitni mehanizmi so bili pogosto krhki in zapleteni, osredotočeni so samo na trenutno A → B smer, kot da prihodnje poti na C, D ali E se nikoli ne bi odpravili.

Ampak to seveda ni tako. Kot kaže primer Pitney Bowes, današnje poti podatkov morda ne bodo videti nič podobne jutrišnjim. Na dolgi rok morajo biti vse povezave dinamične, pripravljene za spreminjanje po potrebi navzgor ali navzdol in pripravljene za vmesnik s tem, kar je potrebno. Če želite ostati konkurenčni, ne morete uporabljati istih tehnologij in nadaljevati s krepitvijo in se ne morete zanašati na razpadanje okvirov, kot sta »znotraj« in »zunaj«.

Natančneje, tukaj so minimalne zahteve za notranji dostop do sistema:

  • Varnost
  • Revizijska sled
  • Vidnost
  • Učinkovitost izvajanja (uptime, zamuda)
  • Stroški (izogibanje stroškom, prihranki stroškov)

Tu se že tradicionalno ustavi veliko podjetij. Toda v današnjem hitrem svetu je treba upoštevati še dodatne točke:

  • Vpogled / analitika
  • Enostavnost uporabe
  • Razširljivost
  • Možnosti razmestitve (npr. Zabojniki, oblaki, lestvica)
  • Monetizacija
  • Finozrnat nadzor

Kot kažejo nove zahteve, če svojih sistemov ne boste zgradili v pričakovanju, da bodo morali komunicirati s sistemi, ki še niso bili izumljeni, tvegate, da se zaprete. Preveč ljudi še vedno zmotno misli, da izziv je prenašanje velikih kosov podatkov prek grobozrnate varnosti do debelih aplikacij za stranke.

V prihodnosti pa bodo aplikacije in arhitekture morali biti izjemno natančni in razširljivi. Če želite priti do tja, se morajo podjetja razviti od integracijske miselnosti do sodobnejših pristopov, ki omogočajo sistematično in zanesljivo dostopnost sistemov, hkrati pa zagotavljajo vidnost, vpogled, nadzor in varnost. Temelj večine teh atomskih, okretnih arhitektur bodo producirani API-ji - to so API-ji, ki se ne uporabljajo samo za izpostavljanje sredstev, ampak so zasnovani in upravljani kot izdelki, ki razvijalcem omogočajo, da so notranji ali zunanji, da ustvarijo nove aplikacije, razširite doseg blagovne znamke in odprite nove možnosti prihodka.

To razlikovanje je pomembno: API-ji se danes uporabljajo v številnih scenarijih integracije, zato poanta ni v tem, da imajo API-ji - načrtovali in upravljali API-je za porabo, ponovno uporabo in nenehno izboljševanje. Povedano drugače, z integracijo miselnosti o integraciji lahko API-ji rešijo kratkoročne težave - a ko enkrat opazimo, da se je notranji / zunanji delitev sesul in da primeri uporabe integracije ne zadostujejo, postane upravljanje API-ja najbolj razumna rešitev.

[Vas zanima več nasvetov za upravljanje API-jev in vodenje digitalnega podjetja? Oglejte si novo e-knjigo Apigee-ja, "Mindset API Product."]