API's Inside vs. Outside the Enterprise

De grens tussen interne en externe IT-functionaliteit in een onderneming is een vals onderscheid. Niemand kan voorspellen hoe gegevens zullen worden gebruikt of waar informatie naartoe zal stromen. Zelfs als u weet waar de binnen- / buitenlijnen van uw bedrijf vandaag worden getekend, zullen deze lijnen vrijwel zeker doelen in de toekomst verplaatsen.

Neem Pitney Bowes, een bedrijf waarmee ik heb samengewerkt in mijn rol in het Apigee-team bij Google. Hoewel een groot deel van zijn bijna-eeuwse geschiedenis is geworteld in fysieke e-mailoplossingen, zoals frankeermachines, ontwikkelde het bedrijf in de loop der jaren ook betalings- en e-commercemogelijkheden en verwierf het enorme hoeveelheden logistieke, verzend- en geolocatiegegevens. Terwijl Pitney Bowes evolueerde van analoge diensten naar de hedendaagse wereld van geconnecteerde handel, ontleende het waarde aan deze activa en competenties binnen de organisatie - maar het erkende dat de activa en competenties ook buiten het bedrijf waardevol kunnen zijn, voor ontwikkelaars en partners die ze kunnen gebruiken om nieuwe apps en services te bouwen.

Om deze kans te benutten, biedt Pitney Bowes meer dan 160 openbare API's via de cloud, waardoor miljoenen potentiële nieuwe inkomsten worden gegenereerd en de inspanningen van het bedrijf op het gebied van digitale handel een jaarlijkse omzet van meer dan $ 1 miljard worden. Gegevens en functionaliteit die ooit alleen intern waren, zijn nu ook extern.

Hier is een les: denken aan bedrijfsoplossingen en -strategieën in termen van "intern" en "extern" of in termen van "systeem A en B integreren" is verouderd. Het probleem is niet hoe je je interne systemen en gebruikers gaat verbinden - die verbinding kan op een aantal manieren worden gemaakt. Het gaat er eerder om wat u kunt doen met de verbinding nadat deze is gemaakt.

Het antwoord hangt af van het type verbinding - statisch versus dynamisch. In de oude wereld van puntoplossingen lag de focus bijvoorbeeld vaak op statische integratie, waarbij informatie van systeem A naar systeem B werd gebracht. De gebruikte monolithische mechanismen waren vaak broos en complex, alleen gericht op het huidige A → B traject, alsof toekomstige routes naar C, D of E zouden nooit worden gewaagd.

Maar dat is natuurlijk niet het geval. Zoals het voorbeeld van Pitney Bowes aantoont, lijken de datapaden van vandaag misschien niet op die van morgen. Op de lange termijn moeten alle verbindingen dynamisch zijn, klaar zijn om naar behoefte te worden opgeschaald of te worden geschaald en klaar om te communiceren met alles wat nodig is. Om concurrerend te blijven, kunt u niet alleen dezelfde technologieën gebruiken en blijven voortbouwen, en kunt u niet vertrouwen op afbrokkelende frameworks zoals "binnen" en "buiten".

Meer specifiek zijn hier de minimale vereisten voor interne toegang tot een systeem:

  • Veiligheid
  • Audit trail
  • Zichtbaarheid
  • Runtime-prestaties (uptime, latentie)
  • Kosten (kostenvermijding, kostenbesparingen)

Traditioneel zijn veel bedrijven hier gestopt. Maar er zijn extra punten waarmee rekening moet worden gehouden in de snel veranderende wereld van vandaag:

  • Insights / analytics
  • Makkelijk te gebruiken
  • rekbaarheid
  • Implementatie-opties (bijv. Containers, clouds, schaal)
  • monetization
  • Fijne korrelregeling

Zoals de nieuwe vereisten aantonen, als je je systemen niet bouwt met de verwachting dat ze moeten communiceren met systemen die nog niet zijn uitgevonden, riskeer je jezelf op te sluiten. Te veel mensen denken nog steeds ten onrechte dat de uitdaging is om grote hoeveelheden gegevens via grofkorrelige beveiliging te verplaatsen naar dikke client-apps.

Maar vanaf nu moeten applicaties en architecturen ongelooflijk gedetailleerd en schaalbaar zijn. Om daar te komen, moeten bedrijven evolueren van een integratiementaliteit naar modernere benaderingen die systemen granulair, betrouwbaar en schaalbaar maken en tegelijkertijd zichtbaarheid, inzichten, controle en beveiliging bieden. De basis voor de meeste van deze atomaire, behendige architecturen zullen product-API's zijn, dat wil zeggen API's die niet alleen worden gebruikt om activa te ontmaskeren, maar die zijn ontworpen en beheerd als producten waarmee ontwikkelaars, intern of extern, nieuwe apps kunnen maken, vergroot het merkbereik en open nieuwe omzetmogelijkheden.

Dit onderscheid is belangrijk: API's worden tegenwoordig in veel integratiescenario's gebruikt, dus het is niet nodig om API's te hebben - het is om API's te laten ontwerpen en beheren voor consumptie, hergebruik en voortdurende verbetering. Anders gezegd, met een integratiemindset kunnen API's problemen op de korte termijn oplossen - maar zodra men ziet dat de interne / externe divisie is ingestort en dat integratie-use cases niet langer voldoende zijn, wordt API-beheer de meest redelijke oplossing.

[Geïnteresseerd in meer tips voor het beheren van API's en het stimuleren van digitale business? Zie het nieuwe e-boek van Apigee, "The API Product Mindset."]