Les entreprises connectées ont besoin de plateformes pour mener cette transformation numérique. Un groupe d'API est un élément fondamental de telles plateformes.
Agile et API
À l'heure actuelle, de nombreuses entreprises parlent beaucoup du principe Agile, car ce processus de livraison de logiciel est une méthodologie appropriée qui permet de réduire le délai de mise sur le marché des applications d'entreprise. Et les fournisseurs API font manifestement leur maximum pour intégrer l'adaptabilité à leurs propres services et processus d'entreprise. Mais dans le cas qui nous occupe, il ne s'agit pas d'adaptabilité en tant que processus de développement de logiciels. Cet article envisage l'adaptabilité de l'API ou du système comme un ensemble dans l'environnement d'exécution.
Et si le comportement de l'API dépendait de l'emplacement où elle est invoquée ? Quelle est la flexibilité de l'API dans un environnement d'utilisation en perpétuel changement ?
Il est nécessaire d'aborder ces questions d'un point de vue architectural.
Étant donné que nos clients sont toujours connectés et impatients d'utiliser nos applications ou API — sans se soucier du moment, de l'endroit et du dispositif utilisé — nous devons veiller à ce que notre architecture API puisse prendre en charge une telle demande. Nous appelons ces paramètres les informations de contexte. Ces paramètres de contexte désignent toute information pouvant être utilisée pour caractériser la situation d'une entité. Une entité est une personne, un lieu ou un objet que l'on considère comme appropriée dans l'interaction entre l'utilisateur et les applications (Dey et Abowd). Votre application se sert de différents types de contexte comme le lieu, la météo, l'activité de l'utilisateur, les données de capteur et les balises à proximité afin de mieux comprendre les situations actuelles des utilisateurs et d'utiliser ces informations pour offrir des expériences personnalisées et optimisées.
Expérience utilisateur personnalisée
L'utilisation des informations contextuelles liées aux utilisateurs et aux dispositifs peut entraîner une réduction des interactions entretenues par les clients afin de profiter d'une expérience personnalisée. Le matériel de capteur utilisé pour collecter les informations contextuelles est hautement disponible. Les données de bas niveau telles que l'emplacement physique, l'heure et le rythme cardiaque peuvent être utilisées pour déduire des informations contextuelles de haut niveau comme des situations, par exemple « jogging matinal dans le parc ». L'expérience utilisateur des applications, qui dépend des informations contextuelles, peut être largement améliorée par l'envoi automatique des informations contextuelles, dérivées des données de capteur, à ces applications. Ainsi, intégrer l'internet des objets (Internet of Things, IoT) à la solution d'architecture d'une entreprise connectée présente un intérêt évident.
Le paradigme de conception le plus approprié qui mène à ce genre d'architectures est l'orientation du service. Les services sont des blocs de construction de la plate-forme informatique orientée services, chacun exécutant une tâche spécifique et étant accessible par des protocoles et interfaces standard. Les applications sont formées par la composition et la recomposition des services à partir de l'inventaire de service présent au sein du domaine d'activité. L'objectif principal est d'identifier les services qui sont déployés une seule fois et utilisés par plusieurs applications et ceux qui offrent des capacités réutilisables. Il en va de même pour les API dont les fournisseurs API cherchent une réutilisation maximisée de leur API.
Nous pouvons constater que les deux paradigmes — l'informatique de contexte et l'orientation du service — sont complémentaires et utiles l'un à l'autre. Un système sensible au contexte a besoin de récupérer des informations à partir de plusieurs sources. Les services servant à synthétiser les données de capteur brutes sont les meilleures options pour fournir des informations contextuelles aux autres parties du système sensible au contexte. En revanche, les inventaires de service peuvent profiter des informations contextuelles pour améliorer la qualité des résultats de recherche et pouvoir offrir un comportement hautement personnalisé au client des services. Le processus de découverte de service peut tirer profit des informations contextuelles puisqu'il peut offrir le service ou l'API le/la plus pertinent(e) à utiliser dans des environnements d'utilisation en constante évolution.
Les paradigmes tels que l'orientation du service, la gestion des API et le contexte demanderont des technologies supplémentaires pour permettre aux systèmes d'élaborer des compositions de service plus automatisées. L'implication d'un designer ou d'un concepteur en sera donc réduite (liaison [runtime] tardive). Par conséquent, nous avons besoin d'une description des services, de dispositifs IoT et éventuellement de données dans un format qui peut être traité par le système lui-même, sans intervention humaine (designer). Cette description sera créée à l'aide de technologies web sémantiques. Sur la base de ces descriptions, le système peut découvrir les éléments nécessaires pouvant réaliser la requête donnée du client de manière (semi-)automatique.
D'un clin d'œil
L'image ci-dessous traduit le message principal de cet article. L'information concernant l'environnement dans lequel le système évolue est mesurée à l'aide de toutes sortes d'entrées. Le système traduit cette information en connaissance afin d'adapter son comportement, ce qui donne une expérience plus personnalisée à nos clients et nos partenaires.
Dans mon prochain article, j'aborderai ces descriptions en détail et vous expliquerai comment elles pourront être utilisées dans l'architecture. Realdolmen vous propose certains de ces éléments (cf. SEE4SOA) pour votre architecture. Ils tiennent compte de certains aspects vous permettant de vous concentrer sur la logique opérationnelle des services et des API plutôt que sur les éléments sous-jacents qui soutiennent la vision de l'entreprise en ce qui concerne la connexion.
Johan Kumps, Solution Architect. Pour plus d'information sur ce thème vous pouvez me conatcer parJohan.Kumps@realdomen.com.
Vous souhaitez recevoir plus d'informations sur la façon de devenir une connected company ? Veuillez contacter notre expert Roel De Cuyper, Division Manager The Connected Company via roel.decuyper@realdolmen.com.
Vous voulez en apprendre plus sur les connected companies ? Veuillez lire les blogs précédents :
Devenez une connected company avec ces dix principes
Proximus et IoT : une histoire de 'getting there together'
La blockchain est bien plus qu'une devise numérique. Quelques applications qui sont dès à présent possibles
CoZo devient mobile
PSD2 : un défi se transforme en opportunité avec Secured Runtime