Et si le client n’était que la partie visible de l’iceberg ? Pour tous les “transformers” digitaux des entreprises, l’objectif est de mieux connaître les clients. Imaginez cependant que vos clients vous écartent de votre véritable objectif : maîtriser la totalité de votre patrimoine de données.
Priorité client ne signifie pas priorité SI client
Les métiers expriment le besoin de mieux connaître les clients. Le premier réflexe est donc de lancer des projets sur les outils permettant de travailler étroitement avec les clients. Par SI orienté Client, nous entendons ainsi parler par exemple de CRM, Data lake client, DMP. La priorité est ainsi souvent donnée aux outils centrés sur la relation client et centrés sur les métiers en contact quotidien avec les clients.
Vous faites cependant face à des changements rapides du marché et à la transformation des habitudes des clients, liés aux opportunités du digital. L’évolution du seul SI client ne répondra pas à ces changements. L’approche client ne doit donc pas être uniquement synonyme d’évolution du SI client : elle doit piloter l’analyse de l’évolution du SI au travers de l’évolution des attentes des clients.
Connaître les attentes des clients avant tout
Prenons quelques exemples pour démontrer que bien connaître les attentes des clients permettra d’avoir le socle de votre transformation.
Le premier exemple concerne la confidentialité des données. Garantir la confidentialité et être transparent avec les clients, sont des sujets qui vont révolutionner la relation avec les clients. “Aujourd’hui 54% ¹ de la “GenTech” (génération Z) s’inquiètent quant à l’accès qu’ont les organisations à leurs données”. Les entreprises devront garantir et prouver à cette génération (les futurs clients) qu’ils répondent à la réglementation qui se développe sur le sujet.
Le deuxième exemple concerne le parcours d’un client qui cherche une assurance habitation. Suite à un ciblage et à une campagne par e-mail il est informé d’une toute nouvelle assurance habitation. Il ne donnera pas suite cependant car il n’a pas trouvé les informations détaillées sur la nouvelle assurance. Le parcours client ne comprend plus uniquement le fait de communiquer et de fournir un prix : il s’agit aussi de mettre à disposition les caractéristiques détaillées des produits pour faciliter l’acte d’achat.
Le dernier exemple concerne la disponibilité produit. Selon une étude PwC, “85% ² des enseignes françaises déclarent générer des revenus sur plusieurs canaux”. Cependant les clients souhaitent connaître la disponibilité d’un produit peu importe le canal. Intégrer tous les points de vente dans vos stocks est la réponse qu’attendent dorénavant les clients.
Ces quelques exemples montrent qu’il est primordial d’avoir une vision à 360° des attentes des clients pour capter l’exhaustivité des besoins. Cette exhaustivité est le socle pour opérer votre transformation. Comment alors ensuite construire ce socle? Le plus sûr chemin pour y parvenir est de travailler à l’échelle de vos données.
La capillarité des données, base de la Transformation
La donnée est présente dans tous les processus, en contact ou non avec le client. C’est la capillarité des données. Pour répondre à l’ensemble des attentes des clients, il faut donc préférer travailler les données au travers de leurs utilisations.
Ainsi par ricochet, de nombreux sujets SI transverses seront adressés grâce à la capillarité des données. Collecter les données, créer des référentiels, mettre en place une gouvernance pour garantir la mise en qualité des données, garantir des informations en temps réel, connaître l’état d’avancement de processus, sont des sujets transverses à adresser dont tous les clients bénéficieront.
La capillarité des données oblige en effet à se concentrer la maîtrise du patrimoine de données. L’analyse des attentes des clients au travers des données, va donc petit à petit faire émerger le SI permettant de maîtriser ces données : un SI Data Centric.
Être data centric est pérenne
Les bénéfices d’un SI Data Centric sont de construire un SI agile, évolutif et pérenne.
Définir au travers d’une approche “données” des principes de gouvernance et de mise en qualité, oblige à avoir des architectures SI orientées données, basées sur des “piliers SI” tels que les référentiels, les échanges, les outils de qualité de données et les workflows.
Cette transformation sera durable tout en étant évolutive. Peu importe le besoin, le référentiel client alimente les systèmes liés à ce besoin. De même, les outils de qualité sauront s’adapter à tous les sujets business. Pour finir, l’approche API, conçue à partir de vos données, des besoins, et s’appuyant sur une conception fonctionnelle transverse à votre entreprise, sera aussi un outil robuste face aux changements des habitudes de vos clients.
A chaque nouveau besoin, vous enrichirez un de ces “piliers SI”. Chacun vous sollicite et profite de l’approche et de la capillarité des données. L’effet en est ainsi démultiplié avec l’accumulation des projets.
Il reste cependant à savoir si vous avez la capacité à définir votre approche par les données et à mettre en place ces “piliers SI”.
L’expert en vaut la chandelle
De la collecte à la mise à disposition des données, les “piliers SI” doivent garantir la bonne gestion des données et permettre de mieux satisfaire les clients. L’enjeu business est donc important.
Pour cela, des experts sur les SI Data Centric sont indispensables. L’expertise garantit d’optimiser les coûts et les plannings de construction du SI Data Centric autour des “piliers SI”. D’ailleurs, maintenant qu’il est établit qu’un SI répondant aux besoins clients est un SI Data Centric, quels sont les “piliers SI” à construire ?
Le phénomène d’API GraphQL est en progression, aujourd’hui sommes-nous prêts à abandonner à nouveau tout ce qui a été fait sur les API ces 15 dernières années et passer à un nouveau concept d’intégration ? Le GraphQL est-il une option viable pour remplacer l’API telle que nous l’avons définie jusqu’à aujourd’hui ?
Qu’est ce que le graphql ?
Le GraphQL se résume par la mise à disposition d’une interface de requêtage qui s’appuie sur les mêmes technologies d’intégration utilisées par les API REST. Nous allons toujours passer par le protocole HTTP et par un payload de retour, préférablement au format JSON, mais la différence pour le client repose sur le contrat d’interface.
Si nous essayons de vulgariser, les réponses apportées par le REST et le GraphQL à la même question sont fondamentalement différentes.
Analysons la question suivante : qui es-tu ?
Voici comment elle serait abordée par Rest et par le GraphQL
Le REST :
QUESTION : qui es-tu ?
REPONSE : voici ma pièce d’identité (ni plus, ni moins)
Le GraphQL
QUESTION : quels sont ton nom, prénom, date de naissance, adresse de résidence, lieu de travail et tes coordonnées personnelles ?
RÉPONSE : voici toutes ces informations ciblés (et tu peux avoir encore plus de détails si tu veux, en une seule fois)
On a affaire ici à un changement radical dans la manière d’aborder les requêtes.
La DATA reste l’élément central de la réflexion autour du GraphQL. Sur ce point, nous pouvons voir l’héritage venant des paradigmes du REST, avec une focalisation sur la ressource. Alors que les pratiques précédentes, comme le SOAP, étaient plus axées “action”, le GraphQL est très axé sur la DATA, l’objectif primaire étant la manipulation de la donnée et pas l’exécution d’une opération.
Le concept de DATA est cependant présenté différemment. Elle n’est pas contrainte par une structure strictement définie à l’avance mais il est désormais possible de la naviguer par l’API GraphQL, ce qui change complètement le concept du contrat d’interface.
Il n’y a donc plus de contrat d’interface ?
Nous pourrions en déduire que le contrat d’interface, très cher aux démarches SOAP et REST, n’est plus d’actualité pour le GraphQL…
Notre vision se résume en une simple phrase : ”Le contrat d’interface change de forme. Il n’est plus centré sur la structure de l’information retournée par l’API mais s’intéresse au modèle de données lui-même”
Le contrat d’interface s’appuie sur le modèle de données qui devient encore plus crucial puisqu’il est maintenant directement exposé / connu par les clients de l’API. Pour rappel, nous avons défini le GraphQL comme un langage de requêtage qui s’appuie sur la structure de la donnée définie dans notre schéma de modélisation. Bien qu’une couche d’abstraction ne soit pas totalement à exclure, le modèle de données, défini dans nos bases de données et exposé aux clients (par introspection ou connaissance directe), devient le point de départ de toute requête.
Cela saute aux yeux, la flexibilité est le grand avantage apporté par le GraphQL. Nous ne sommes plus contraints par le retour de données défini par le fournisseur de l’API mais uniquement par la donnée qui nous est mise à disposition. Cela permet de réduire le phénomène de l’underfetching (obligation d’utiliser plusieurs appels car un seul ne permet pas de remonter la totalité des informations nécessaires) et de l’overfetching (récupération de plus de données par rapport au besoin réel), vrais casse-têtes lors de la conception des APIs.
L’autre vrai avantage est la rapidité de mise en œuvre. Sans vouloir rentrer dans la réalisation, la mise à disposition d’une API classique a toujours comporté des longues périodes de réflexion sur le périmètre, le découpage, la profondeur des données retournées. Ces phases de réflexion qui, sans un besoin clair en face, avaient tendance à se prolonger et à réduire le Time-To-Market des APIs. GraphQL permet de pallier ces problèmes :
En libérant le fournisseur de l’API de cette lourde tâche de conception,
En évitant la multiplication des APIs sur le même périmètre,
En facilitant le choix du périmètre de la part du consommateur, sans qu’il soit forcément obligé d’orchestrer plusieurs requêtes afin obtenir ce dont il a besoin, sans limites théoriques.
…mais aussi des contraintes
La liberté donnée au client de l’API est certainement un avantage pour les deux parties mais apporte également des contraintes de sécurisation et de gestion de la charge serveur.
La charge
Une API, REST ou SOAP, est globalement maîtrisée. Elle a un périmètre bien défini et donc la seule question à se poser porte sur la volumétrie et/ou la fréquence d’appel. Le GraphQL, par le fait que les requêtes sont variables, réduit la prévisibilité de la charge associée :
La non-prédictibilité des requêtes expose au risque de retours complexes et volumineux, sans pagination, ce qui pourrait mettre en difficulté une infrastructure mal dimensionnée ;
L’utilisation du cache est complètement révolutionnée / complexifiée, car la probabilité d’avoir la même requête de deux différents consommateurs est très faible et ne permet donc pas de s’appuyer complètement sur le cache pour décharger les machines.
La sécurité
Dans l’ancienne conception nous pouvions avoir des niveaux de sécurité induits par le périmètre restreint de l’API.
Le GraphQL, de par la liberté d’exploration des données, oblige à une réflexion plus profonde sur la question des habilitations et de l’accès aux informations. Cette sécurisation doit être garantie par une sorte de “douane” qui se définie comme la couche par laquelle nous devons transiter pour accéder aux données, et qui gère directement les droits d’accès par utilisateur.
Cette pratique n’est pas nouvelle, elle devrait accompagner toute démarche API, toutes technologies confondues. La couche de sécurisation et d’habilitations devrait toujours être indépendante de l’exposition de l’API. Parfois, un défaut de conception non identifié de cette couche de sécurité était pallié, tant bien que mal, par la limitation de périmètre imposé par l’API or cette limitation n’existe plus avec le GraphQL.
Conclusion
GraphQL représente la tentative la plus intéressante de “flexibiliser” la gestion des APIs et apporte une nouvelle dynamique à celle-ci, tout en respectant les contraintes induites par ce mode d’intégration.
Si l’objectif n’est pas forcément de “tout casser”, pour recommencer tout en GraphQL, cette approche devient une alternative concrète aux démarches API dites “classiques”.Exemple en est la mise en application de cette méthode d’intégration sur une plateforme de paiement, Braintree, filiale de Paypal.
Le marché du Serverless ou FaaS a bondi de manière importante en 2018, porté entre autres par la popularité grandissante de AWS Lambda, Azure Functions ou de Google Cloud Functions. Mais en quoi consiste une architecture Serverless ? Cela consiste à exécuter des fonctions sur le cloud sans se soucier de la conception de l’architecture technique et du provisionnement de serveurs. La facturation de ce type de service étant basée sur le temps que le traitement aura mis pour s’exécuter. Il y a donc toujours besoin de serveurs mais la conception et la gestion de ceux-ci sera réalisée à 100% par le fournisseur Cloud.
La différence avec une architecture basée sur des containers ?
La containérisation reprend les concepts de la virtualisation mais ajoute de la souplesse.
Un container est un sous-système pré-configuré par le biais d’une image. Celle-ci définit ce que le conteneur embarque à sa création (serveur d’application, application, etc.), normalement le minimum indispensable pour votre application (fonction ou micro-service).
Le Serverless est une architecture qui repose sur un concept simple : l’abstraction complète des ressources machine.
Il vous suffira par exemple d’avoir un compte AWS, cliquer “Create function” depuis la console, configurer quelques paramètres techniques comme la taille de la mémoire allouée et le temps de timeout maximum toléré, copier votre code et voilà !
Avantages et inconvénients
Le principal avantage de ce type d’architecture est le coût. Vous ne paierez que ce vous utiliserez basé sur des métriques à la seconde. Plus besoin de louer des ressources comme des machines virtuelles que vous n’utilisiez jamais à 100% ou de payer un nombre d’utilisateurs qui n’étaient pas connectés en permanence dans l’outil. Par exemple pour une fonction AWS Lambda à laquelle vous aurez attribué 128 Mo de mémoire et que vous prévoyez d’exécuter 30 millions de fois en un mois (pour une durée de 200 ms par exécution), vos frais ne seront que 10€/mois environ ! Si cela correspond à un pic saisonnier atteint en période de solde et que la moyenne d’exécution correspondra à la moitié de cette charge vous ne paierez que ce que vous aurez consommé. À titre de comparaison, un serveur virtuel de 1 coeur et 2 Go de RAM facturé au mois sera facturé 12€/mois, peu importe la charge. Et si un serveur de ce type ne suffisait pas, il faudra prévoir le coût d’une plus grosse instance ou d’une deuxième. Il est donc évident que le FaaS permet d’optimiser vos coûts par rapport à du IaaS ou du PaaS.
Le second avantage est qu’il n’y a pas besoin de gérer et maintenir l’infrastructure. Vous n’arrivez pas sur vos projets Agiles à anticiper vos besoins d’infrastructure ? Vous pensez qu’attendre 1 jour pour avoir une machine virtuelle c’est encore trop long ? Vous trouvez bien le principe des microservices mais vous trouvez compliqué de gérer une architecture technique distribuée ? Une architecture Serverless ou FaaS vous simplifiera la vie de ce point de vue.
Il y a cependant des désavantages. Les AWS Lambda et Azure Functions sont des technologies propriétaires qui vous rendront complètement dépendant de votre fournisseur. Si un jour vous désirez migrer sur une autre plateforme, il vous faudra revoir le code de votre application notamment si celui-ci fait appel à des services ou infrastructure propre à ce fournisseur (lire un fichier dans un container S3 par exemple ne sera pas de la même façon que de le lire sur un Azure Blob). L’autre point important aussi à surveiller est que ces services sont bridés en termes de ressources et ne conviendront donc pas pour des applications nécessitant des performances élevées.
Pour quels cas d’usage ?
Une architecture Serverless peut convenir lorsque les critères suivants sont réunis :
Cela peut être par exemple :
Le lancement d’une requête comme l’appel d’une API pour récupérer les données de météo et les déposer dans la base de données utilisée par une application mobile.
L’envoi de notification par messagerie pour prévenir un groupe d’utilisateurs d’un événement.
Le transfert et la vérification du format de fichiers multimédias pour un site permettant à des photographes de partager leur travail.
En résumé, il s’agit d’une nouvelle façon de concevoir votre architecture solution, pouvant vous permettre de réaliser des économies importantes mais qui vous rendra plus dépendant du fournisseur Cloud que vous aurez retenu.
Après notre panorama 360° sur l’IoT dans notre précédente série de publications, nous entrons comme promis dans une nouvelle série d’articles plus opérationnelle pour accompagner vos premiers pas dans le monde de l’IoT.
Aujourd’hui, nous vous proposons d’incarner un(e) responsable Digital, néophyte sur les sujets IoT, faisant face à l’émergence interne de cas d’usage métier sans réponse :
Automatiser le réapprovisionnement de clients B2B en consommables (bouteilles de gaz/oxygène…) sur la base de leur consommation réelle et prédictive,
Suivre l’envoi de marchandise de bout en bout : de la fabrication à la réception par le client.
Afin de booster la transformation métier, notre responsable (oui c’est bien vous) se donne pour objectif de rapidement expérimenter une gamme de services basés sur le traitement de données terrain récoltées par des objets IoT.
Le hic ?
Cette entreprise ne dispose d’aucune connaissance ou compétence dans le domaine de l’IoT. Il s’agit ici de leurs premiers cas d’usage sur ces technologies. Autant dire que notre responsable digital est plutôt perdu(e) à ce stade et ne sait pas réellement par quel bout traiter la demande : comment partager les responsabilités entre IT et Métier ? Quels sont les maillons d’une chaîne IoT ? Make or Buy ? Comment concevoir l’objet connecté ? …
Rassurez-vous, cher(e) responsable digital, nous sommes ici pour répondre à vos interrogations et vous guider dans la réalisation de ce challenge.
Principe #1 : Rester “business focus” en réalisant un proof of value (pov) de quelques semaines
L’IoT, au delà de sa dimension technique, doit avant tout répondre à un enjeu business.
Une phase d’idéation avec le métier est nécessaire pour détourer le cas d’usage et affiner la valeur métier recherchée pour soi et/ou pour ses clients.
Le but premier de cette démarche est de se focaliser sur les éléments à valeur probante et d’occulter temporairement toutes les problématiques techniques. Nous ne visons pas ici l’industrialisation … nous visons uniquement l’expérimentation ciblée, la démonstration de la valeur par l’exemple.
Aussi nous nous focaliserons davantage sur les questions de fond :
Quel est l’existant (processus, équipements, données…) à intégrer ?
Qui est le client final ?
Quelle est l’objectif recherché et la valeur à atteindre ?
Quelle(s) donnée(s) dois-je récupérer / exposer pour y arriver ?
… Plutôt que sur les détails :
Quelles sont toutes les contraintes : environnement, connectivité, form factor, …
Principe #2 : Utiliser les accélérateurs du marché … miser sur l’IoT-as-a-service
La chaîne IoT (objet, connectivité, plateforme IoT, SI entreprise) est longue, complexe et varie en fonction des cas d’usage adressés et de leurs contraintes.
Notre responsable Digital en a eu le vertige !
Start slow…
Comme mentionné précédemment, la phase de PoV ne doit pas s’attarder sur toutes les considérations techniques :
L’objet : concevoir un prototype simple qui sait capter et transmettre des informations. Soit à base de capteurs existants sur le marché … soit en réalisant son propre objet connecté en “une demie journée” : littlebits, raspberry / arduino et la diversité des sondes sont vos amis. Ne vous préoccupez pas à ce stade de la puissance, du form factor à respecter, de l’autonomie ou des enjeux de sécurité.
La connectivité : restreindre son choix à un seul réseau (que ce soit le LPWAN, un protocole domotique ou directement le WiFi) simple à mettre en oeuvre pour vous. Ne cherchez pas à pouvoir fonctionner en mode dégradé / en mode déconnecté / à switcher sur un réseau secondaire si le primaire est indisponible.
La plateforme : utiliser les offres As-A-Service sur étagère, notamment celles des Cloud Providers. Ces offres ont l’avantage d’être déployables en quelques clics, d’être à l’état de l’art, d’être potentiellement gratuite (free tiers) pour faire un PoC. Exemples : AWS IoT Core, Azure IoT et Azure IoT Central, GCP Cloud IoT, …
SI Enterprise : ne pas chercher tout de suite à propager les données IoT dans les méandres de votre SI. Misez plutôt sur les capacités de restitution intégrées à votre plateforme IoT, elles seront suffisantes pour montrer la valeur générée..
… fast PoV !
Principe #3 : Capitaliser aussi bien sur le succès que sur l’échec des PoV
Comme dans tout bon projet SI, que ce premier PoV soit un succès ou un échec, il faudra capitaliser dessus. L’échec est riche d’enseignements et il faut savoir rebondir : “Le projet est mort … Vive le projet”.
Un diagnostic post-mortem vous permettra de prendre du recul sur les activités menées :
Est-ce que le cas d’usage a bien été défini ? Quel questionnement rajouter en phase de cadrage pour être plus pertinent et percutant ?
Quelles ont été les facilités et les difficultés de mise en oeuvre ?
Quelles compétences nous manque-t-il ?
Comment mieux faire la prochaine fois ?
Le premier objectif est de mettre en lumière la démarche réalisée, les conclusions et la valeur apportée pour rayonner ensuite auprès des autres Métiers et les embarquer dans une spirale vertueuse : Fast PoV UC#1 -> Amélioration continue -> Fast PoV UC#2 -> …
Le second objectif, au fil des itérations, sera de fédérer plus large, d’onboarder d’autres Métiers et disposer d’un sponsorship fort afin de créer une Gouvernance IoT à l’échelle de l’Entreprise…
Pour aller plus loin : Le passage à l’industrialisation et la mise en place d’une gouvernance IoT
Félicitations ! Vous avez pu mener à bien plusieurs expérimentations IoT à forte valeur sur des cas d’usages divers et variés, si bien que les sollicitations ne cessent d’arriver !
C’est le moment de passer au niveau supérieur ! Vers l’industrialisation de l’IoT et au delà, la mise en place d’une gouvernance d’entreprise.
Cette étape importante n’en est pas moins complexe tant dans son appréhension et sa préparation que sa mise en œuvre.
Rassurez-vous, nous vous accompagnerons également dans cette démarche lors de nos prochains articles dédiés à ces sujets ! Stay tuned !
Dans un précédent article, nous vous présentions le dernier né des plateformes d’intégration : l’iPaaS. Cette solution s’ajoute à une liste déjà longue comme le bras.
#Batch, #MFT, #ETL, #EAI, #ESB, #EDI, #API, #MOM, #iPaaS … que faire en 2019 dans cette jungle de solutions d’intermédiation ?
Les exigences Business (innovation, écosystème d’affaire, Time To Market, instantanéité de la donnée, …) poussent l’IT à se dépasser en traitant des problématiques d’intégration de plus en plus complexes. Et cela va crescendo le temps passant. Gartner présage même une très forte augmentation (+50%) du marché de l’intégration sur les 5 prochaines années.
Malgré les efforts déployés, l’organisation IT ne permet pas toujours de répondre dans le temps imparti aux besoins du métier. A défaut d’avoir une offre d’intégration Self-Service orientée Citizen Integrator (profil non expert souhaitant réaliser des intégrations simples), ces derniers passent du côté obscur du Shadow IT.
Fort de ces constats, les cabinets d’analyste remettent les compteurs à zéro et recommandent d’adopter une stratégie d’Hybrid Integration Platform (HIP).
Kézako ? Sur quelles solutions miser pour couvrir tous ses besoins d’intégration tout en ayant un objectif de rationalisation ? Comment les décliner dans son organisation ?
Rappel des nouvelles contraintes d’intermédiation
Vente, gestion des stocks, publicités ciblées, connaissance client, campagne marketing, […] … tous les processusmétier (front, middle ou back) doivent être gérés au cordeau (en qualité, en rapidité, au bon moment, …) pour qu’au bout du bout l’expérience client soit sans couture.
Pour cela, l’heure est à la Data : Data centric, cold/hot Data, Data stream, Data processor, Data privacy… de la Data en veux-tu en voilà. La Data en tant que FUEL pour l’Entreprise. Aliment de base qu’il faut capter, qualifier, transformer, raffiner, normaliser, enrichir et transporter vers tous les organes du SI.
Ce dernier point est primordial. Nul doute que le métier boudera si vous n’avez pas les bons outils pour traiter, transporter et mettre à disposition la donnée, aussi qualitative puisse-t-elle être.
Il est presque révolu (enfin sur le papier, car il en existe encore beaucoup dans le SI des entreprises) le temps du gros batch de nuit qui tourne à 5h en fin de plan de PROD pour synchroniser les données dans tous les applicatifs monolithiques on-premise des domaines métiers.
De nos jours :
Le Cloud s’impose et contribue à distribuer les SI,
L’Event Driven Architecture est désormais reine dans l’art de propager la donnée fraîche à qui veut bien la consommer,
L’IoT contribue à l’explosion du volume des données, à l’hyper personnalisation de l’expérience client et impose de savoir ingérer, traiter, actionner et partager de l’information en quasi temps réel,
Les API REST sont la base pour offrir des prises d’accès simplifiées et sécurisées au SI ultra bunkerisés,
# …
Malheureusement, la plateforme d’intermédiation centrale unifiée qui saurait tout bien faire à 100% n’est pas encore née !
Qu’à celà ne tienne …
… Un brin de Transformation, un zest de Pub/Sub … ou l’importance de séparer les capacités d’intermédiation pour faire son propre cocktail d’Hybrid Integration Platform
Vous l’avez compris…
Tout n’est pas synchrone, tout n’est pas asynchrone,
Tout n’est pas fichier, tout n’est pas service, tout n’est pas message,
Tout n’est pas normalisé, tout n’est pas au format SAP,
Tout n’est pas disponible sur le même plan d’adressage IP,
Tout n’est pas privé et tout ne doit pas être exposé au grand public,
Tout ne fait pas 5 octets, tout ne fait pas 4Go,
…
… En fonction de son SI et de ses besoins passés, présents et futurs, il convient d’identifier les fonctions d’intermédiation nécessaires et suffisantes pour couvrir tous les cas d’usages Data.
Une fois cette cartographie détaillée établie, il convient d’analyser quel puzzle de solutions de Data Integration du marché est le plus optimum pour couvrir tous vos besoins en évitant les redondances fonctionnelles et les surcoûts associés.
Pour certains, un couple “iPaaS + API” suffira, pour d’autres ça sera “MOM + API”, il n’y a pas de règles prédéfinies à l’avance…
Cependant le tiercé gagnant selon nous…
Notre recette Data Integration jeunesse et vitalité serait :
#Un socle MOM d’Entreprise pour gérer tous les échanges internes asynchrones orientés messages qui prennent une place prépondérante dans les nouvelles architectures (Pub/Sub, Fan-Out, CQRS, …). Dans l’idéal la solution retenue sera de type Event Mesh pour créer un réseau de broker distribué au plus près des applications.
# Un socle API Management d’Entreprise pour gérer l’exposition (privé, public) de vos services et ressources métiers. Au menu du cycle de vie d’une API: conception, documentation, exposition, sécurisation, gestion des versions, gestion des quota, facturation, catalogue des API, animation d’une communauté privé / publique.
# Un socle iPaaS d’Entreprise pour tout le reste : échange avec l’extérieur, échange Cloud2Cloud, besoin de transformer, nécessité de composer ou d’orchestrer des processus… l’iPaaS fait des miracles (consulter notre article sur le sujet).
Cependant, la Rolls-Royce des plateformes sans Pilote (gouvernance, centre d’excellence) ne vous mènera pas au nirvana de la Data Integration.
Remettre la DSI devant ses responsabilités et ses engagements d’agilité (T2M) vis-à-vis des métiers
Nous avons tendance à accorder beaucoup de place aux Appels d’Offres solutions, à leur couverture fonctionnelle et non fonctionnelle … mais trop peu de temps et d’énergie à la gouvernance et à la gestion des compétences autour de celles-ci.
Quelle erreur… à laquelle la vision stratégique Hybrid Integration Platform compte bien remédier.
Une fois les différentes pièces techniques du Puzzle Data Integration assemblées, pour dévoiler tout son potentiel ce dernier à besoin :
# D’un Centre d’Excellence composé d’un pilote unique, de MOA, d’architectes, d’experts de l’intégration, du développement et de la production. Son rôle sera de veiller au bon fonctionnement de la plateforme, veiller à son MCO, créer des patterns d’intégration et autres composants réutilisables sur étagère, accompagner les domaines métiers, …
# Des métiers eux mêmes qui pourront utiliser les outils orientés Citizen Integrator pour soit réutiliser les composants d’intégration validés en central soit créer rapidement leurs propres processus d’intégration et les mettre en production sous réserve d’approbation par qui de droit.
La stratégie Hybrid Integration Platform vise à créer une plateforme d’intégration unique et sur mesure à votre contexte tant sur le plan technologique que sur le plan organisationnel.
La performance de l’ensemble n’étant viable que si les bonnes fonctionnalités d’intermédiations ont été sélectionnées et intégrées dans un tout cohérent, avec le bon niveau de Gouvernance en central et dans les différents Domaines Métiers.
Dans notre précédent article, nous avons introduit l’Internet Of Things (IoT) et ses cas d’applications phares.
Les quelques lignes ci-dessous vous dressent un portrait de la chaîne IoT et de ses acteurs. Historiquement plutôt réservé à un marché de niche exploité par un écosystème de startups, le marché de l’IoT est en complète effervescence depuis plusieurs années.
Pour y regarder de plus près, prenons chacun des trois grands segments principaux qui le compose.
Les objets connectés
Le marché des objets connectés pour les particuliers est dominé par les startups qui ont su tirer profit de l’IoT dès ses premiers pas. Nous citerons par exemple des acteurs tels que NETATMO, FITBIT, NEST (racheté par Google en 2014) ou encore Withings.
Pour le marché professionnel, on distingue les acteurs historiques du #M2M (Machine to Machine) tels que LeGrand ou Schneider Electric qui ont vu en l’IoT une opportunité de compléter leurs positionnement et se rapprocher encore plus de leurs clients. Mais aussi, des acteurs industriels spécialisés dans le développement et la distributions de capteurs et puces IoT tels que Bosch, Samsung ou encore Siemens.
La connectivité
Sur le volet de la connectivité, le marché est tout aussi divisé, vous vous en doutiez, non ?
D’un côté les réseaux à faible consommation spécialisés pour les besoins IoT nommées #LPWAN (Low Power Wide Area Network) avec deux acteurs ou plutôt deux technologies qui sont massivement déployées sur le marché : Sigfox et LoRa.
#Sigfox, opérateur télécom français crée en 2014 et qui propose sa propre technologie propriétaire.
#LoRa, une modulation des ondes radio open source exploitable par toute entreprise dès lors qu’elle achète des puces de communications LoRa rattaché au réseau #LoRaWan distribué au travers de l’ “#Alliance LoRa”. Cette technologie est exploitée par les grands opérateurs historiques, en particulier Orange et Bouygues Telecom.
De l’autre, les technologies télécom classiques mobiles 2, 3, 4 et bientôt 5G, les réseaux domotiques comme #Zigbee ou #Wave ou encore l’infrarouge, le bluetooth, le Wifi etc.
Nous aurons tout le loisir de détailler les technologies citées et bien d’autres dans notre prochain article dédié à la #Connectivité IoT.
Les plateformes IoT
Le marché des plateformes IoT est certainement celui qui est le plus vaste en terme de représentation et de typologies d’offres différentes.
Quel est le rôle d’une plateforme IoT ? Quelles fonctionnalités critiques doit-elle adresser ?
Domaines d’expertises critiques portés par la plateforme IoT :
Authentification et gestion des objets connectés : authentification et gestion des habilitations, appairage et révocation, supervision et monitoring, maintien en condition opérationnelle (mise à jour, maintenance…), référentiel des objets.
Collecte, analyse et traitement des données : ingestion du stream de données, traitement par flux / lot, historisation et premier niveau de stockage, corrélation événementielle via des règles définies, gestion de scénarios enregistrés.
Exposition des données : gestion événementielle avec des briques externes (SI legacy, plateforme Data Management…), exposition des données (API, Web Services…).
Pour appréhender le marché, divisons les offres en deux grandes familles :
Les Plateformes dites “horizontales” ou “généralistes” couvrent les besoins de manière transversale. C’est à dire, mettent à disposition des fonctions et services pouvant être déclinés sur tous (ou presque) les cas d’usages IoT. Ces plateformes deviennent très utiles lorsque l’on multiplie les cas d’usages, nombre et typologies d’objets, réseaux utilisés, points de collecte et d’exposition des données, afin d’en faciliter la gestion au quotidien (règles et processus de « device management », standards de formats de communication, APIs etc.) et permettre de conserver une cohérence globale. Dans cette catégorie, nous retrouvons tout d’abord les #Pure Players IoT. Mais également les grands acteurs #Cloud qui proposent des offres packagées et brandées IoT se basant sur leurs services managés.
Les Plateformes “verticales” disposent d’une expertise sur un secteur d’activité défini (immobilier, télémétrie, santé…). Elles jouent le rôle d’accélérateur métier fort dans l’analyse et l’exploitation des données IoT. Elles disposent par exemple d’algorithmes et de fonctions de traitement complexes pré-intégrées évitant ainsi à leur client de devoir porter ce développement en interne.
Le marché de l’IoT est en pleine effervescence, entre émergence de startups innovantes, rachats et partenariats, développement de nouvelles technologies (objets et communications), les transformations sont constantes. Le marché n’est pas mature, il n’est pas pertinent de tenter d’établir des règles préétablies applicables dans tous les cas.
Aussi, il faut repenser la démarche et rester dans un modèle au plus près des cas d’usages métier ! Dans un contexte marché dynamique, multipliant les cas d’usages, ne conviendrait-il pas de casser les conventions et de s’orienter vers une approche #multi-plateformes ?
Nous tenterons d’y voir plus clair et rentrerons plus en profondeur dans le détail des typologies d’offres, différents hébergements proposés, critères de comparaisons, typologies d’architectures et modèles opérationnels, modèles financiers et bien d’autres indicateurs déterminants dans notre article dédié aux #Plateformes IoT à venir.
Le prochain, et dernier volet de nos articles 360° sur l’IoT mettra en lumière les promesses faites par la technologie… mais nous nous attarderons surtout sur les points d’attention à ne pas négliger.
