API à l'intérieur et à l'extérieur de l'entreprise

La frontière entre les fonctionnalités informatiques internes et externes dans une entreprise est une fausse distinction. Personne ne peut prédire comment les données seront utilisées ou où les informations circuleront. Même si vous savez où les lignes intérieures / extérieures de votre entreprise sont tracées aujourd'hui - ces lignes seront certainement des cibles mobiles à l'avenir.

Prenez Pitney Bowes, une entreprise avec laquelle j'ai travaillé dans mon rôle au sein de l'équipe Apigee chez Google. Alors qu'une grande partie de son histoire de près d'un siècle a été enracinée dans des solutions d'envois physiques tels que les machines à affranchir, la société a également développé des capacités de paiement et de commerce électronique au fil des ans et acquis de grandes quantités de données de logistique, d'expédition et de géolocalisation. Au fur et à mesure que Pitney Bowes est passé des services analogiques au monde actuel du commerce connecté, il a tiré de la valeur de ces actifs et compétences au sein de l'organisation - mais il a reconnu que les actifs et les compétences pouvaient également être précieux à l'extérieur de l'entreprise, pour les développeurs et les partenaires qui pouvaient les utiliser. pour créer de nouvelles applications et de nouveaux services.

Pour saisir cette opportunité, Pitney Bowes propose plus de 160 API publiques via le cloud, ouvrant des millions de nouveaux revenus potentiels et aidant les efforts de commerce numérique de l'entreprise à devenir une activité annuelle de plus d'un milliard de dollars. Les données et fonctionnalités qui étaient autrefois uniquement internes sont désormais également externes.

Il y a une leçon à tirer ici: la réflexion sur les solutions et stratégies commerciales en termes «internes» et «externes» ou en termes «d'intégrer le système A et le système B» est dépassée. Le problème n'est pas de savoir comment vous allez connecter vos systèmes internes et vos utilisateurs - cette connexion peut être établie de plusieurs façons. Le problème est plutôt de savoir ce que vous pouvez faire avec la connexion une fois celle-ci établie.

La réponse dépend du type de connexion - statique contre dynamique. Dans l'ancien monde des solutions ponctuelles, par exemple, l'accent était souvent uniquement sur l'intégration statique, obtenant des informations du système A au système B. Les mécanismes monolithiques utilisés étaient souvent fragiles et complexes, concentrés uniquement sur la trajectoire A → B actuelle, comme si les routes futures vers C, D ou E ne seraient jamais envisagées.

Mais bien sûr, ce n’est pas le cas. Comme le montre l'exemple de Pitney Bowes, les chemins de données d'aujourd'hui pourraient ne ressembler en rien à ceux de demain. À long terme, toutes les connexions doivent être dynamiques, prêtes à être augmentées ou réduites au besoin, et prêtes à s'interfacer avec tout ce qui est requis. Pour rester compétitif, vous ne pouvez pas simplement utiliser les mêmes technologies et continuer à vous accrocher, et vous ne pouvez pas compter sur des cadres en ruine tels que «à l'intérieur» et «à l'extérieur».

Plus précisément, voici les exigences minimales pour l'accès interne à un système:

  • Sécurité
  • Piste d'audit
  • Visibilité
  • Performances d'exécution (disponibilité, latence)
  • Coût (évitement des coûts, économies de coûts)

Traditionnellement, de nombreuses entreprises se sont arrêtées ici. Mais il y a des points supplémentaires à prendre en compte dans le monde en évolution rapide d'aujourd'hui:

  • Insights / analytics
  • Facilité d'utilisation
  • Extensibilité
  • Options de déploiement (par exemple, conteneurs, nuages, évolutivité)
  • Monétisation
  • Contrôle à grain fin

Comme le démontrent les nouvelles exigences, si vous ne construisez pas vos systèmes avec l'espoir qu'ils devront interagir avec des systèmes qui n'ont pas encore été inventés, vous risquez de vous enfermer. Trop de gens pensent encore à tort que le défi consiste à transférer de gros morceaux de données via une sécurité à granularité grossière vers des applications clientes épaisses.

Mais à l'avenir, les applications et les architectures devront être incroyablement granulaires et évolutives. Pour y parvenir, les entreprises doivent évoluer d'une mentalité d'intégration vers des approches plus modernes qui rendent les systèmes disponibles de manière granulaire, fiable et évolutive tout en fournissant visibilité, perspectives, contrôle et sécurité. Le fondement de la plupart de ces architectures atomiques et agiles sera les API productives, c'est-à-dire les API qui ne sont pas seulement utilisées pour exposer des actifs, mais qui sont conçues et gérées comme des produits qui permettent aux développeurs, internes ou externes, de créer de nouvelles applications, étendre la portée de la marque et ouvrir de nouvelles possibilités de revenus.

Cette distinction est importante: les API sont utilisées aujourd'hui dans de nombreux scénarios d'intégration, il ne s'agit donc pas d'avoir des API, mais d'avoir des API conçues et gérées pour la consommation, la réutilisation et l'amélioration continue. Autrement dit, avec un esprit d'intégration, les API peuvent résoudre des problèmes à court terme - mais une fois que l'on voit que la division interne / externe s'est effondrée et que les cas d'utilisation d'intégration ne sont plus suffisants, la gestion des API devient la solution la plus raisonnable.

[Intéressé par plus de conseils pour gérer les API et stimuler les affaires numériques? Voir le nouvel ebook d'Apigee, «La mentalité du produit API».]