Il y a encore aujourd’hui de nombreuses entreprises qui ne misent pas encore sur les API et qui se demandent encore comment faire. Elles se retrouvent souvent bloquées par le grand nombre de questions qui se posent à elles, ne sachant pas comment aborder ce genre de projets. Elles se retrouvent rapidement bloquées. C’est pourquoi je préconise une démarche MVP.
L’approche MVP pour un projet d’API Management
Parler d’approche MVP pour d’aussi gros projets peut surprendre. En effet, les points à soulever sont nombreux, que l’on parle de sécurité, des solutions techniques, de l’organisation, de la roadmap API ou encore de la définition de bonnes pratiques.
Mais les avantages d’une démarche MVP pour un projet d’API Management sont nombreux :
Démontrer la valeur :
En mettant en place la première API en mode MVP, il est possible de communiquer plus rapidement aux métiers ce que l’on peut désormais faire grâce aux API.
Démontrer la faisabilité :
Dans le cas de systèmes Legacy complexes, encore plus s’ils sont cloisonnés, les raisons sont nombreuses de penser qu’il sera long et compliqué de mettre en place des API. Grâce à l’existence de nombreux modèles d’architecture d’intégration (comme le CQRS), il est plus facile qu’on ne le pense de faire sauter les verrous !
Obtenir des retours d’expérience :
Plutôt que les audits SI et autres audits de maturité, qui sont longs et pas toujours pertinents, rien de tel que des REX réguliers pour faire avancer un projet d’API Management.
Prioriser les initiatives :
Grâce aux premiers retours d’expérience, il est possible de savoir quelle initiative prioriser. La gouvernance doit-elle être étudiée ? La stratégie d’intégration ? La communication interne ?
Réduire les risques :
La démarche MVP permet d’adopter une approche totalement intégrée, avec des décisions de type Go/NoGo à chaque étape. Vous courrez donc un risque réduit à sa portion la plus congrue.
Cette approche MVP peut rapidement aboutir à une première API en un mois, certes imparfaite, mais utilisable. Est-ce qu’il y aura encore des questionnements après un mois ? La réponse est évidente : c’est oui ! Et vous serez même en mesure de classer ces questionnements par ordre de priorité !
Approche MVP et grandes étapes
Une approche MVP étalée sur quatre semaines est clairement réalisable, pour peu qu’on suive les grandes étapes suivantes :
Définition du périmètre (première semaine) :
Choix d’une API candidate :
Vous allez d’abord choisir une première API en fonction de sa facilité à être instanciée et de la valeur qu’elle apportera. Visez le gain rapide !
Lister les attendus :
Plusieurs contraintes techniques, fonctionnelles et autres sont susceptibles d’être émises par les parties prenantes, qu’ils soient métier ou IT. Collectez-les !
Visioning (deuxième semaine) :
Définition de l’architecture :
Vous devez ensuite définir l’architecture cible de votre gestionnaire d’API. Une solution sur site ? dans le nuage ? L’important est de le faire rapidement. Ce n’est pas compliqué de changer le gestionnaire d’API, vous aurez le temps de le changer plus tard. Visez vite et pas cher ! Et n’oubliez pas les sujets d’authentification.
Définition de l’API :
Il vous faut ensuite définir l’API. Un travail à faire de concert avec les métiers, les développeurs et les architectes.
Validation :
Partagez enfin votre API et votre architecture avec tout le monde, pour la valider.
Construction (troisième semaine) :
Installation des composants :
Il est donc temps d’installer votre gestionnaire d’API ! N’oubliez pas, dans le cas de solution cloud, de vérifier s’il n’y a pas de contraintes de sécurité à gérer !
Développements :
Rien n’est plus simple que d’instancier une API, avec son interface. Et n’oubliez pas les sujets d’authentification (bis repetita).
L’intégration et les tests avec les systèmes consommateurs :
Bien sûr vous devez tester. Avec toutes les parties prenantes disponibles, idéalement en même temps…
Rétrospective (quatrième semaine) :
REX technique et métier :
Faites des démonstrations de votre API, avec présentation de la plateforme d’API Management. Ce faisant, vous obtiendrez des retours techniques et métiers.
Initiatives à venir à prioriser :
C’est le bon moment pour lister les prochaines initiatives. Comme les retours d’expérience viennent d’être faits, il n’est pas question de tout arrêter. Continuez !
En respectant ces étapes, vous serez en mesure de poursuivre votre programme API grâce au travail des initiatives priorisées, mais surtout, de pouvoir continuer sur votre lancée ! Et n’oubliez pas que les projets d’API Management nécessitent beaucoup de communication et d’évangélisation !
Les autres articles qui peuvent vous intéressez
L’intelligence artificielle au service de l’architecture d’entreprise
L’intelligence artificielle au service de l'architecture d'entreprise
Des bâtiments aux systèmes d’information en passant par la santé, l’intelligence artificielle joue un rôle croissant dans la transformation de l’entreprise en ouvrant de nouvelles potentialités, mais aussi de nouvelles innovations. D’autre part, l’architecture d’entreprise (AE), historiquement au cœur des transformations de l’entreprise, est particulièrement concernée par les opportunités offertes par ces nouvelles capacités, notamment pour améliorer le fonctionnement interne de l’AE. L’hybridation entre l’intelligence humaine et l’intelligence artificielle (IA) sera la clé de voûte dans la mise en œuvre des capacités de l’IA, notamment au service de la transformation de l’AE et plus globalement au service de l’entreprise.
Cette hybridation se traduit notamment par…
Cartographie et contrôles de conformité
Avec les algorithmes de Machine Learning (ML), les architectes d’entreprise ont à leur disposition une nouvelle approche de cartographie des systèmes d’information au sein de l’entreprise. En effet, ces nouvelles capacités permettent à l’architecture d’entreprise d’automatiser (via un processus d’audit automatique) la cartographie des systèmes d’information en reliant les acteurs, l’organisation, les processus métier et les données. Cette cartographie automatique a le double avantage de permettre une accélération de l’ouverture du SI via une APIsation.
Dans le même sillage, les nouvelles capacités offertes par les algorithmes de l’IA permettront d’accélérer et de simplifier l’analyse des données dans le cadre règlementaire (RGPD par exemple) mais aussi pour les dictionnaires des données. Étant donné les nouvelles méthodes de travail (plus de collaboration, méthodes agiles, …), l’architecture d’entreprise aura à évoluer vers un modèle lui permettant de s’adapter rapidement aux changements continus. Elle aura aussi pour effet de libérer les architectes des tâches chronophages liées à la création et mise à jour des référentiels.
Proposer des modèles d’architecture en utilisant l’IA
Un des fondements des algorithmes de ML est de permettre de générer des solutions imitant la distribution statistique des données qui lui sont soumises pendant la phase d’apprentissage et de se soustraire des modèles statiques. Cette capacité permettra à l’AE de pouvoir présenter plus rapidement et plus efficacement des modèles d’architecture proche des besoins et des contraintes propres à l’entreprise. Certaines entreprises sont déjà dans le secteur.
Proposer des modèles de mise en oeuvre
Reconnaissances biométriques, recommandations personnalisées, Chatbots, autant de modèles de ML largement utilisés dans différentes entreprises dans le monde, dans ce contexte hautement disruptif. L’utilisation de ces fonctionnalités a un impact majeur sur les processus standards des entreprises allant du métier à la technique. A ce titre, l’architecture d’entreprise, garante de l’harmonisation des processus et des SI, se doit de prendre en compte les impacts de l’intégration de ces technologies. De par son rôle, l’architecture d’entreprise anticipe la mise en place de ces technologies via des recommandations stratégiques.
L’architecture d’entreprise soutient les initiatives d’IA
Les initiatives IA ne sont pas simplement un ensemble d’initiatives complexes et coûteuses dans un environnement complexe, ce sont aussi des accélérateurs de la transformation des processus métiers. Du fait de sa fonction première, l’architecture d’entreprise est une alliée des initiatives IA sur ce domaine. L’architecture d’entreprise apporte la structure et la transparence nécessaires à la planification et à l’exécution de changements complexes dans un domaine aussi vaste et diversifié qu’une entreprise moderne. Une méthode pouvant servir à la mise en place d’une IA :
Identifier les éléments/capacités qui favorisent la satisfaction du client
Evaluer l’impact de l’introduction d’une solution d’IA
Planifier et gérer la mise en œuvre
Analyser le REX
Optimiser les prochaines itérations.
Conclusion
L’architecture d’entreprise a un rôle central à jouer dans l’expérimentation de futurs scénarios impliquant les algorithmes de ML. La connaissance transversale des flux de valeur, des processus, des technologies et des données de l’entreprise est un puissant vecteur de transformation et une opportunité pour toutes les entreprises. Adopter l’IA, c’est permettre à son entreprise de rester dans la course à l’innovation et pour délivrer un maximum de valeur.
Les autres articles qui peuvent vous intéresser
Rhapsodies Conseil, une relation client et du conseil (taillés) sur-mesure
Rhapsodies Conseil, une relation client et du conseil (taillés) sur-mesure
Rhapsodies Conseil est un cabinet de conseil à taille humaine et ne peut donc pas se permettre de baser son commerce sur la production de conseil en masse comme peuvent le faire des ESN classiques. Sa philosophie est donc de produire une offre « sur mesure » pour ses clients et cela se retrouve dans sa manière de faire du commerce.
Rhapsodies Conseil comme un tailleur
Le terme de « sur mesure » vient du monde de l’habillement classique pour homme. Un costume sur mesure veut dire que le patron est fait à partir des mensurations (besoins) du client et que les détails sont choisis par celui-ci.
Lorsque vous allez vous faire faire un costume sur Savile Row en Angleterre, le tailleur qui allait prendre vos mesures vous faisait parler pour bien comprendre ce qu’il vous fallait (quel type d’événement, ville / campagne, température, …). Le but de tout cela était de s’assurer que le costume réponde bien à votre besoin. Une fois cela terminé, il griffonnait le mot « BESPOKE » sur la liasse de tissu que vous aviez choisie pour la réserver et pour dire que le client avait parlé.
Le commerce chez Rhapsodies Conseil fonctionne de la même manière. Bien sûr, il nous arrive de répondre à des appels d’offres sur des besoins déjà formalisés ou de fournir un CV pour une demande d’assistance avec des compétences attendues spécifiques mais dans tous les cas, la valeur du Cabinet se situe dans sa capacité d’écoute de ses clients. Cela nous permet d’ajuster notre proposition au « juste » besoin du Client. Ce principe de frugalité a été résumé ainsi par un ancien client : “Je ne veux pas que l’on me propose une Ferrari quand j’ai besoin d’une 4L”. En d’autres termes, les facteurs limitants doivent être pris en compte lorsque l’on mène une mission de conseil (temps, budget, besoins, …).
Construire de la confiance
Quand ce dialogue se met en place, une relation de proximité avec le client peut se créer et cette proximité est nécessaire pour connaître l’objectif derrière l’objectif.
Avec votre tailleur, la confiance va vous aider à lui avouer que vous voulez apparaître plus grand, il va donc monter l’emplacement de votre cran, ou que vous voulez avoir l’air plus statutaire, il va alors élargir vos revers… Pour Rhapsodies Conseil, c’est la même chose.
Et pour construire cette confiance, cela se fait plus facilement quand la mission se passe bien mais ce n’est évidemment pas toujours le cas. Plus la relation va durer, plus la probabilité de rencontrer un obstacle augmente et, dans ce cas, il est essentiel d’assumer les erreurs qui ont pu être faites et de les réparer. Le droit à l’erreur existe mais il faut tout faire pour que cela n’arrive plus.
On peut dire que la relation est de confiance quand elle est construite sur 2 niveaux de relation : Le premier niveau est évidemment celui du consultant qui mène la prestation. C’est la qualité de sa prestation qui est la première étape (ou le premier coup de ciseaux dans le cas de notre tailleur) dans la construction de la confiance. Mais que se passe-t-il si le consultant quitte le cabinet ? Après tout, cela arrive dans une évolution de carrière, surtout quand on valorise votre travail. Et bien comme notre tailleur ne travaille pas tout seul (il y a celui qui travaille sur le patronage, celui qui coupe, celui qui confectionne, parfois vous avez un pantalonnier).
Chez Rhapsodies Conseil c’est la même chose : Un consultant n’est jamais laissé seul en mission. Il a toujours accès aux connaissances acquises par le cabinet. Un client ne consomme pas la prestation d’un consultant mais bien celle du cabinet dans son entièreté. Et cette relation passe donc également par un deuxième niveau, le manager de mission. Son rôle n’est pas que de faire le suivi du consultant mais également de prendre du recul sur la mission, échanger sur ses besoins avec le client, comprendre ses contraintes et apporter son point de vue. Quand tout cela est réussi, nous pouvons être sûr que si un des deux niveaux est défaillant, le lien n’est jamais rompu.
Une interaction biologique
Enfin, le but de chaque relation est qu’elle soit bénéfique à toutes les contreparties. Et pour que cela soit le cas, elle doit être envisagée comme un partenariat et pas uniquement comme une relation client – fournisseur. L’un apporte ses besoins, de potentiels projets à forte valeur et Rhapsodies Conseil apporte son expertise et son engagement.
Pour changer de notre analogie avec le tailleur, nous pouvons utiliser le concept biologique qui désigne un processus impliquant des échanges ou relations réciproques entre plusieurs éléments. Il y a bien évidemment un échange, qui est contractualisé, une expertise contre rémunération mais cela ne doit pas être uniquement cela. Pour le client, il faut aussi qu’il puisse intégrer une partie de cette expertise, que les connaissances dont il a besoin soient acquises par ses équipes. Pour le cabinet de conseil, l’intérêt est de confronter le consultant à des problématiques qu’il n’a jamais rencontrées auparavant (nouveau domaine d’activité, nouveau domaine fonctionnel, nouvelle technologie, …) et ainsi élargir le champ de ses compétences.
Existe-t-il une durée de relation idéale ?
Quand votre garde-robe a atteint une taille nécessaire (ce qui est propre à chacun), ou quand votre budget ne vous le permet pas, il n’est pas dans l’intérêt de votre tailleur de vous faire commander tout de suite de nouveaux vêtements. Il risque de vous lasser, de vous décevoir car vous n’avez plus d’attente, voire de vous braquer.
Si on garde le fil de notre analogie, le risque est le même dans le conseil. Il est indéniable qu’une relation à long terme avec un client est bénéfique : on le connaît de mieux en mieux et l’inverse est aussi vrai, en conséquence nous sommes de plus en plus performants collectivement. Mais une relation à long terme ne veut pas dire être toujours là mais être là quand il en a besoin. Nous disions tout à l’heure que pour qu’une mission de conseil soit une pleine réussite, il faut qu’une partie de l’expertise soit captée par le client, que le client monte en maturité sur le sujet.
Cela ne se fait pas en un claquement de doigts (ou un coup de ciseau). Il faut parfois savoir partir pour (mieux) revenir. Le risque à vouloir toujours être là est de trop s’écarter de son expertise, de ne plus justifier son budget et donc d’abîmer la confiance. La relation entre le client et Rhapsodies Conseil et la relation entre le client et le consultant ont des cycles de vie différents. Si la valeur ajoutée de la relation entre le client et le cabinet augmente avec le temps, nous estimons que la durée de vie de la relation entre le client et un consultant doit être comprise entre 1,5 et 3 ans. C’est le temps nécessaire à un consultant pour comprendre et maîtriser l’environnement du client et pour ce dernier d’en tirer les bénéfices.
Comment définir un prix ?
Comme pour toute relation commerciale (tailleur ou conseil), le prix doit correspondre à la valeur perçue pour que la confiance soit maintenue. Si vous avez l’impression de surpayer un bien ou un service, vous ne serez pas enclin à faire un deuxième achat.
Chez Rhapsodies Conseil nous proposons des prix justes, prix marché, par rapport à l’expertise fournie en regard du besoin. Nous n’essayons pas de faire le plus de marge possible au détriment du client et du collaborateur (car le client attendrait une expertise peut être supérieure à celle du collaborateur et cela le mettrait en difficulté)
En contrepartie, la marge de manœuvre pour des négociations est très faible et parfois inexistante. Il nous arrive de perdre des clients qui cherchent une baisse de prix infondée. La solution serait de faire intervenir des consultants avec une expertise insuffisante pour répondre au besoin du client et nous nous y refusons. Cela nous obligerait à baisser la qualité de service à laquelle nous tenons, au risque d’avoir des « casseroles » chez le client, or il est fondamental pour nous de maintenir la confiance.
Si le client n’a pas le budget nécessaire pour financer notre intervention, nous cherchons alors un moyen de baisser le montant total en travaillant sur la priorisation et ainsi apporter un maximum de valeur et cela le plus rapidement possible. Plutôt que de vouloir traiter 100% du spectre avec un budget insuffisant, nous préférons nous concentrer sur les 80% de fonctionnalités qui représentent souvent l’intégralité des attentes prioritaires venant du métier. Pour cela, notre expertise sur l’agilité est rentrée dans notre ADN et nous aide beaucoup dans la manière de mener nos prestations mais également dans notre commerce.
Rhapsodies Conseil commerce comme il travaille
Finalement, la vision de Rhapsodies du conseil est de ne jamais perdre de vue l’objectif dans ce que nous entreprenons. Que ce soit dans nos prestations ou dans notre commerce, le « quick win » n’est qu’un moyen pour atteindre l’objectif final et non une fin en soi. Nous ne voulons pas mettre en péril l’atteinte de cet objectif pour un contrat de plus courte durée. Votre tailleur vous accompagne au fil du temps en prenant en compte vos évolutions physiques, et Rhapsodies Conseil fait de même en prenant en compte les nouveaux défis à relever.
Je n’ai rien contre vous, mais ça va prendre trop de temps de référencer et de compléter nos applis… Vous avez une ligne d’imputation ?
Chef de projet
C’est surtout un énième référentiel qui ne sera pas tenu à jour : beaucoup d’efforts d’initialisation au départ et pas de récompense à l’arrivée !
Directeur d’un domaine applicatif
Je monterai à bord seulement si on me prouve que ça marche et que les autres ont déjà complété leur part.
Indiana Jones
Damn…
En entendant ces retours, Indiana réalise à quel point le déploiement d’un référentiel d’architecture pour son entreprise d’archéologie ne va pas être chose facile… Surtout auprès des parties prenantes qui devront se charger de compléter les informations sur leurs applications.
L’arrivée d’un référentiel des applications, quel que soit l’usage qui en est fait (Application Portfolio Management, gestion de l’obsolescence, transformation du SI…), est majoritairement vu par les équipes opérationnelles comme une contrainte, en termes de temps, et donc de budget.
Armé de son chapeau fedora d’explorateur intrépide, Indiana se lance sur les eaux sinueuses de la mise en place d’un référentiel d’architecture et de la conduite du changement auprès de ses équipes.
Nous retracerons ses péripéties à travers ce retour d’expérience : que pouvons-nous faire concrètement pour lever les freins et faciliter ainsi le changement et l’acceptation de l’outil ?
Enfilez votre meilleur pantalon cargo et chaussez des boots en cuir confortables (nota bene : vous pouvez exclure le fouet de votre attirail) et… Action !
Pour bien se dérouler, l’expédition doit être bien organisée
Première étape, Indiana part à la recherche de recrues sur lesquelles il pourra compter pour mener à bien sa quête.
La mise en place d’un référentiel d’architecture ne s’effectue pas sans un fort sponsoring de la part de la direction. Ces sponsors seront les plus pertinents pour répondre au « pourquoi » (Simon SINEK, « How great leaders inspire action »), ce fameux adverbe qui, à défaut de nous laisser coi, doit au contraire éclairer les lanternes et permettre aux intéressés comme aux sceptiques de rallier la cause. Ainsi, le directeur du Système d’Information, de l’architecture, des études, voire de la sécurité et des différents pôles applicatifs, semblent tous désignés pour accomplir ce rôle de « parrain » (sorte d’Al Pacino corporate) du projet.
Si nos sponsors semblent désignés d’office, nous aurons besoin d’aventuriers au sein de notre organisation projet, de personnes qui promeuvent la démarche et qui veulent utiliser l’outil. Ils seront de préférence opérationnels ou auront une bonne connaissance des équipes, de leurs besoins et contraintes. Ces aventuriers devront également être capables d’aller vaincre les démons de la réticence et de prendre du recul sur la situation. Ce seront des ambassadeurs du projet : des responsables d’applications, des responsables de pôles, des PMO ou autres fonctions transverses, ou même des personnes qui connaissent peut-être l’entreprise et son SI depuis plus de 20 ans… En bref, ces opérationnels seront nos yeux et nos oreilles pour les remontées terrain, afin de permettre à l’équipe projet référentiel d’architecture de répondre aux attendus et de lever le plus tôt possible les principaux freins au changement.
Armé de cette équipe solide, Indiana est prêt à débuter son expédition auprès des responsables d’applications !
Équipement approprié + capacité d’adaptation = le kit du bon aventurier
Qui dit déploiement d’un nouvel outil dit nécessairement conduite du changement auprès des populations concernées. En l’occurrence, si nous arrivons avec un outil qui est vu comme une contrainte, il sera important d’adapter nos leviers à notre public. (Mettons momentanément de côté la méthode Indiana : le fouet n’EST PAS une solution adaptée à la conduite du changement. Est-ce bien clair ?)
En revanche, il conviendra de s’équiper d’un attirail adéquat en fonction de la situation. Qui sont mes utilisateurs ? Quels sont les canaux de communication les plus adaptés ? Qu’est-ce qui fonctionne bien dans l’entreprise ? Sur quelles ressources puis-je m’appuyer ? sont autant de questions qui aideront à constituer l’équipement de l’aventurier.
Prenons l’exemple d’un kit qui a fonctionné :
des kick-off courts auprès de chaque équipe pour présenter le « pourquoi » du projet, recueillir les besoins et premiers retours et convaincre à l’aide de cas d’usage adaptés en fonction de leurs objectifs ;
des formations sur-mesure et interactives (cet accessoire indispensable est à calibrer en fonction de l’ergonomie et de la facilité d’utilisation de l’outil choisi) ;
du coaching à volonté à l’aide d’un point de contact et de support bien identifié et accessible par les utilisateurs (de ce fait, cela ne peut pas être un directeur, mais quelqu’un qui sera disponible pour les équipes) ;
une documentation abordable, pas trop longue, pour ne pas décourager les élèves, et tenue à jour pour assurer la cohérence du discours ;
des vidéos tutos pas-à-pas, avec une communication régulière, parfois légère ou informelle (via Workplace, SharePoint, mail, voire même papyrus antique).
L’une des composantes principales de la conduite du changement est la communication. L’enjeu sera d’apporter, avec pédagogie, toute la connaissance nécessaire à nos populations concernées, afin de les rendre autonomes et de les convaincre de l’utilité de la démarche. Pour cela, des formations adaptées, couplées à une communication régulière et orientée en fonction du public, seront nécessaires.
La réussite du succès : itérer
Inutile d’arriver avec un schéma de déploiement trop préconçu : avoir des principes, oui, mais rigides, non ! Ce serait le meilleur moyen pour que les utilisateurs n’adhèrent pas. Il nous faudra faire preuve de souplesse et d’agilité pour éviter les écueils et nous emparer des idoles aztèques conservées dans les temples maudits sans se faire transpercer par les flèches piégées.
Plus encore, il faudra également donner la parole à ces parties prenantes de tout horizon et les inclure dans les décisions prises autour du référentiel (nomenclatures, règles de modélisation d’une application, ses instances, ses interfaces, ses composants techniques et les informations complémentaires utiles à renseigner).
Pour faciliter l’acceptation, nous prendrons en compte les points de vue et adapterons l’expédition en fonction des imprévus, qui ne manqueront pas d’arriver (cf. Indy dans « Les Aventuriers de l’arche perdue »), mais qui permettront à coup sûr d’enrichir la portée du référentiel !
Après avoir recueilli les doléances, il sera important de trouver des solutions, de les documenter et de les généraliser auprès de tous les utilisateurs. Les équipes se sentiront plus ainsi engagées et responsabilisées, d’autant plus qu’on aura itéré avec elles sur leurs besoins.
Bien entendu, il faut savoir dire non à certaines demandes, afin de ne pas se retrouver avec une liste au Père Noël qui diluerait les objectifs premiers du référentiel.
Conclusion
Intérieur – une deuxième salle de réunion dans une Université
Responsable d’application
Ça m’a pris du temps, mais j’ai mieux compris à quoi le référentiel allait me servir : partager la carte d’identité de mon application, visualiser ses flux d’échange, anticiper l’évolution de son état de santé technique, pour faciliter les études d’impacts.
Chef de projet
Je peux dorénavant avertir les autres responsables d’application de l’arrivée d’une nouvelle application dans la cartographie et afficher les impacts sur le système d’information. Associé au travail des architectes sur la vision future de l’entreprise, le référentiel prend une vraie valeur.
Directeur d’un domaine applicatif
Je dispose à présent d’une vue exhaustive de mon périmètre et d’informations de qualité sur les applications. Je me porte garant pour assurer la maintenance dans le temps de cette cartographie afin d’en faire bénéficier toutes les parties prenantes de la direction informatique.
Indiana Jones
Is this the real life? Is this just fantasy?
The end
Comme nous le constatons en cette fin de scénario, Indiana a pu lever les réticences majeures à l’aide de sponsors investis, de cas d’usage ciblés et d’une conduite du changement adaptée aux besoins des équipes opérationnelles. L’apport d’un tiers dans la démarche, neutre et indépendant, facilite cette conduite du changement.
Un exemple de la réussite de cette phase de déploiement est d’avoir fait entrer le référentiel d’architecture en tant que « réflexe » dans les mœurs de la direction du système d’information : « As-tu vérifié ce que dit le référentiel à ce sujet ? As-tu capitalisé ton étude SI dans le référentiel ? » Une fois que c’est fait, nous pouvons entrer dans une phase de mise à jour récurrente des informations, à l’aide d’un processus adapté et de KPI pour évaluer la qualité globale du référentiel dans le temps.
De votre côté, comment vous êtes-vous frayés un chemin à travers la végétation luxuriante de l’inventaire applicatif ? Comment avez-vous organisé l’expédition et quel kit du bon aventurier vous a le plus aidé ?
Mettre en place la fonction Urbanisme/Architecture dans une Entreprise n’est jamais simple. Faut-il vraiment suivre le déroulement de méthodologies lourdes et complexes, style TOGAF ? Nous proposons une approche plus rapide et plus économique : partir d’outils déjà éprouvés, et en contrepartie, concentrer l’effort sur l’accompagnement au changement.
Démarrer une pratique d’architecture n’a rien d’une sinécure. Par où commencer ? Où dégager très vite de la valeur ajoutée ? Faut-il vraiment se lancer dans le déroulement d’une démarche méthodologique complète, mais longue et coûteuse? Notre proposition est de commencer par s’équiper d’une boîte à outils. En effet, au quotidien, l’architecte a besoin d’un petit nombre d’outils. Oui, mais lesquels ?
La contribution positive de l’architecte se démontre sur le terrain, dans sa capacité à accompagner les équipes de projet pour éclairer la voie et trouver les meilleures solutions, à la fois sur le court et sur le long terme. Pour cela, il a besoin des outils suivants:
un corpus de règles d’architecture,
un modèle fonctionnel de référence, base d’une cible d’urbanisation du système d’information,
un catalogue de normes et standards (modèles « design patterns », matériels, logiciels,…)
Sans oublier :
des cartographies qui décrivent les systèmes de l’entreprise : processus, applications,…
une procédure d’instruction de projet bien établie, avec des acteurs et des rôles bien identifiés,
un modèle de document qui décrit la ou les solutions envisagées pour le projet, et en synthétise les points-clé (objectifs, solution proposée, risques, etc…), permettant ainsi à toutes les parties prenantes de s’approprier rapidement le sujet, et de prendre une décision en toute connaissance de cause.
Passer du sur-mesure au prêt-à-porter… et vice-versa !
Comment fabriquer ces outils ? Bien sûr, on pourrait dérouler une démarche complète de développement de l’architecture, mais il est plus rapide de partir d’un corpus de bonnes pratiques déjà éprouvées, que l’on enrichira pour l’adapter aux spécificités de l’entreprise. En particulier, on constate que d’une entreprise à l’autre, une partie des règles d’architecture sont communes. Cela se comprend : il en est de même dans toutes les disciplines de construction, qu’il s’agisse de fabriquer des bâtiments (par exemple, les règles de calcul de la section d’un pilier en béton), des meubles, ou des véhicules.
Il en va de même pour le processus d’instruction des projets : les étapes à respecter, les rôles et les responsabilités des différentes parties prenantes sont identiques. Seules les procédures sont dépendantes de l’organisation, sa taille, et ses enjeux.
Des modèles de solutions et des standards de facto sont également disponibles : architectures n-tiers, décisionnelles, modèles IAM pour la gestion de la sécurité des accès, Hadoop pour le big data…
Le modèle fonctionnel est spécifique pour ce qui concerne les fonctions propres au(x) métier(s) de l’Entreprise : les fonctions génériques (RH, Finance, Compta, GED,…) étant de leur côté identiques d’une Entreprise à l’autre. Deux entreprises qui font le même métier ont des cadres fonctionnels extrêmement ressemblants !
Une logique du « juste assez »
Il existe de nombreuses méthodes pour mettre en place l’architecture d’entreprise, et il existe aussi de nombreuses solutions pour outiller ce métier. Ces méthodes ont pour but de guider les architectes pour la production et le maintien de ce que l’on appelle parfois des «actifs» d’architecture.
Ces méthodes, telles que TOGAF, sont parfois jugées longues et coûteuses à mettre en place, et ce, à juste titre. En effet, elles constituent une « check-list » certes très utile, mais elles se concentrent sur la fabrication de ces outils, et non sur leur utilisation au quotidien. A notre sens, du fait de leur complexité, elles sont à utiliser dans des conditions bien particulières, pour des programmes de transformation significatifs. Or, il est très rare que le système d’information d’une entreprise soit reconstruit de fond en comble.
A l’inverse, notre approche consiste à partir d’outils déjà utilisables, et de les adapter aux spécificités de l’entreprise. Cette approche est donc beaucoup plus rapide et économique : typiquement, quelques semaines suffisent pour démarrer une fonction Architecture.
Le véritable enjeu : accompagner le changement
Les entreprises sont de plus en plus nombreuses à avoir compris l’intérêt de la fonction architecture. Toutefois, la déployer reste un travail délicat : au départ, elle est souvent perçue comme superflue ou intrusive… Nos interventions chez nos clients se focalisent sur l’enjeu principal : accompagner ce changement, et faire en sorte qu’il soit accepté.
Soyons réalistes : on ne forme pas un architecte en six mois, ni même en trois ans, quelle que soit la méthode utilisée. En revanche, en quelques semaines, il est possible de l’aider à s’approprier des outils, et à les adapter aux enjeux de son entreprise et à son niveau de maturité.
Pour réussir ce changement, il est important d’accompagner l’architecte sur deux ou trois projets, afin de l’aider à prendre en main ses outils sur des cas concrets. Rien de tel en effet que l’application concrète à des projets de terrain, quelle que soit leur taille, pour démontrer le bien-fondé et la valeur ajoutée de l’architecture.
Depuis quelques années nous observons une croissance rapide du marché Cloud Public. Les offres Amazon Web Services (AWS), Microsoft Azure et Google Cloud Platform (GCP) sont arrivées maintenant à maturité.
Une jeune entreprise ou startup qui cherche à déployer une nouvelle application métier ne va même plus considérer d’acheter ou d’opérer des serveurs dans son data center ou via un hébergeur plus traditionnel. Afin de répondre à la demande de certaines entreprises, ces trois leaders sur le marché du Cloud Public ont tous sorti ces dernières années une solution permettant le Cloud Hybride. Mais que valent aujourd’hui ces solutions ? A quels cas d’usage permettent-elles de répondre ? Nous allons tenter de répondre à ces quelques questions dans cet article.
Les différentes stratégies d’adoption ou de migration vers le cloud
Si, pour certaines entreprises, une stratégie Cloud-First basée sur un seul fournisseur peut paraître tentante, celle-ci n’est pas sans risque comme nous l’avons expliqué dans notre article : Les 5 mythes associés à une stratégie Cloud-First.
D’autres vont adopter une stratégie multi-Cloud, c’est-à-dire qu’elles vont retenir les services de plusieurs fournisseurs, qu’ils soient SaaS, PaaS ou IaaS, afin de ne pas mettre tous leurs œufs dans le même panier.
Enfin, certaines ont fait le choix d’adopter une stratégie Cloud Hybride, afin d’avoir la possibilité de déployer l’infrastructure : soit sur une plateforme Cloud Public soit sur leur data center On-Premise, soit sur un Cloud Privé.
Nous allons maintenant vous présenter chacune des solutions proposées par ces trois fournisseurs et vous expliquer leurs différences.
Azure stack
Azure Stack est un portfolio de produits qui existe depuis 2016 et décliné sous forme de 3 solutions : Hub, HCI, Edge.
Azure Stack Hub vous offre la possibilité de déployer vos applications modernes basées en particulier sur des microservices ou des containers On-Premise.
Azure Stack HCI permet de déployer des ressources compute et de stockage pour des bureaux ou des usines qui nécessitent d’avoir des ressources en locales.
Enfin, il existe aussi Azure Stack Edge pour répondre aux cas d’usages nécessitant des capacités d’intelligence Artificielle et de Machine Learning en local.
Chacune de ces solutions n’a pas tout à fait la même couverture fonctionnelle (et le modèle des prix est aussi différent) que les services Cloud associés. Ces offres viennent sans matériel et celui-ci devra être acheté en sus parmi une gamme certifiée par Microsoft.
AWS Outpost
AWS a annoncé la sortie de sa solution Cloud Hybride fin 2019. Cela permet d’exécuter les services EC2, EBS, EMR et bientôt S3 en local. La solution comprend l’infrastructure et est livrée sous la forme d’une appliance. A noter que la solution Outpost ne permet pas de déployer ses services sur les autres fournisseurs Cloud Public.
AWS Snowflake
A noter aussi, ce service qui dans sa version Snowball Edge Storage Optimized permet d’avoir au sein d’un boîtier du stockage par bloc ou objet, de la CPU et un accès à certains algorithmes de Machine Learning. Ceci peut être pratique notamment pour des professionnels dans le multimédia ou la santé ayant besoin de faire des recherches avancées sur le contenu de très large bibliothèques de vidéos ou de photos en local sans avoir à les partager sur des services grands publics sur internet.
Anthos
La solution de Google est basée sur Kubernetes et permet pour des CloudOps familiers avec cet outil de déployer leurs applications basées sur des microservices à la fois On-Premise et sur d’autres fournisseurs Cloud Public.
VMWare
Il ne faut pas oublier que, depuis quelques années, Azure, AWS et Google offrent également la possibilité aux clients utilisant la solution de virtualisation VMWare d’étendre leurs ressources sur le Cloud Public.
IOT
Des solutions IOT mixant des ressources en ligne, Edge et On-Premise sont également disponibles mais celles-ci seront l’objet d’un prochain article.
A quels cas d’usage ou problématiques peuvent répondre ces solutions ?
Ces différentes solutions permettant de faire du Cloud Hybride peuvent être intéressantes pour certains cas d’usage. A titre d’exemples, nous pouvons citer :
Tirer parti de ressources compute, stockage et d’analyse sur des sites ayant besoin de croiser des données avec des systèmes de gestion hébergés en local.
Certains sites ou bureaux (ex : des points de vente) ont besoin d’exécuter des traitements critiques nécessitant des temps de réponses presque immédiats. Cela peut aussi être des transactions qui ne tolèrent pas les problèmes réseaux (ex : encaissement des achats clients).
Dans le cas précis d’Anthos ou d’Azure Stack, cela permet de capitaliser sur vos compétences internes et de pouvoir avoir une seule usine logicielle CI/CD pouvant être déployée sur plusieurs plateformes.
Enfin toutes ces solutions peuvent aussi servir comme option pour les applications nécessitant un Plan de Reprise d’Activité (PRA), pour faciliter vos migrations sur le Cloud Public ou pour faire du débordement pour absorber des pics de charge saisonnier à moindre coût.
Le revers de la médaille de ces solutions est que souvent seuls les services de base (IaaS, CaaS, certaines briques PaaS) sont proposés. Chaque année, les fournisseurs déploient des centaines, voire même des milliers d’innovations sur leurs propres data centers, dont vous ne pourrez pas bénéficier au fil de l’eau sur votre Stack Cloud OnPremise. Les plateformes Big Data ou e-Commerce ayant le plus besoin d’élasticité et de ressources quasi illimitées ne seront pas de bons candidats pour ce mode de déploiement.
Il ne faut pas se tromper, si Microsoft, Google et AWS disposent tous d’une solution pour faire du Cloud Hybride, c’est bien parce qu’il y a une forte demande même si cela permet de répondre à des cas d’usages bien précis. En 2017, la taille du marché pour le Cloud Hybride était estimée à 36 milliards $. Les analystes prévoient que celui-ci atteindra 171 milliards d’ici 2025 ! Alors qui gagnera la course pour dominer ce marché ?
