API Inside vs. Outside the Enterprise

Il confine tra funzionalità IT interne ed esterne in un'azienda è una falsa distinzione. Nessuno può prevedere in che modo verranno utilizzati i dati o dove scorreranno le informazioni. Anche se sai dove sono disegnate le linee interne / esterne della tua azienda oggi, quelle linee saranno quasi sicuramente in movimento obiettivi in ​​futuro.

Prendi Pitney Bowes, un'azienda con cui ho lavorato nel mio ruolo nel team Apigee di Google. Sebbene gran parte della sua storia quasi centenaria sia stata radicata in soluzioni di mailing fisiche come contatori postali, la società ha anche sviluppato nel corso degli anni pagamenti e funzionalità di e-commerce e ha acquisito enormi quantità di dati logistici, di spedizione e di geolocalizzazione. Mentre Pitney Bowes si è evoluto dai servizi analogici al mondo odierno del commercio connesso, ha derivato valore da questi beni e competenze all'interno dell'organizzazione - ma ha riconosciuto che i beni e le competenze potrebbero essere preziosi anche al di fuori dell'azienda, per sviluppatori e partner che potrebbero usarli per creare nuove app e servizi.

Per cogliere questa opportunità, Pitney Bowes offre oltre 160 API pubbliche tramite il cloud, aprendo milioni di potenziali nuove entrate e aiutando gli sforzi del commercio digitale dell'azienda a diventare un business annuo di oltre 1 miliardo di dollari. I dati e le funzionalità che un tempo erano esclusivamente interne ora sono anche esterne.

C'è una lezione qui: pensare a soluzioni e strategie di business in termini di "interno" ed "esterno" o in termini di "integrazione del sistema A e del sistema B" è obsoleto. Il problema non è il modo in cui si collegheranno i sistemi e gli utenti interni: tale connessione può essere effettuata in diversi modi. Piuttosto, il problema è che cosa puoi fare con la connessione dopo che è stata stabilita.

La risposta dipende dal tipo di connessione: statica contro dinamica. Nel vecchio mondo delle soluzioni puntuali, ad esempio, il focus era spesso solo l'integrazione statica, ottenendo informazioni dal sistema A al sistema B. I meccanismi monolitici impiegati erano spesso fragili e complessi, focalizzati solo sull'attuale traiettoria A → B, come se le future rotte verso C, D o E non sarebbero mai avventurate.

Ma ovviamente non è così. Come dimostra l'esempio di Pitney Bowes, i percorsi dei dati di oggi potrebbero non assomigliare a quelli di domani. A lungo termine, tutte le connessioni devono essere dinamiche, pronte per essere ridimensionate in base alle esigenze e per interfacciarsi con tutto ciò che è richiesto. Per rimanere competitivi, non puoi semplicemente usare le stesse tecnologie e continuare a scappare, e non puoi fare affidamento su strutture fatiscenti come "dentro" e "fuori".

Più specificamente, ecco i requisiti minimi per l'accesso interno a un sistema:

  • Sicurezza
  • Audit trail
  • Visibilità
  • Prestazioni di runtime (tempo di attività, latenza)
  • Costo (riduzione dei costi, riduzione dei costi)

Tradizionalmente, molte aziende si sono fermate qui. Ma ci sono altri punti che devono essere considerati nel mondo in rapida evoluzione di oggi:

  • Approfondimenti / analytics
  • Facilità d'uso
  • Estensibilità
  • Opzioni di distribuzione (ad es. Contenitori, nuvole, scala)
  • monetazione
  • Controllo a grana fine

Come dimostrano i nuovi requisiti, se non costruisci i tuoi sistemi con l'aspettativa che dovranno interagire con sistemi che non sono ancora stati inventati, stai rischiando di bloccarti. Troppe persone pensano ancora erroneamente che la sfida consiste nel trasferire grandi quantità di dati attraverso una sicurezza a grana grossa verso app client spesse.

Ma andando avanti, le applicazioni e le architetture dovranno essere incredibilmente granulari e scalabili. Per arrivarci, le aziende devono passare da una mentalità di integrazione ad approcci più moderni che rendono i sistemi disponibili in modo granulare, affidabile e scalabile, fornendo visibilità, approfondimenti, controllo e sicurezza. La base per la maggior parte di queste architetture atomiche e agili saranno le API prodotte, ovvero le API che non vengono utilizzate solo per esporre le risorse ma che sono progettate e gestite come prodotti che consentono agli sviluppatori, interni o esterni, di creare nuove app, estendere la portata del marchio e aprire nuove possibilità di guadagno.

Questa distinzione è importante: le API sono utilizzate oggi in molti scenari di integrazione, quindi il punto non è avere API: è che le API siano progettate e gestite per il consumo, il riutilizzo e il miglioramento continuo. Detto in altro modo, con una mentalità di integrazione, le API possono risolvere problemi a breve termine, ma una volta che si vede che la divisione interna / esterna è crollata e che i casi di utilizzo dell'integrazione non sono più sufficienti, la gestione delle API diventa la soluzione più ragionevole.

[Sei interessato a ulteriori suggerimenti per la gestione delle API e la promozione del business digitale? Vedi il nuovo ebook di Apigee, "La mentalità del prodotto API".]