TOGAF est le Framework de l’architecture. Sa roue ADM est un classique. Le nombre de certifiés a explosé en France et dans le monde. Le but de cette série d’article est de voir avec vous, en se basant sur mon expérience de 13 années en tant qu’architecte, si ce framework doit être appliqué ou non, et sans renier la certification, réfléchir à comment l’appliquer et avec quel niveau d’investissement.
Nous allons donc commencer par explorer, dans cet article, les 2 premières phases, puis nous aborderons les autres phases dans de prochains articles.
Enfin certifié
Imaginons un plan de transformation du système d’information, vous êtes architecte et
on vous propose une formation. Comme vous êtes curieux, vous acceptez, et comme vous êtes travailleur vous réussissez l’examen final. Une fois la certification obtenue, et la satisfaction qui va avec, chacun s’est posé cette question : Qu’est-ce que je fais maintenant ? Et trop souvent, le résultat obtenu est décevant.
Il est décevant pour les certifiés qui ne savent pas comment mettre en œuvre ce qu’ils ont appris, mais aussi pour ceux qui ont financé cette certification et tout le monde a déjà entendu « TOGAF est trop loin de la réalité, cela ne sert à rien ». Alors, comment faire pour ne pas en arriver là ?
La phase préliminaire
Une phase primordiale
La première des phases de la roue ADM est celle qui, justement, est en dehors de la fameuse roue. C’est pourtant une phase vitale pour la suite de vos travaux. Elle sert à préparer l’entreprise aux travaux d’architecture (et pas uniquement la DSI). Les questions que l’on doit se poser sont « Où allons-nous faire de l’architecture ? avec Qui et Comment ? », mais également « Pourquoi ? ». L’odbjectif principal de cette phase est donc de construire une vue succincte des besoins, pour ensuite définir les capacités d’architecture que l’on pense nécessaire. Nous sommes en train de cadrer la mise en œuvre de l’architecture.
Capitaliser sur le sponsor
Lors de la formation, nous avons appris qu’il fallait commencer par définir la structure de l’entreprise puis les éléments métiers qui poussent au lancement de ce projet, de formuler la demande de travaux, de définir les principes d’architecture s’appliquant au projet, le référentiel à utiliser et les relations avec les autres référentiels de pilotage. Mais c’est également à ce moment qu’il faut évaluer la maturité de l’entreprise sur les notions d’architecture et que l’on peut adapter la méthodologie et l’ADM au projet.
Les « entrées », informations censées être collectées avant le projet, seraient : le modèle de l’organisation de l’entreprise, le référentiel méthodologique d’architecture, les outils, les principes d’architecture, le continuum d’entreprise, le référentiel d’architecture et le cadre de capacité… mais dans les faits, ces « entrées » sont rarement présentes.
Et pourtant, TOGAF préconise une première réunion avec le sponsor / commanditaire lors de cette phase et celle-ci est obligatoire. Lors de cette première réunion, les points cruciaux sont les entités / fonctions de l’entreprise pour définir le périmètre de l’étude, la gouvernance du projet d’architecture et bien sûr, le driver de la transformation. Sans cette réunion, il n’est pas utile d’aller plus loin, et si cela est difficile à organiser, vous avez déjà votre évaluation de la maturité.
Capitaliser sur ce qui existe pour ne pas consommer trop de temps
D’après TOGAF, il est possible, lors de cette phase, de modifier la roue ADM pour répondre au mieux aux besoins du projet de l’entreprise. Attention toutefois, il peut être dangereux de remettre en cause la roue ADM à chaque itération, et il faut absolument en garder le principe (l’enchainement des phases et les liens entre elles). Il est préférable d’avoir une roue stable sur un segment fonctionnel donné.
Nous allons donc commencer par la phase préliminaire elle-même : Le but est de de capitaliser sur ce qui a déjà été fait. Lors de la réunion avec le sponsor, vous avez identifié les grandes fonctions impactées. Pour identifier la capacité d’architecture nécessaire à votre projet, 3 situations peuvent se présenter à vous :
Si vous être dans une grande entreprise, il y a déjà des architectes en charge de ces fonctions, il suffit de leur exposer les attendus métier et de collecter leurs retours.
Si ce n’est pas le cas, il est possible de se baser sur des projets précédents. De façon native, de nombreuses étapes de la roue TOGAF sont déjà mises en place au sein d’un SI : des architectures applicatives ou techniques, parfois des processus sont déjà modélisés, des plans de migration sont mis à plat avec la gouvernance associée. Cela est tout à fait normal car TOGAF est un framework pour répondre à des besoins liés à une DSI et parfois, des réponses ont déjà été apportées à des besoins apparus lors des projets. Il faut alors se baser sur ce retour d’expérience.
Si vous n’êtes dans aucun des cas précédents, Il ne reste plus qu’à construire vous-même vos hypothèses. Basez vous sur quelques concepts faciles à identifier : Combien de processus ? Sont-ils le cœur de métier de l’entreprise ou pas ? Quelle est l’application au cœur de la transformation et quelle est l’équipe qui en a la charge ? Ces hypothèses seront évidemment fausses mais cela permet de poser une première brique.
Savoir comment valider ses propositions
Pour finir cette phase, il reste à définir comment faire valider vos travaux. Pour cela rien de plus facile : Si un processus de validation existe déjà, demandez-le ainsi que le temps moyen de validation. S’il vous semble imparfait, n’essayer pas de le faire modifier. Vous allez perdre du temps qui serait utile à votre projet. Si aucun processus n’existe, faites valider vos propositions par le sponsor et les parties prenantes, comme cela est préconisé par TOGAF.
Tout le monde sur la ligne de départ
A la fin de cette phase, vous aurez la structure de votre équipe d’architecture, qui valide les étapes et les résultats de l’étude, prête à démarrer votre projet.
La phase a : la vision de l’architecture
Les choses sérieuses commencent
La phase de vision de l’architecture permet de définir les impacts du projet sur le système d’information ainsi que les chantiers d’architecture à mettre en place. Elle est précédée de la phase préliminaire ou de la roue ADM précédente (en plus clair, la précédente phase du projet).
D’après TOGAF, a liste des étapes pour construire la vision d’architecture sont : identifier les parties prenantes et leurs exigences, les enjeux métiers (les bénéfices attendus par le métier), confirmer les objectifs, évaluer le niveau de motivation et de préparation des métiers, ainsi que les capacités des dits métiers, confirmer les principes d’architecture, définir les KPI pour mesurer les bénéfices d’architecture, les risques… Bien sûr, tout cela est logique dans un monde sans contrainte, mais cela arrive peu, pour ne pas dire jamais :
Comment évaluer les capacités du métier à répondre aux attentes de l’architecture, son niveau de motivation ou de préparation ? L’architecture est habituellement intégrée à la DSI et à quoi bon faire cela ? Comment présenter au métier, qui finance la DSI et l’étude, qu’il n’est pas au niveau et quels seraient les critères pour dire cela ?
Comment estimer la capacité du métier ? A partir des chaines de valeur ? Le contrôle de gestion de l’entreprise est le seul à avoir les informations nécessaires, mais les informations sont rarement partagées.
Et pour les KPI, comment faire une évaluation des gains alors que les problèmes à résoudre sont noyés dans le reste des activités des utilisateurs ?
Se concentrer sur l’essentiel
En fait, tout cela s’ajuste au fur et à mesure de l’avancée de l’étude, car cela permet au métier de reprendre le contrôle sur ses outils et ses processus. Cependant, on peut rapidement réaliser quelques étapes de cette phase :
Construire une carte des parties prenantes permet de faire une estimation rapide des influences de chacun.
Faire une macro-cartographie pour définir les grands ensembles du projet ainsi que quelques scenarios métiers pour pouvoir « jouer » des cas pratiques lors de la conception de la solution.
Si la mise en place des KPI n’est pas possible, on peut au moins demander au métier de faire une pondération « à dire d’expert » de ses attendus. En fait, il suffit souvent de demander les différents « pain points » à résoudre ainsi que les nouveaux besoins auxquels répondre, et de demander un ordre de priorité. A la fin du projet, vous pourrez demander au métier si la solution apportée lui convient.
L’état des lieux est terminé
Au final, cela permet à chacun de faire une évaluation plus fine de l’étude à réaliser et de compléter la note de cadrage. Comme dans toutes les épreuves, tous ces éléments vont s’affiner avec le temps et il est bon de garder le document pour le confronter au réel.
La suite
La grande force de la roue TOGAF est qu’elle traite toutes les problématiques liées à l’architecture et apporte une réponse, ou au moins un Framework pour répondre, à ces problématiques. Et comme tout framework, il est important de l’appliquer à un contexte. Suivre TOGAF c’est bien, savoir le faire sans oublier pourquoi, c’est mieux. Il n’est pas utile de tout faire exactement comme cela est préconisé – tous les acteurs du projet n’en saisissent pas forcement les bénéfices – mais il est tout à fait possible d’en extraire l’essentiel. Apres avoir traité les deux premières phases, nous continuerons, dans les prochains articles, à parcourir les autres phases la roue ADM et explorer ensemble TOGAF IN REAL LIFE.
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.
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é ?
Les données sont partout et nulle part et sont bien souvent intangibles. Notre quotidien devient petit à petit un flot permanent de données générées, collectées et traitées. Elles sont cependant un moyen pour atteindre des objectifs et non une finalité.
Les entreprises doivent donc avoir la capacité à naviguer vers leurs objectifs business, sur une rivière qui deviendra vite un océan de données. L’important maintenant est donc de savoir si elles ont les moyens de braver les éléments.
Les ‘éléments’ auxquels il faut faire face
1. L’obligation de la donnée
La donnée est omniprésente. Données personnelles, confidentielles, de navigation, de consentement, data science, data platform, data visualization, chief data officer font partie d’une longue liste de termes qui font le quotidien des experts mais aussi du client consommateur. Les données sont aujourd’hui un asset reconnu et à forte valeur ajoutée (1). Elles sont aussi un asset pérenne du fait des usages numériques et des opportunités business qui se réinventent tous les jours.
Premier constat donc, l’obligation de la donnée. Elle est un passage obligatoire pour mieux connaître les consommateurs, répondre à leurs nouveaux besoins et être innovant.
2. La surabondance
La digitalisation croissante dans tous les secteurs, les réseaux sociaux, l’IOT, la mobilité, l’utilisation croissante des smartphones sont des exemples qui provoquent une forte augmentation de la génération de données. Les sources se multiplient, les besoins en stockage également (2). Par conséquent, nous sommes vite confrontés à une problématique grandissante : comment maîtriser toutes ces données ? Comment faire face à ce flot surabondant ? Et comment en tirer des informations utiles sans être noyé ?
Les prévisions (3) tablent en effet sur une multiplication par trois ou quatre du volume annuel de données créées tous les cinq ans. Les chiffres sont implacables.
Le deuxième constat est donc la surabondance. Un océan numérique déferle et chaque entreprise, peu importe sa taille, devra y faire face.
3. L’éphémère
Le numérique génère de nouvelles habitudes chez le consommateur : l’instantanéité, le choix abondant et la rapidité de changement. (offre, prix, produit, etc.). Ces habitudes se traduisent par des besoins de plus en plus éphémères. Elles raccourcissent les durées de vie des produits et des services, ou imposent de continuellement se renouveler pour se différencier. Les opportunités marchés sont nombreuses et il faut aller vite pour les saisir le premier. Être le premier est ainsi souvent synonyme de leadership sur le marché. (exemple : Tesla, Airbnb, Uber) L’éphémérité des besoins impose donc d’accélérer en permanence tous les processus internes, métier et SI.
Le troisième constat est donc l’éphémère (besoin, produits, services) qui devient de plus en plus présent. Il est ainsi nécessaire d’être de plus en plus réactif pour s’adapter et évoluer rapidement face à ces changements permanents.
4. L’innovation permanente
Le numérique engendre aussi une accélération de l’innovation. Il rend accessible au plus grand nombre la possibilité de réinventer son quotidien. Cette accélération permanente rend plus rapidement obsolète l’invention d’hier.
Qui aurait en effet pensé que nous allions pouvoir partager nos appartements il y a 10 ans ? Qui aurait pensé que payer sa place de parking se ferait sur son téléphone ? Et surtout qui aurait pensé qu’un téléphone deviendrait l’accès privilégié à toutes nos innovations de demain ?
Le dernier constat est donc l’innovation permanente. Comme pour l’instantanéité, cela génère un besoin de flexibilité et de rapidité fort pour pouvoir suivre le rythme d’innovations imposé par le monde digital.
5. La capillarité de la donnée
Quel est le point commun aux constats précédents ? La donnée. La donnée est présente dans tous les processus et tous les usages en contact ou non avec le client. Ainsi la donnée, par nature, telle la propagation d’un liquide sur une surface, oblige à s’interroger sur les briques du SI qui l’utilisent pendant ces processus et ces usages : c’est la capillarité des données.
Ensuite avec de l’expertise et de la méthodologie, tout s’enchaîne! La définition des besoins et la conception fonctionnelle au travers du prisme “donnée” dans une vision d’ensemble, feront que naturellement par capillarité, vous adresserez le cycle de vie de la donnée, sa valeur et l’architecture de votre SI pour répondre à ces besoins.
Survivre grâce au SI Data Centric
Dans ce contexte de surabondance, d’éphémérité et d’innovation permanente, comment alors maîtriser son patrimoine de données ? Il s’agit de raisonner données et non plus SI. L’objectif devient la gestion de la donnée. Se poser la question de comment gérer des données permet en effet d’adresser ces changements détaillés précédemment et par capillarité, le SI. Un SI centré sur les données est donc le moyen d’adresser ces vagues de changements et de résister aux éléments. En effet, gérer les données impliquent des notions d’unicité, de qualité, de volumétrie, de performance, de confidentialité, d’échanges, de réglementations. L’amélioration de la conception du SI pour faire face à ce nouveau contexte est donc immédiate.
Les fonctions à adresser par le SI, qu’elles soient métiers ou techniques, et la gouvernance nécessaire à la gestion des données vont soulever des questions qui permettront d’adresser ce nouveau contexte d’éphémérité et de surabondance. L’innovation permanente oblige, elle, à industrialiser la livraison des nouvelles fonctionnalités de ce SI centré sur les données. Le SI se construit ainsi autour de la donnée : flexible, modulaire, et industrialisé. Par exemple des référentiels (produits, clients, fournisseurs, etc.) sont mis en place, garantissant la qualité et la mise à jour des données utilisées par toute l’entreprise. Un autre exemple est que les données collectées sont conservées à un seul endroit brutes puis standardisées pour identifier les relations entre elles. Ou encore des outils permettant d’avoir la définition, le cycle de vie et le propriétaire de chaque donnée sont déployés. Le SI devient ainsi un SI centré sur les données. (“Data Centric”).
Il s’adaptera donc naturellement aux futurs changements du marché grâce à tout ce qu’implique la donnée. Il devient un socle solide adressant différents usages sans forcément avoir besoin de transformation en profondeur, longue et coûteuse. Pourquoi ? Car encore une fois, gérer une donnée et faire en sorte qu’elle soit collectée, de qualité, sous contrôle, disponible partout en temps réel et en unitaire ou en masse, intégrées aux processus cœur de métier de l’entreprise, est universel et adaptable à tout usage.
Intrinsèquement la donnée est agnostique de l’usage qu’elle sert. C’est le SI Data Centric qui garantit cette fonction, et assure la survie de l’entreprise dans la jungle digitale.
Conclusion
S’impliquer fortement dans l’évolution du SI est donc nécessaire. L’objectif est de commencer petit mais de commencer Data Centric. Usage après usage, votre SI se construit toujours plus résilient aux différentes vagues de cet océan de données. Un autre bénéfice, et non des moindres : l’innovation des équipes n’étant plus ralentie par le SI, elle s’en trouve ainsi décuplée.
Construire un SI Data Centric, c’est la garantie d’avoir un SI modulaire et adaptable qui répond aux enjeux d’aujourd’hui et de demain. Il est ainsi une base solide sur laquelle construire la pérennité de l’entreprise dans ce nouveau contexte.
Nous aurions pu dresser ici un panorama des technologies, mais mis à part l’intérêt artistique de la présentation, même si l’analyse de notre exemple est très pertinente, sa plus-value en termes d’architecture s’en serait trouvée limitée (1).
Certains proposent une vision basée sur les prérogatives technologiques.
Cette approche (2) oublie la finalité du stockage de la donnée et ne propose qu’un nombre limité de solutions. Nous préférons donc proposer une approche axée sur l’usage de la donnée et sur le besoin utilisateur…
Faisons un rapide tour d’horizon des technologies
Aujourd’hui lorsque nous parlons de data stores, plusieurs familles sont représentées :
Les bases de données relationnelles : Oracle, SQLServeur, MySQL, PostgreSQL, …
D’autres technologies (de stockage ou autres) qui, même si elles permettent de répondre à certains besoins, ne sont pas réellement des bases de données : AWS S3, Azure Blobstorage, Stockage HDFS, Elastic Search, …
Bref, plus de 350 bases de données sont répertoriées à ce jour. Certaines sont uniquement disponibles en PaaS, d’autres sont hybrides et certaines plus traditionnelles ne sont pas éligibles au Cloud(3). Il est donc indispensable de construire une méthodologie qui permette de choisir la technologie qui réponde au besoin.
Pas facile de faire son choix !
Répondre à notre question initiale est bien plus complexe aujourd’hui qu’il y a quelques années, tant les usages ont évolués et les technologies se sont multipliées.
Toutefois pour ne pas se tromper, les bonnes questions à adresser en amont sont les suivantes :
De quelle manière l’application va-t-elle consommer les données : via des appels directs, une couche d’API, des requêtes GraphQL ?
Est-ce que les fonctionnalités attendues doivent être portées uniquement par la base de données ? Ou est-ce que des composants supplémentaires sont nécessaires ?
Est-ce que les transactions doivent être ACID (4) ?
A quelles contraintes du théorème CAP(Consistency, Availability, Partition tolerance) (5) la base de données doit-elle répondre en priorité ?
Quelles structures ou formats de données se prêtent le mieux à l’usage demandé : clé/valeur, colonne, document ou encore graph ?
Quelle va être la volumétrie de ces données ? Quels sont les besoins en termes de performances, de résilience ?
Pour quel type d’usage ? (Décisionnel ? Transactionnel ? Événementiel ?)
Pour quelle nature de données ? (IoT ? Géographiques ? Coordonnées GPS ? Données chronologiques ? Spatio-temporelles ?)
D’autres considérations doivent également être prisent en compte :
Quel sera l’écosystème dans lequel va être hébergée mon application (Cloud ou On Premise) ?
Y a t’il besoin d’accéder aux données lorsque l’application est déconnectée de la base de données ?
Est-ce que je souhaite m’inscrire dans un écosystème intégré (certains éditeurs fournissent des composants qui n’ont plus rien à voir avec le stockage de la données (6)) ?
Quel est le niveau de maturité des équipes de développement, des équipes chargées d’assurer le RUN et l’assistance technique ?
Quel est le niveau de sécurité à appliquer pour protéger les données ?
Au cas par cas, suivant l’usage qui sera fait des données, selon le type des données, selon le niveau de protection nécessaire, nous vous conseillons de construire un arbre de décision cohérent avec l’ensemble des contraintes à appliquer.
Dans certains cas, la solution pour simplifier la spécialisation du stockage sera complétée par une orientation microservice. Cette approche permettra d’exposer et de consommer les données de manière beaucoup plus souple qu’avec l’approche monolithique traditionnelle (un seul data store pour toutes vos données).
Pour en savoir plus sur ces sujets, nous vous invitons à consulter nos articles dédiés :
La solution, concentrez-vous sur le besoin initial
Que l’on se le dise, il n’y aura pas de solution permettant de répondre à l’ensemble des besoins. Les projets qui réussissent sont ceux qui se concentrent sur le besoin initial, prennent en compte le savoir-faire de l’équipe en charge du projet et qui, lorsque le besoin évolue, complètent leur architecture en restant concentrés sur le besoin métier.
En conclusion, la solution de stockage ne doit pas être choisie uniquement en fonction des contraintes technologiques, mais bien en fonction de l’usage qui sera fait de la donnée.
Vous avez des APIs pour interconnecter les systèmes ? Parfait c’est une belle première étape. Asseyons-nous maintenant pour parler de résilience et de découplage… Une nouvelle étape s’ouvre : les APIs Asynchrones ? Mais quelle obscure clarté, quelle douce violence est-ce donc que cela ??
Un petit récap, pourquoi parler d’APIs asynchrones ?
Le sujet des APIs asynchrones résonne depuis quelques années dans la tête des architectes, et ces derniers en font de plus en plus un de leurs objectifs : une API, donc un contrat d’interface bien défini, qui s’affranchit des défauts des APIs. Comme disait le sage Bruno dans son article : “Favoriser l’asynchronisme est un bon principe de conception de flux”.
Ce besoin d’éviter un couplage fort et de créer des SAS de décompression entre les différentes applications / parcours est certainement cohérent, mais est à priori en contradiction avec la nature même des API et du protocole HTTP. Alors comment concilier le meilleur de ces deux mondes ?
Commençons par les bases, une API asynchrone, concrètement, c’est quoi ?
Une API asynchrone est une API recevant, par exemple, la commande d’un client, client qui n’attend pas la réponse de celle-ci dans l’immédiat. Le seul retour mis à disposition par l’API, dans un premier temps, est la prise en compte de la demande (un « acknowledgement » : vous avez bien votre ticket, merci d’attendre).
Le fournisseur d’API effectue les actions nécessaires pour satisfaire la requête, sans forcément être contraint par des timeouts, en gros il peut prendre son temps pour en garantir la bonne exécution.
Et dans la pratique ?
En pratique, cette architecture peut être garantie par le couple API qui poste dans une queue / topic assurés par un outil de type MOM.
L’API déverse les informations dans une queue (ou topic) du MOM, informations qui sont ensuite prises en compte suivant les disponibilités des applications en aval. L’application appelée devient un consommateur d’un flux asynchrone, ce qui permet de découpler les deux.
Pour notifier, ça passe crème
Ce type de comportement est facilement mis en place lorsque nous nous trouvons dans des cas de figure non critiques, dans lesquels par exemple on doit notifier un utilisateur LinkedIn de l’anniversaire d’un de ses contacts : en tant que client, tant pis si l’information n’arrive pas, nous pouvons accepter un manque de fiabilité.
Un peu moins quand l’objectif porte sur un échange critique
Tout change quand le demandeur s’attend à quelque-chose, soit une information soit une confirmation forte de la livraison de l’information , car cet aspect demeure crucial pour son bon fonctionnement. Dans une API synchrone, nous l’obtenons à la fin de la transaction.
Dans le cas asynchrone, comment garantir le même comportement lorsque la transaction se termine ?
C’est à ce niveau que les avantages de l’asynchronisme induisent une complication de gestion, complication dont souvent les équipes n’ont pas conscience. Une confirmation de réception (“acknowledgement”) est dans ces cas insuffisante (ex. votre transaction bancaire s’est bien passée, comme par exemple un virement).
Mais alors comment notifier le client du résultat ?
La mise en place d’une logique de réponse peut être construite de deux façons différentes.
En mode PULL
Le mode pull présuppose que l’action soit toujours à l’initiative du client.
L’API met à disposition le statut de l’action (sous forme de numéro de suivi), sans notifier le client. C’est au client de venir vérifier le statut de sa demande, en faisant des requêtes de suivi à des intervalles réguliers.
En mode PUSH
Le mode push suppose que le canal de communication soit ouvert dans les deux sens, et que le serveur ne soit pas forcément tenu d’attendre une requête du client pour “pousser” l’information.
Certaines technologies et patterns d’architecture, permettent de mettre en place ce mode de communication, pour citer les plus connus :
Le protocole websocket permettant l’ouverture de canaux pour établir une communication bidirectionnelle entre serveur et client,
Les mécanismes de CallBack et Webhooks,
Les constructions réalisées avec des MOMs, basées sur des queues / topics d’aller et d’autres de retour, qui se traduisent en patterns request / reply implémentés par certains de ces outils,
Basés sur des solutions similaires au précédent point, des patterns d’architecture custom permettant de gérer ces aller-retours entre applications.
Les patterns schématisés ci-dessous ne sont pas exhaustifs mais ont pour objectif de montrer des exemples réels de contraintes, en termes de flux, apportées par les trois modes : synchrone, asynchrone pull et asynchrone push.
Synchrone
Asynchrone Pull
Asynchrone Push
Mais alors, push ou pull ?
L’utilisation d’un pattern par rapport à l’autre doit être réfléchie, car donner un avis tranché sur la meilleure solution est assez compliqué sans connaître l’environnement et les contraintes. Les deux techniques sont fondamentalement faisables mais le choix dépendra du besoin réel, des patterns supportés par les socles déjà déployés et des applications difficilement intégrables en synchrone.
Notre avis est d’éviter au maximum les solutions pull, car ces méthodes impliquent des aller-retour inutiles entre les applications.
Comment mettre du liant entre aller et retour ?
La mise en place d’une API asynchrone présuppose donc une certaine attention à l’intégrité fonctionnelle entre la requête et la réponse, qui ne sont pas, dans le cas de l’asynchronisme, forcément liées par la même transaction.
Pour garantir l’intégrité fonctionnelle et le lien entre la requête et la réponse, surtout dans le cas d’une notification PUSH, un échange d’informations pour identifier et coupler les deux étapes est nécessaire. L’utilisation d’informations spécifiques dans l’entête des requêtes, comme dans le cas d’APIs synchrones, est une solution performante, tout en s’assurant d’avoir mis en place les bonnes pratiques de sécurité visant à éviter l’intrusion de tiers dans la communication. Sans vouloir réinventer la roue, les mécanismes déjà en place pour d’autres technologies peuvent être repris, comme par exemple les identifiants de corrélation, chers au MOMs, identifiants qui permettent de créer un lien entre les différentes communications.
Si on utilise des mécanismes non natifs aux API, pourquoi passer par une API et pas par un autre moyen asynchrone ?
Le choix de passer par une API a plusieurs raisons, suivant le cas d’usage :
c’est le standard actuel auquel la plupart des solutions ont adhéré, avec un fonctionnement API first même si le besoin est asynchrone
l’éventuelle gestion par API gateway, rendue possible sur une construction asynchrone par cette solution, demeure très pratique pour la gestion des échanges, avec des avantages que les protocoles / solutions asynchrones classiques ne sont pas prêts d’intégrer
Cela ne limite pas pour autant le spectre d’APIs asynchrones au seul HTTP. Bien que le standard OpenAPI soit fortement focalisé HTTP, d’autres standards ont été conçus expressément pour les cas d’usage asynchrone.
Exemple, la spécification AsyncAPI. Cette spécification se veut agnostique du protocole de communication avec le serveur, qui peut être du HTTP, mais également du AMQP, MQTT, Kafka, STOMP, etc. standards normalement employés par des MOMs.
Conclusion
En conclusion, notre conviction est que l’asynchronisme est vraiment la pièce manquante aux approches API. L’APIsation a été un formidable bond en termes de standardisation des interfaces mais reste jusque là coincée dans son carcan synchrone. L’heure de la pleine maturité a sonnée !
