Rozhraní API uvnitř vs. mimo podnik

Hranice mezi interními a externími funkcemi IT v podniku je nesprávným rozlišením. Nikdo nemůže předvídat, jak budou data použita nebo kam budou informace proudit. I když víte, kde jsou dnes vykresleny vnitřní / vnější linie vaší společnosti - tyto linie se v budoucnu téměř jistě stanou pohyblivými cíli.

Vezměte Pitney Bowes, společnost, se kterou jsem pracoval ve své roli v týmu Apigee v Googlu. Zatímco většina z jeho historie téměř století byla zakořeněna ve fyzických poštovních řešeních, jako jsou poštovní metry, v průběhu let společnost také vyvinula možnosti plateb a elektronického obchodování a získala obrovské množství logistických, přepravních a geolokačních dat. Jak se Pitney Bowes vyvinul z analogových služeb do dnešního světa propojeného obchodu, odvodila hodnotu z těchto aktiv a kompetencí v rámci organizace - uznala však, že aktiva a kompetence mohou být cenné mimo společnost, pro vývojáře a partnery, kteří je mohou využívat vytvářet nové aplikace a služby.

Aby využil této příležitosti, Pitney Bowes nabízí přes 160 veřejných API prostřednictvím cloudu, otevírá miliony potenciálních nových výnosů a pomáhá společnosti v digitálním obchodním úsilí stát se roční miliardou dolarů plus roční roční obchod. Data a funkce, která byla kdysi výhradně interní, jsou nyní také externí.

Zde je lekce: uvažování o obchodních řešeních a strategiích z hlediska „interního“ a „externího“ nebo z hlediska „integrace systému A a systému B“ je zastaralé. Problém není v tom, jak se chystáte propojit své interní systémy a uživatele - toto spojení lze provést několika způsoby. Problémem je spíše to, co můžete s připojením udělat, jakmile bude vytvořeno.

Odpověď závisí na typu připojení - statické versus dynamické. Například ve starém světě bodových řešení byla často jen statická integrace, získávání informací ze systému A do systému B. Použité monolitické mechanismy byly často křehké a složité a zaměřovaly se pouze na současnou trajektorii A → B, jako by budoucí trasy do C, D nebo E by nikdy nebyly odvážné.

Ale samozřejmě to tak není. Jak ukazuje příklad Pitneyho Bowese, dnešní datové trasy nemusí vypadat jako zítra. V dlouhodobém horizontu musí být všechna připojení dynamická, připravená k nastavení měřítka nahoru nebo dolů podle potřeby a připravená k propojení s jakýmkoli požadavkem. Chcete-li zůstat konkurenceschopní, nemůžete použít pouze stejné technologie a dál se držet a nemůžete se spolehnout na rozpadající se rámce, jako jsou „uvnitř“ a „venku“.

Konkrétně jsou zde uvedeny minimální požadavky na interní přístup k systému:

  • Bezpečnostní
  • Audit trail
  • Viditelnost
  • Runtime výkon (doba provozu, latence)
  • Náklady (vyhýbání se nákladům, úspory nákladů)

Tradičně se zde zastavilo mnoho podniků. V dnešním rychle se rozvíjejícím světě je však třeba vzít v úvahu další body:

  • Statistiky / statistiky
  • Snadnost použití
  • Rozšiřitelnost
  • Možnosti nasazení (např. Kontejnery, mraky, měřítko)
  • Zpeněžení
  • Jemnozrnná kontrola

Jak ukazují nové požadavky, pokud své systémy nestavíte s očekáváním, že budou muset interagovat se systémy, které ještě nebyly vynalezeny, riskujete, že se uzamknete. Příliš mnoho lidí si stále mylně myslí, že Úkolem je spouštět velké kusy dat prostřednictvím hrubozrnného zabezpečení pro silné klientské aplikace.

Ale v budoucnu budou aplikace a architektury muset být neuvěřitelně granulární a škálovatelné. Abychom se tam dostali, musí se podniky vyvinout z integrační mentality k modernějším přístupům, které zpřístupňují systémy granulárně, spolehlivě a škálovatelně a zároveň poskytují viditelnost, vhled, kontrolu a zabezpečení. Základem pro většinu těchto atomových, agilních architektur budou produktizovaná rozhraní API - tj. API, která se nepoužívají pouze k odhalení aktiv, ale která jsou navržena a spravována jako produkty, které vývojářům, ať už interním nebo externím, umožňují vytvářet nové aplikace, rozšířit dosah značky a otevřít nové možnosti příjmů.

Toto rozlišení je důležité: API se dnes používají v mnoha scénářích integrace, takže nejde o to, aby API byla navržena a spravována pro spotřebu, opětovné použití a neustálé zlepšování. Jinak řečeno, s integračním přístupem mohou API řešit krátkodobé problémy - jakmile však jeden uvidí, že interní / externí divize se zhroutila a že případy použití integrace již nestačí, správa API se stává nejrozumnějším řešením.

[Máte zájem o další tipy pro správu rozhraní API a podporu digitálního podnikání? Viz nová e-kniha společnosti Apigee, „The API Product Mindset“.]]