« Traditionnellement l’architecture orientée services a servi à construire des ensembles fermés ; les changements dus aux activités commerciales ont été effectués au sein des systèmes. En pratique, l’architecture basée sur l’API cherche à construire un modèle opérationnel basé sur l’accessibilité des données internes du système et des fonctions, aussi bien à l’intérieur qu’à l’extérieur du système, par le biais d’interfaces établies » raconte le Solution Architect de Bonsky Digital, Kimmo Lankila.

Le soutien aux activités commerciales comme objectif

Plus on a recours au modèle de solution de service en couches basé sur l’API, plus il est facile d’effectuer les transitions d’un système à l’autre.
« Auparavant, pour changer les solutions au sein des systèmes, il fallait collaborer avec le fournisseur. Cela est souvent lent, laborieux et cher. En outre, les connexions entre les systèmes ont souvent été réalisées avec des outils d’intégration au cas par cas, ce qui a rendu les connexions entre systèmes très complexes » déclare M. Lankila.

Une architecture basée sur l’API se base sur la création de couches et de composants interopérables. Le terme exact serait une architecture de microservices basée sur l’API.
« Le but de l’architecture de microservices est de créer de petits ensembles qu’il est plus facile de développer et de gérer indépendamment. Le principe de ces microservices se base sur de plus petites entités qui facilitent la numérisation de différentes parties des activités indépendamment les unes des autres » raconte M. Lankila.

« Cela permet également de tirer profit agilement de services de tiers. Notamment les services en nuage qui fournissent des fonctionnalités et des services en constant développement, permettant d’ajouter de nouvelles propriétés aux systèmes et de soutenir leur développement » dit le développeur de programmes de Vincit, Jukka Rintaluoma.

Une véritable architecture orientée services en couches, basée sur l’API, crée de la rentabilité et permet la réutilisation. Cela élimine également le besoin superflu de créer des solutions particulières pour transférer les données à l’avenir.

« Nous voulons aider le client à échapper aux griffes d’un système unique. Les processus et systèmes qui tournent autour de la gestion des données devraient s’adapter aux besoins des entreprises et non l’inverse. »

Comment reconnaître une architecture orientée services, basée sur l’API, qui soit réellement indépendante ? 

À en croire les vendeurs, presque toutes les plateformes semblent actuellement être fondées sur l’architecture orientée services basée sur l’API. Alors comment reconnaître une véritable architecture orientée services basée sur l’API indépendante, d’une solution qui mène à un enfermement propriétaire ?
« Par exemple, Salesforce et SAP sont des plateformes basées sur l’API, en théorie. Mais dans ces cas de figure, la performance de l’API est liée à la plateforme et à ses capacités. Pour les développer, il est nécessaire de maîtriser le fonctionnement en profondeur des plateformes, ainsi que les éventuels outils conçus spécifiquement pour celles-ci. En s’engageant à concentrer ses solutions autour de cette plateforme, on renonce à la possibilité de chercher et de tirer profit de meilleures solutions pour différents besoins et on se retrouve dans une situation où, encore une fois, la capacité d’un seul système gouverne les possibilités de développement d’une entreprise » insiste M. Lankila.

Une architecture basée sur l’API cherche à briser les cloisons entre les systèmes et à permettre une expérience d’utilisation de première classe et multicanale, avec une exécution en couches et modulaire. 
« On permet ainsi à l’entreprise de développer des capacités conçues pour des besoins individuels et de se libérer des restrictions liées aux systèmes individuels et de leurs fournisseurs » continuent M. Rintaluoma et M. Lankila.

L’architecture orientée services doit pouvoir s’adapter aux activités de l’entreprise 

Le plus grand avantage d’une architecture orientée services basée sur l’API est de permettre à l’organisation de s’adapter aux différents besoins des activités commerciales et de mettre les données de l’entreprise à la disposition de tous. Dans la pratique, l’avantage compétitif majeur découle du développement des capacités de gestion des données à long terme. L’information et la fonctionnalité doivent être disponibles pour plusieurs utilisations différentes, sans arrangements particuliers. 
« Lorsqu’une équipe de développement interne réalise son projet en se basant sur l’API, les capacités sont rapidement disponibles pour tous les autres domaines de l’entreprise et il est facile de proposer également ces capacités aux partenaires et aux clients. Les mêmes structures permettent donc de créer de la valeur, aussi bien au sein de l’entreprise qu’en dehors de celle-ci » raconte M. Lankila.

La capacité d’une API peut se construire agilement, il ne s’agit pas de construire la cathédrale de Berne. 
« On peut se lancer dans la construction d’une API pour un besoin individuel, par exemple, fournir les données de disponibilité des produits. Si la gestion des données de disponibilité des produits est créée en interne conformément à l’API, il est facile de transférer ces données aux partenaires et aux clients par le biais d’une interface. Ou alors, si on enrichit les données de produit en interne, on peut également ouvrir des voies, afin de permettre aux entreprises de transmettre facilement les données de produit par le biais d’une interface. Cette même interface pourra être utilisée par des tiers, comme par exemple des boutiques en ligne. Dans la distribution, on peut tirer profit des données obtenues par le biais de l’API de la manière désirée, par exemple, en informant les distributeurs directement des prix les concernant dans leurs propres systèmes. Si on continue sur cette lancée, les vieilles habitudes de transfert de données entre différentes organisations deviendront petit à petit obsolètes » explique M. Lankila.

En promouvant l’architecture basée sur l’API, il ne faut pas oublier que les solutions doivent être entretenues et développées. 
« Les API livrent des informations à de nombreux opérateurs internes et possiblement externes, nous sommes donc responsable de leur bon fonctionnement. Il convient d’en prendre bien soin et de soutenir leur développement. Les descriptions d’interface doivent être maintenues à jour et les modifications prévues doivent être effectuées sans obliger toutes les parties à y réagir immédiatement. Le développement responsable et la culture opérationnelle des DevOps sont comme des obligations qui débouchent sur une meilleure expérience client » réfléchissent M. Rintaluoma et M. Lankila.

Vos systèmes dictent-ils vos activités ? 

Quel que soit le modèle d’architecture orientée services retenu, le plus important est de planifier les solutions en se basant sur les conditions de l’entreprise et non sur celles de la technologie ou du système. 
« Les entreprises ont souvent une multitude d’idées, mais généralement on ne peut pas les réaliser, car les systèmes disponibles ne le permettent pas. Sans le vouloir, l’équipe informatique freine souvent le développement sur ce point, car la responsabilité de la réalisation des idées lui incombe et les solutions nécessaires rendraient son travail plus complexe » dit M. Lankila.

M. Lankila aimerait proposer aux entreprises un modèle opérationnel où l’informatique serait responsable des systèmes définis et de l’infrastructure, tout en aidant l’entreprise à comprendre l’architecture numérique actuelle et les capacités disponibles. En outre, l’équipe informatique et l’entreprise pourraient collaborer, afin d’évaluer comment ajouter de nouvelles solutions à l’architecture numérique dans son ensemble. 
« Il faut également investir dans le maintien de l’architecture numérique orientée services. La culture opérationnelle des DevOps est particulièrement importante pour cet aspect. Dans le développement, il faut que, dès le début, toutes les fonctionnalités et structures soient le plus automatisées possibles et les erreurs doivent être soigneusement corrigées » raconte M. Rintaluoma.

« Une architecture basée sur la culture d’API et dirigée par les activités économiques permet de rendre l’organisation plus compétitive. Le développement de nouvelles solutions doit donc incomber davantage à l’entreprise. En créant des responsabilités plus claires pour l’informatique, on permet à l’entreprise de réfléchir à l’impact des solutions planifiées sur son ensemble et on obtient un avantage maximal » résume M. Lankila.

Comment les entreprises peuvent-elles se lancer dans une architecture orientée services basée sur l’API ?

Lorsque vous souhaitez garantir la compétitivité de votre entreprise et créer des activités commerciales proactives dans un environnement opérationnel en constante évolution, voici comment se lancer : 

  1. Identifiez quel genre de service numérique vous souhaitez produire. Essayez de comprendre les besoins de l’entreprise. Cherchez comment les données sont connectées, quelles sont les capacités de votre organisation, par exemple en ce qui concerne les intégrations nécessaires, comment réaliser une solution basée sur l’API dans l’écosystème actuel.
  2. Commencez simplement. Prenons par exemple une situation où une application mobile est nécessaire pour les employés sur le terrain, afin de réceptionner les tâches. L’application mobile communique avec l’interface fournie par le système back-end de l’entreprise. En créant une interface séparée (système d’API) au-dessus du système de l’entreprise, on fait un pas en avant vers une architecture numérique indépendante des systèmes (voir l’image).
  3. Implantez la culture opérationnelle DevOps dès le début. Automatisez toutes les fonctions possibles.
  4. Faites avancer les choses petit à petit et devenez de plus en plus indépendant des systèmes individuels en tâche de fond. Par exemple, lorsque vous rajoutez des fonctionnalités à l’application mobile décrite dans la phase précédente, n’effectuez pas uniquement les modifications à la couche de système d’API, mais ajoutez une nouvelle couche, une API de processus, qui assume les responsabilités des fonctionnalités de l’entreprise et de gestion des données.
  5. Au cours de la phase suivante, vous pouvez commencer à implanter des fonctionnalités de niveau d’expérience sur la couche de processus d’API basée sur l’entreprise. L’objectif est d’unifier les fonctionnalités au niveau des processus et de créer une expérience d’utilisation particulière autour de ceux-ci. Ainsi, il devient possible d’autoriser les alertes [notifications] instantanées d’une application mobile, par exemple, et une interface « publique » pour les opérateurs travaillant en-dehors du terrain. Les deux fonctionnalités peuvent utiliser les mêmes capacités.
  6. Gardez à tout moment la vue d’ensemble en tête et n’oubliez pas comment vous voulez développer l’architecture. Le développement doit être basé sur les affaires, et non sur les systèmes. Les itérations et le peaufinage de petites entités permettent d’acquérir la capacité de s’adapter aux besoins de l’entreprise.

Vincit et Bonsky ont uni leurs forces afin d’aider les entreprises industrielles à affronter l’avenir avec confiance et sérénité grâce à leurs approches innovantes. Vincit se concentre sur la transformation et la numérisation des opérations commerciales, notamment la gestion de changements grâce à des choix stratégiques, de nouveaux modèles d’opérations commerciales et un leadership éclairé. Bonsky Digital se charge de développer des activités et une architecture numériques avec des méthodes de design agiles qui impliquent les clients.

Experts :

Kimmo Lankila, Solution Architect, Bonsky Digital Oy
Dans le monde de la technologie en constante évolution, il y a toujours une nouveauté au coin de la rue permettant de peaufiner les modèles de solution familiers.

Jukka Rintaluoma, Développeur de programmes, Vincit Oyj
Moins de code, moins d’erreurs

Des questions ?

Christopher Blackwell, Vincit Plc, tél. +41 78 748 7777, christopher.blackwell@vincit.com

Auteurs : Minna Haapsaari, Bonsky Digital Oy