API gateway ili tačka-tačka integracija za preduzeća

Porudžbina iz veb prodavnice ujutru ulazi u ERP, zatim u sistem skladišta, pa u sistem fakturisanja i sistem kurirske službe. Dok se radi o dva-tri povezivanja, proces uglavnom funkcioniše neprimetno. Međutim, nakon nekoliko godina rasta, pojavljuju se novi prodajni kanali, dobavljački odnosi, korisnički portali i zahtevi za izveštavanjem. Tada pitanje API gateway-a ili point-to-point integracije više nije samo informatička odluka: određuje koliko je rad transparentan i održiv.

Loša odluka retko izaziva trenutni zastoj. Umesto toga, postepeno se pojavljuju problemi: jedno polje podataka mora se promeniti na tri mesta, nakon ažuriranja sistema neočekivano dolazi do greške u prenosu porudžbine, i niko tačno ne zna koja veza je odgovorna za nestali status. U takvim slučajevima, poslovni proces naizgled teče između sistema, ali zapravo ga ljudi održavaju kontrolama, e-mailovima i tabelama.

Šta znači point-to-point integracija?

O point-to-point integraciji govorimo kada dva sistema direktno komuniciraju jedan s drugim. Na primer, veb prodavnica šalje podatke o porudžbini ERP-u, a ERP prosleđuje informacije o zalihama nazad veb prodavnici. Svaka veza može funkcionisati sa sopstvenim pravilima, formatom podataka, upravljanjem pravima i rukovanjem greškama.

Ovaj pristup nije pogrešan, štaviše, u mnogim slučajevima je najrazumniji izbor. Ako kompanija ima samo jednu veb prodavnicu, jedan ERP i jasno definisanu razmenu podataka, direktna veza može biti brzo ostvariva, lako razumljiva i proporcionalno troškovno efikasna. Nema potrebe graditi centralni sloj integracije samo zato što se čini tehnološki elegantnijim.

Problem počinje sa povećanjem broja veza. Ako se na isti ERP povezuju veb prodavnica, CRM, sistem skladišta, špediter, platforma dobavljača, BI sistem i korisnički portal, svaka nova veza stvara sopstvenu zavisnost. Promena strukture podataka u ERP-u tada nije samo razvojni zadatak, već usklađivanje više sistema i poslovnih procesa.

U point-to-point modelu često se dešava da se ista poslovna pravila pojavljuju na više mesta. Promena statusa porudžbine, čišćenje podataka o partnerima ili usklađivanje polja master podataka može se posebno uvesti u svaku integraciju. To ne samo da znači dodatni razvojni rad. Kasnije otklanjanje grešaka takođe se usporava, jer kompanija prvo mora da razume gde je nastala razlika.

Šta pruža API gateway?

API gateway je centralni ulazni i kontrolni sloj u komunikaciji između sistema. Umesto da svaka aplikacija direktno pristupa svim ostalim sistemima, spoljašnji i unutrašnji zahtevi prolaze kroz određene, nadgledane rute.

Na poslovnom jeziku to znači da kompanija ne upravlja skupom odvojenih tehničkih veza, već uspostavlja red u komunikaciji sistema. Može se odrediti ko može zatražiti koje podatke, u kojem formatu, kojom učestalošću, sa kojim pravima i uz koje beleženje. Novi partnerski interfejs ili mobilna aplikacija ne mora imati direktan pristup unutrašnjem ERP-u samo da bi videla zalihe ili status porudžbine.

Gateway je posebno vredan tamo gde su pristup i operativna sigurnost poslovni rizik. Centralno se može upravljati autentifikacijom, pravima, ograničenjem saobraćaja, beleženjem i praćenjem grešaka. Ako spoljni sistem pogrešno ponovi zahtev, ne opterećuje neograničeno unutrašnji sistem. Ako partnerov pristup prestane, ne treba tražiti njegova prava u više odvojenih veza.

Važna razlika je da API gateway ne rešava nužno svaki zadatak integracije. Nije automatski alat za poboljšanje kvaliteta podataka, ne zamenjuje razjašnjavanje procesa i ne može odlučiti koji sistem treba da bude zvanični izvor podataka. Ako se podaci o kupcima razlikuju u CRM-u, ERP-u i staroj evidenciji klijenata, gateway može samo urednije preneti razliku.

API gateway ili point-to-point integracija: pravi kriterijumi odluke

Dobar odgovor na pitanje nije da sve veze treba centralizovati. Dobar odgovor je onaj koji odgovara složenosti procesa kompanije, tempu promena i rizicima.

Point-to-point veza je obično opravdana kada je razmena podataka jednostavna, ostaje između dva sistema, retko se menja i nema osetljivog spoljnog pristupa. U slučaju uskog skupa podataka koji proizvodna mašina prenosi svakodnevno ili jedinstvene veze za štampanje etiketa prevoznika, direktna integracija može biti dobro dokumentovano i operativno sigurno rešenje.

Situacija ukazuje na API gateway kada iste usluge koristi više sistema, partnera ili kanala. Tipičan primer je kada veb prodavnica, korisnički portal i aplikacija za prodaju svi zahtevaju status porudžbine, zalihe ili podatke o kupcima. U takvim slučajevima nije poslovno razumno da se svi direktno prilagođavaju unutrašnjem funkcionisanju ERP-a. Bolje je uspostaviti stabilan, regulisan servisni interfejs, iza kojeg se unutrašnji sistem može kasnije modifikovati.

Trošak promene je takođe odlučujući faktor. Direktna veza može se u početku činiti jeftinijom. Ali ako svaki novi kanal zahteva poseban razvoj, posebnu sigurnosnu proveru i posebno otklanjanje grešaka, kratkoročna jednostavnost može biti skupa na duge staze. Nasuprot tome, uvođenje gateway-a zahteva više planiranja i disciplinovaniju arhitekturu u početku. Isplati se kada kompanija mora da upravlja ne jednom vezom, već ponovljenim novim povezivanjima.

Prvo neka podaci i proces budu jasni

Mnogi projekti integracije propadaju jer tehnička pitanja preteknu poslovno razjašnjenje. Pre nego što se odluči arhitektura, vredi pratiti konkretan proces: šta se dešava od prijema porudžbine do isporuke, ko može menjati podatke, gde nastaje nova informacija i u kojem sistemu podaci postaju konačni.

Na primer, ako skladište koristi ERP zalihe, ali veb prodavnica prikazuje dostupnost prema sopstvenim pravilima, nije tehnički detalj koji podaci su vidljivi kupcu. To direktno utiče na mogućnost naručivanja, komunikaciju sa kupcima i broj reklamacija. Integracija će biti pouzdana samo ako su ove odgovornosti i poslovna pravila jasna.

Isto važi i za rukovanje greškama. Šta se dešava ako sistem fakturisanja privremeno nije dostupan? Da li se obrada porudžbine zaustavlja, podaci stavljaju u red čekanja ili neko pokušava ručno da ih nadoknadi? Ko dobija obaveštenje i kada se greška smatra rešenom? Dobra integracija nije ona koja šalje podatke u normalnim uslovima, već ona koja ostaje proverljiva i u vanrednim situacijama.

Postepeno sređivanje često je bolje od rekonstrukcije

U rastućoj kompaniji nije realno očekivati da se svi postojeći odnosi redizajniraju odjednom. Štaviše, prevelike promene u integracijama koje podržavaju kritične operacije mogu predstavljati ozbiljan poslovni rizik.

Razumnije je prvo mapirati veze: koje podatke prenose, ko ih koristi, koliko su kritične, ko je odgovoran za njih i da li postoji ažurirana dokumentacija. Već ovaj posao može otkriti da samo jedan zaposleni zna zašto se vrši stari prenos podataka ili da isti podaci teku paralelno između dva sistema sa različitim pravilima.

Zatim je vredno početi sa područjima koja donose najviše vrednosti. Možda je već opravdano uspostaviti pristup zasnovan na gateway-u za novi korisnički portal, dok dve stare, stabilne unutrašnje veze za sada ostaju direktne. Cilj nije pratiti tehnološki obrazac, već postepeno poboljšavati kontrolu, održivost i fleksibilnost.

Dobra arhitektura sistema na kraju nije vredna zbog broja modernih komponenti koje sadrži. Vredna je jer je putanja porudžbine, podatka o zalihama ili fakture razumljiva, proverljiva i funkcionalna čak i kada kompanija dođe do sledećeg koraka rasta.