API des de dins i fora de l'empresa

El límit entre la funcionalitat informàtica interna i externa d'una empresa és una distinció falsa. Ningú no pot predir com s’utilitzaran les dades ni on fluirà la informació. Tot i que saps on es dibuixen les línies interiors i exteriors de la teva empresa avui, les línies gairebé segurament seran objectius en moviment.

Pren Pitney Bowes, una empresa amb la qual he treballat en el meu equip a l’equip Apigee de Google. Tot i que bona part de la seva història propera al segle està arrelada en solucions de correu físic com ara mesuradors, la companyia també va desenvolupar els pagaments i les capacitats de comerç electrònic al llarg dels anys i va adquirir grans quantitats de dades de logística, enviament i geolocalització. A mesura que Pitney Bowes va evolucionar des dels serveis analògics fins al món actual del comerç connectat, va derivar valor d’aquests actius i competències dins de l’organització, però va reconèixer que els actius i competències podrien ser valuosos fora de l’empresa també als desenvolupadors i socis que podrien utilitzar-los. per crear aplicacions i serveis nous.

Per aprofitar aquesta oportunitat, Pitney Bowes ofereix més de 160 API públiques a través del núvol, obrint milions de diners en possibles nous ingressos i ajudant als esforços de comerç digital de la companyia a convertir-se en un negoci anual més d’1 mil milions de dòlars. Les dades i la funcionalitat que abans eren només internes també són externes.

Hi ha una lliçó: pensar en solucions i estratègies empresarials en termes de "intern" i "extern" o en termes de "integrar el sistema A i el sistema B" no està actualitzat. El problema no consisteix en la manera de connectar els vostres sistemes interns i els usuaris, sinó que podeu fer-ne una connexió de diverses maneres. Més aviat, el problema és el que podeu fer amb la connexió un cop feta.

La resposta depèn del tipus de connexió: estàtic versus dinàmic. En el vell món de solucions puntuals, per exemple, l’atenció era sovint només la integració estàtica, obtenint informació del sistema A al sistema B. Els mecanismes monolítics emprats eren sovint trencadissos i complexos, centrats només en la trajectòria actual A → B, com si fos. Les futures rutes a C, D o E mai no s’aventuraran.

Però, per descomptat, no és així. Tal com demostra l'exemple de Pitney Bowes, les rutes de dades actuals no podrien semblar res a les de demà. A la llarga, totes les connexions han de ser dinàmiques, estar preparades per escalar cap amunt o cap avall segons calgui i preparar la interfície amb el que sigui necessari. Per mantenir-se competitiu, no podeu fer servir les mateixes tecnologies i seguir endavant i no us podeu confiar en marcs enrunats com ara "dins" i "fora".

Més concretament, aquí teniu els requisits mínims per a l’accés intern a un sistema:

  • Seguretat
  • Pista d'auditoria
  • Visibilitat
  • Rendiment d'execució (temps de funcionament, latència)
  • Cost (evitació de costos, estalvi de costos)

Tradicionalment, moltes empreses s’han aturat aquí. Hi ha punts addicionals que cal tenir en compte en el món que es mou ràpidament:

  • Perspectives / analítiques
  • Facilitat d'ús
  • Extensibilitat
  • Opcions de desplegament (per exemple, contenidors, núvols, escala)
  • Monetització
  • Control de gra fi

Tal com demostren els nous requisits, si no construïu els vostres sistemes amb l’esperança que hauran d’interactuar amb sistemes que encara no s’han inventat, us arriscareu a bloquejar-vos. Massa persones encara creuen erròniament que el repte és transmetre grans fragments de dades mitjançant seguretat de gra gruixut a aplicacions de clients gruixuts.

Però, endavant, les aplicacions i les arquitectures hauran de ser increïblement granulars i escalables. Per arribar-hi, les empreses han d’evolucionar des d’una mentalitat d’integració fins a enfocaments més moderns que fan que els sistemes estiguin disponibles de forma granular, fiable i escalable alhora que proporcionen visibilitat, informació, control i seguretat. La base per a la majoria d’aquestes arquitectures àtiques i àgils seran les API que es produeixen, és a dir, les API que no s’utilitzen només per exposar actius, sinó que estan dissenyades i gestionades com a productes que permeten als desenvolupadors, ja siguin interns o externs, crear noves aplicacions, ampliar l’abast de la marca i obrir noves possibilitats d’ingressos.

Aquesta distinció és important: les API s’utilitzen avui dia en molts escenaris d’integració, de manera que el punt no és tenir API, sinó que s’ha de dissenyar i gestionar API per consum, reutilització i millora contínua. Altrament, amb una mentalitat d’integració, les API poden solucionar problemes a curt termini, però un cop es veu que la divisió interna / externa s’ha esfondrat i que els casos d’ús de la integració ja no són suficients, la gestió de l’API es converteix en la solució més raonable.

[T'interessa més consells per gestionar les API i conduir negocis digitals? Vegeu el nou llibre electrònic d'Apigee, "L'objectiu mental del producte API".]