Vous avez peut-être souvent entendu ces mots « Data is an Asset ». Mais la personne qui les prononce va rarement au bout de l’idée. Et pour cause, l’exercice est plus complexe qu’il n’en a l’air. Cet article a pour ambition d’éclairer le domaine et, pour cela, procédons par étape :
1 – Qu’est-ce qu’un Asset ?
Nous n’allons pas l’inventer, il existe une très bonne définition sur ce site : https://www.investopedia.com/ask/answers/12/what-is-an-asset.asp)
« An asset is anything of value that can be converted into cash. Assets are owned by individuals, businesses and governments »
« Un asset est quelque chose qui peut être converti en monnaie sonnante et trébuchante ».
Avec une maison, cela marche bien en effet. Une expertise suffira à vous donner une bonne idée de la valeur euro de votre maison. Mais pour vos données, ça ne paraît pas si simple.
Le défi aujourd’hui est d’être en mesure de valoriser une donnée, ce qui signifie :
Pouvoir par exemple très formellement comparer deux actifs Data entre eux, deux jeux de données (par exemple sur la base de critères bien définis)
Mettre une valeur « euro » sur un jeu de données (monétisation, prise en compte de l’actif Data sur des opérations d’acquisition / fusion, etc.)
Gérer nos données comme des Actifs, pour maintenir ou développer leur valeur dans le temps
Sur ce dernier point, faisons l’exercice rapide ensemble. Prenons un processus d’asset management standard, appliquons-le à la donnée.
2 – Appliquons un Processus d’Asset management à la Data
Alors allons y ! Appliquons ce processus sur les données pour voir si elle peut être gérée comme un Asset ?
« Inventory » :Inventorier les assets Data. Jusque-là tout va bien.
« Asset Condition Assessment » :Évaluer l’état des biens: Est-ce que la donnée est de qualité, est-ce qu’elle il y a souvent des erreurs qui apparaissent ? Comment les gère-t-on ?
« Determine residual Life / Decay curve » : Il s’agit d’évaluer l’évolution potentielle de différents critères de valeur dans le temps. Par exemple est-ce que la donnée risque de perdre en rareté ? Les usages vont-ils être moins importants ? etc. En général cette notion porte sur le vieillissement d’un bien physique :
« Valuation » : Pour valoriser la donnée, on sent qu’il nous faut poser clairement un cadre de valorisation sur base d’un ensemble de critères. Au même titre que l’expert par exemple en Asset commercial connaît parfaitement les critères qui permettent da valoriser un commerce (surface du commerce, chiffre d’affaire, situation géographique, etc…). Notre conviction est qu’il faut aujourd’hui développer ce cadre pour l’actif « Data ».
« Life Cycle Costing » : C’est le processus qui permet d’identifier tous les coûts impliqués dans le cycle de vie de l’actif (coût d’une erreur, coût de la réparation / correction, coût de la perte de production éventuelle, coût de la maintenance corrective, ….)
« Determine replacements» : Est-ce qu’il faut revoir la manière de gérer certains asset Data ? Faut-il en abandonner/purger certains, non rentables ?
« Set target LOS » : Quel est le niveau de service attendu sur chaque asset Data ? A quels besoins faut-il répondre pour que l’asset ait de la valeur, soit viable ? Quels critères de valorisation veut-on améliorer ? (rareté, qualité, …)
« Assign BRE rating » = Business Risk Evaluation : Et quels sont les risques ? (GDPR, perte de données, …) : « Comment est-ce que des problèmes / incidents peuvent apparaître ? Quelle probabilité d’apparition ? Qu’est cela coûterait si le problème apparaissait ? Quelles en seraient les différentes conséquences ? »
« Determine Appropriate Maintenance » : Si l’on veut maintenir la qualité d’une donnée par exemple, par exemple 3 stratégies de maintenance existent dans le monde physique, elles sont applicables à l’actif Data (Use Base Maintenance : revue à une fréquence donnée, Fail based maintenance : correction sur incident/erreur, Condition Bases Maintenance : Maintenance plus préventive)
« Determine Appropriate CIP » (Capital Investment Program) : Initier (ou mettre à jour) notre programme d’investissement (Projet d’extension du capital d’assets Data, de renouvellement/modification de la gestion de certains Assets, mise en place de nouveaux processus de maintenance = gouvernance…)
« Fund your strategy » : On obtient le financement pour tout cela
« Build the Asset Management Plan » : Enfin on construit, ou on met à jour notre plan de gestion et de valorisation de nos assets Data
La méthode a l’air adaptée. Mais elle soulève des questions clés, auxquelles il va nous falloir répondre, notamment concernant les critères de valorisation. A titre d’exemple, le CIGREF a travaillé sur un cadre d’appréciation de la valeur économique des projets de transformation numérique. Il est intéressant d’avoir une approche comparable pour l’actif « Data ».
3 – Et après ?
Nous venons de voir que la data est effectivement un actif, d’un type bien particulier. Pour aller plus loin, il va falloir identifier des critères objectifs de valorisation des données, et faire des usages de ces données un vecteur clé de sa valorisation.
Dans cet optique, nous pensons qu’un cadre méthodologique de valorisation des données est nécessaire.
Rhapsodies Conseil construit une approche méthodologique pour mesurer la valeur des données, en mettant les usages métiers des données au cœur de la méthodologie, approche que nous vous invitons à découvrir prochainement. En parallèle, nous vous recommandons les travaux initiés sur ces sujets par Doug Laney pour Gartner Inc., en particulier à travers son ouvrage « Infonomics » aux éditions Routledge.
Plusieurs questions se posent aujourd’hui, alors que de nombreux environnements Hadoop sont en production depuis quelques mois / années :
Le Data Lake est-il aussi utile/utilisé que prévu ? et ne l’utilise-t-on pas, à défaut d’avoir trouvé un usage pertinent, à des fins qui n’étaient pas prévues au départ ( exemple courant … GPP : Gros Passe Plat ou encore EDDC : Extracteur De Données Centralisé … )
Comment structurer les données dans le Data Lake ? Si c’est pour mettre un Hadoop chez soi et structurer sa donnée dans quelques parquets et des tables hive, mais avec la même logique que nos bonnes vieilles tables SQL normalisés 3NF, à part de dire « Youhou, hadoop on l’a fait, on en a une belle maintenant ! » Quel intérêt ? C’est comme s’acheter une console Switch en ne la décrochant jamais de son socle (pardon pour l’image pour ceux qui ne connaîtraient pas la dernière console de Nintendo…).
Comment on rend la valeur de l’outil palpable par l’utilisateur final ? Que ce soit pour du reporting quasi temps-réel / journalier / mensuel, de la Data Viz ou de l’analyse de données avancée (un super Random Forest, un neural Network au top en production…) qu’est ce qui fera la différence pour l’utilisateur final ? Par rapport à ce qu’on lui donnait déjà avant…
J’essaie de donner des éléments de réponses ci-dessous et ce n’est que mon humble avis. Si vous avez vos expériences à partager n’hésitez pas.
1 – Le data lake est-il aussi utile/utilisé que prévu ?
Les environnements distribués naissent un peu partout au moment ou j’écris ces lignes. 2 cas caractéristiques existent qui peuvent être problématiques :
Cas 1 – Etre gourmand, trop gourmand : De nombreuses entreprises se sont ruées vers la tendance sans même vraiment avoir eu une réflexion de fond sur la valeur que devraient leur apporter ces nouvelles capacités dans leur contexte, elles se retrouvent aujourd’hui avec des téras stockées qui ne leur apportent pas autant qu’elles l’auraient espérées. On a voulu en mettre beaucoup, on n’a pas pris le temps de travailler sur la description de ce qu’on y a mis (meta data), et peu de gens comprennent vraiment ce qu’on peut y trouver et si c’est vraiment fiable.
Leur Data Lake devient petit à petit un passe-plat facilitant préparations et fournitures de certaines données bien spécialisées, même sur des volumes qui ne justifient en rien son usage, opérant quelques croisements ici et là entre sources originales qui n’étaient pas avant dans le même environnement technique. Elles font face à des bi-modes Hadoop VS Entrepôt Oracle/SAS (pour ne donner qu’un exemple). Certaines données sont dans les deux types de système et l’utilisateur Analyste ne sait pas vraiment lequel utiliser. Alors les Data Scientist, statisticiens – vieux de la vieille continuent à bosser dans SAS parce qu’ils n’ont pas le temps d’apprendre Python, et les petits jeunes qui sortent d’écoles pensent pouvoir changer le monde avec leur modèle de churn codé en Python / Spark mais qui a en réalité déjà été implémenté il y a 10 ans par un Data Miner expert SAS avec une méthode et des résultats similaires… Ce n’est qu’un rien caricaturale.
Pour prouver sa valeur et justifier son coût, ce Data Lake là va devoir se recentrer sur des usages clés porteur de valeur (et de gain euros…) pour l’entreprise, qui justifie son existence, ou mourir de désillusion ou rester un gros GPP (gros passe plat…).
Cas 2 – Etre timide, trop timide : D’autres entreprises plus prudentes, fonctionnent en petites itérations, à base de POC Big Data sous Microsoft AZURE, AWS et autres google cloud, en sélectionnant des cas d’usages qui justifient l’utilisation de telles plateformes. Parfois, le risque est d’être dans l’excès inverse du premier cas, en priorisant trop et en ne montrant rien.
Trouver 3 usages coeur de métier pour commencer est une excellente chose, mais les cas d’usages doivent être assez complets pour montrer l’étendue des possibilités que peut apporter un environnement comme hadoop et tous ses petits (la multitude d’outils d’intégrations, d’analyses, de traitements qui se basent sur hadoop).
Toutefois, faire un vrai POC métier est la clé pour les entreprises qui en sont à ce stade, montrer que Hadoop traite très très très vite un très très très gros volume de données, n’apporte rien au métier. Faire une démo d’un outil métier qui illustre un vrai cas métier en mettant en valeur :
La performance ressentie par l’utilisateur (des jolis diagrammes qui s’affiche rapidement quand l’utilisateur clique sur la carte 🙂 « C’est beau, ca va vite, c’est utile ! ouaouh ! »
La valeur/connaissance apportée en plus en allant au bout de l’usage : On sait détecter un problème, une fraude, etc…et ça génère une alerte en temps réel dans l’outil de l’opérateur qui lui recommande l’action à faire ! Ouaouh merci c’est ce qui fallait ! c’était possible alors ? dingue…)
Dans tous les cas, encore une fois allez au bout de l’usage ! On a tendance à s’arrêter juste un peu avant ce qu’il faudrait (par manque de temps, de connaissance métier, de courage). Ne faites pas un POC IT, ayez le courage de faire un vrai POC business pas juste à moitié parce que vous ne connaissez pas assez le métier, allez jusqu’au bout de la démonstration, jusqu’à la jolie petite interface interactive qui fera la différence. Sinon vous n’aurez pas votre Waouh. Faites collaborer les Data Scientist avec les développeurs des appli métiers pour avoir un vrai résultat.
Si vous ne faites pas cela, les gens comprendrons peut être la théorie « D’accord vous faites une grosse boîte où vous mettez toutes les données et puis ça tourne vite comme une machine à laver, c’est ça ? 🙂 ».
Non ! vous voulez un : « Ah, mon opérateur ne va plus devoir scruter toutes les logs à la mano pour essayer de trouver les problèmes, et je vais multiplier par 10 ma productivité donc…En fait…Ai-je toujours besoin d’un opérateur ? » OUI, là on est bon.
2 – Quelques principes pour structurer le data lake
Ne traitez pas votre Data Lake comme une poubelle à données qu’on recyclera peut être un jour en cas de besoin (le fameux « on prend, on sait jamais » du Data Lake, anti GDPR par dessus le marché). Mais traitez le bien comme un lac nourrissant, abreuvant et vital ! Moins de quantité, plus de qualité.
Structurer vos Données intelligemment. Ce n’est pas parce que vous avez beaucoup de place que vous pouvez en mettre de partout et n’importe comment (que dirait votre mère franchement?). Votre Data Lake doit normalement séparer :
Les données sources (Raw Data)à l’image des données du système sources
Les données sources (Raw Data) retraitées uniquement par applications de règles purement techniques (votre format de date standard, types de données, etc…). Pas de règles métiers ! Pas ici, le but est juste de récupérer la donnée brute ! C’est d’ailleurs un sage principe que vous trouvez aussi dans la philosophie DataVault de Dan Linstedt. Vous n’appliquez des règles métier qu’au moment de la construction de vues métiers qui répondent à un usage donné. C’est aussi surtout du bon sens…Cela apportera bien plus d’agilité à l’ensemble du système.
Une Historisation structurée et intelligentedes données du Data Lake. « OH Non ! Il a dit « structuré » et « Data Lake » dans la même phrase le monsieur, c’est pas joli ». Malheureusement, beaucoup d’entreprises oublient cette étape. Mais pourquoi donc ? Suivez par exemple ici (encore désolé…) la modélisation Data Vault 2.0, je parle principalement des concepts de Hubs, Links, Satellites, ou au moins la philosophie pour cette partie. Vous pouvez éventuellement exclure de cette phase certaines données exceptionnelles (par exemple si ce sont des données vraiment peu utilisées très spécialisées, que vous savez ponctuelles comme des données externes one shot (que vous n’achetez pas tous les mois…).
!!! Attention je ne dis pas qu’il faut faire un Data Warehouse d’entreprise dans le Data Lake (je ne rentrerai pas dans ce débat). Le Data Lake doit couvrir un certain nombre de cas d’usage spécifiques, qui nécessitent d’historiser (avec agilité !) un certain périmètre de données, qui tend à grandir au fur à mesure que les nouveaux cas d’usages apparaissent.
Si vous vous arrêtez aux Raw Data et aux business View et que vous ne mettez rien entre les deux, que vous ne faites pas ce travail de structuration fonctionnelle, au bout d’un moment vous aurez un gros sac de données applicatives, et les Data Scientists et autres utilisateurs devront eux même comprendre la logique de recoupement de toutes les sources (notamment le grain, la définition des clés techniques/métiers, etc.). Faites ce travail de structuration de l’historisation (DataVault 2.0 recèle de bonnes idées).
Les données préparées pour être prêtes à l’Usage (Business View), requêtables rapidement pour usages business. C’est dans la consolidation de chacun de ces socles que les règles métiers sont appliquées ! Ici, On ramène les données au plus proche de l’usage et structurées pour l’usage en question. Et n’hésitez pas à dé-normaliser vos Business View! Vous n’êtes pas dans mysql… Plein de lignes et plein de colonnes ? C’est fait pour ! Vous pouvez même aller (dans certains cas) jusqu’à pré-calculer dans une grosse table adaptée tous les indicateurs sur toutes les combinaison de segments (dimensions), de périodes, de dates… (attention, intérêt à mesurer par rapport à votre propre usage de consommation de la donnée), mais ça se fait : « ouahou ! comme les graphiques s’affiche vite… »
Les métadonnées : leur intégration peut se faire de diverses manières, mais faites en sorte que les gens ait confiance aux données qu’ils utilisent (C’est quoi cette donnée ? d’où vient la donnée ? quelle application, quel fichier source ? Qui l’a saisie ? Quand l’a-t-on intégré au Data Lake ? quelle fréquence de mise à jour ? etc.)
3 – Comment on rend la valeur de l’outil palpable par l’utilisateur final ?
Ne croyez pas (et je suis sûr que vous ne le croyez pas) que votre Data Lake se suffit à lui même
S’il est déjà bien structuré (c’est déjà un gros avantage), il a quand même besoin de belles décorations :
je ne vous apprendrai rien : un outil de Data Viz/report qui plaît au métier (parce qu’il a été impliqué dans son choix…). Je ne ferai pas de pubs ici…
Une bonne intégration avec les systèmes opérationnels et dans les deux sens (un savoir faire sur le sujet), pas qu’en collecte. Par exemple : Lancer des simulations directement depuis mon application de gestion qui va lancer un job spark sur la business view associée qui elle va renvoyer des résultats en un rien de temps sur l’application de gestion : L’utilisateur est heureux, il ne connaît pas Hadoop ou Spark, il ne veut rien en savoir, mais vous avez amélioré significativement sa façon de travailler. C’est ce qu’il faut viser. C’est cela aller au bout de l’usage.
Un environnement complet d’analyse pour vos Data Scientist (Data Viz, développement IDE, collaboration/gestion de version, notebooks, les bonnes librairies de dev !) parce qu’ils en ont besoin. Impliquez réellement les principales personnes concernées dans ce choix !
Pour conclure, les idées clés :
Les usages doivent toujours driver la construction itérative de votre Data Lake
Ne cherchez pas à refaire un/des Data Warehouse 2 sans vraiment savoir par qui, pour quoi ce sera utilisé, ne cherchez pas à manger un maximum de données pour devenir le plus vite possible la plus grosse base de données et justifier le nom de votre équipe, BIG Data, j’imagine…
Si on vous pousse un usage auquel on pourrait répondre sur une base mysql, redirigez gentiment le destinateur…A moins que vous soyez force de proposition pour faire évoluer son usage pour justifier l’utilisation d’une telle plateforme.
Si vous êtes assez matures, ne voyez plus votre Data Lake comme un Lab collecteur qui se suffit à lui-même, si vous allez au bout des usages, vous serez obligés de l’intégrer avec des applications métier (vous savez, l’utilisateur qui clique dans son appli et ça lui sort toute sa simulation en 0.5 secondes…).
Inspirez-vous de la philosophie de monsieur Data Vault 2.0 (Dan linstedt) (je ne dis pas qu’il faut tout prendre, mais au moins inspirez vous des concepts de Hub / Links / Satellites qu’un enfant de 4 ans peut comprendre pour une structuration agile de l’historique de vos données). Cela évitera bien des noeuds au cerveau à vos utilisateurs, Data Engineer et Data Scientist, et cela apportera de l’agilité au bout du compte.
Dé-normaliser vos vues métiers ! Dénormalisez vos étoiles, vos 3NF, ça ira bien plus vite !
Le Data Scientist « Stateu » doit ouvrir les yeux au Data Scientist « Informaticien » sur ce qu’il est vraiment en train de faire tourner. Le Data Scientist « informaticien » doit apprendre au Data Scientist trop « stateu » à produire du code industrialisable et réutilisable. Recrutez les deux types de profils (Ecoles de stats, et école d’ingé informatique)
Si vous faites collaborer vos Data Scientist avec les équipes de développements des applications métiers, alors c’est que vous êtes sur les bons usages…
Les APIs sont omniprésentes. Les métiers en demandent car elles promettent les plus belles perspectives commerciales, des effets boules de neige et de la démultiplication de valeur. Les consultants ne jurent que par cette solution. Pas un schéma d’architecture sans que l’API Gateway ne règne en maitresse, ayant comblé le moindre interstice entre les applications et s‘érigeant en barrière impérieuse entre les deux mondes du Legacy et des frontaux Web, chantre et cœur de l’IT bi-modal.
Obnubilé par les promesses de l’API management, la réflexion sur le bien-fondé de l’utilisation d’un échange synchrone est morte née.
Votre direction a donc investi (cher) et la cellule d’architecture applique une stratégie d’API par défaut.
Mais obnubilé par les promesses bien connues de l’API Management, la réflexion sur le bien-fondé de l’utilisation d’un échange synchrone est passée au second plan. Tout comme la SOA avait imposé ses Web-Services pour des raisons de vitesse de propagation, l’API Management assoit sa domination sur sa supériorité technologique pour l’exposition à l’ensemble des partenaires.
Les échanges synchrones n’offrent aucun mécanisme efficient de reprise des erreurs.
On en oublie une caractéristique et une limite intrinsèque à ce type de flux. Les échanges synchrones ne se justifient en effet que quand une réponse (et donc un aller-retour) est nécessaire, et ils imposent en contrepartie un couplage fort entre l’appelant et l’appelé, l’échange ne pouvant pas aboutir si l’appelé n’est pas disponible au moment précis de l’appel. Les échanges synchrones n’offrent ainsi aucun mécanisme efficient de reprise des erreurs techniques (des retry toutes les 5 secondes ? Pendant 1 heure par exemple ? avec de plus en plus de services qui ne répondent plus… ? Autant sortir les arva® et attendre le Saint Bernard).
On tombe ainsi dans des cas où le rejeu devient très gênant et où la responsabilité de ce rejeu est déporté vers l’appelant alors que son message était correctement émis, correctement formaté et qu’il ne tire aucun bénéfice de l’acquittement HTTP qui lui reviendra. On rencontrera particulièrement ce cas sur des appels visant à créer ou modifier des données. Qui est responsable du rejeu d’une fonction POST ou PUT tombée en erreur ? Pour peu que le partenaire appelant soit une application SaaS, un logiciel propriétaire voire pire un partenaire B2B, on se retrouve dans une impasse.
Les échanges asynchrones et leur pattern publish-subscribe apportent par construction une extrême résilience à ce type d’incident en persistant les messages et en laissant les destinataires maitres de leur rythme de consommation. Ajouter à cela la grande facilité de paramétrage d’une nouvelle cible -là ou une plateforme d’API demandera une nouvelle règle de routage- et l’on retrouve pourquoi les solutions asynchrones sont des impératifs d’un SI bien structuré.
Il serait bien trop limitant de se passer d’un portail d’API et de l’accessibilité externe qu’il offre.
Favoriser l’asynchronisme est un bon principe de conception de flux.
Si l’échange est unidirectionnel, que la donnée peut être stockée chez le consommateur et que la fréquence de modification n’est pas trop importante, oubliez le synchronisme, rendez sa liberté au fournisseur d’information et appuyez-vous sur votre MOM ou EAI !
Pour autant il serait bien trop limitant de se passer d’un Portail d’API et de l’accessibilité externe qu’il offre. La facilité d’exposition offerte par ces solutions est sans pareil sur le marché actuel.
Appliquez-vous donc à construire un système hybride. Pensez l’API Gateway, et le package HTTP, REST et JSON comme un connecteur, une porte d’entrée sur votre SI, et débrayez immédiatement derrière sur une solution de bus de messages (MOM ou EAI) dès que cela est sensé.
En cassant la chaine du synchronisme on récupère la souplesse souhaitée, en maintenant la Gateway en frontal on conserve l’ouverture et la facilité d’utilisation.
Architecture d’entreprise et agilité – chap 4 : comment les architectes d’entreprise peuvent interagir avec l’agilité ?
En tant qu’architecte, quelle posture adopter face à un projet Agile ? Et dans le cadre plus global d’une entreprise Agile, comment est intégrée la notion d’architecture ? Quel rôle est dévolu à la fonction Architecture ?
Les principaux frameworks d’agilité à l’échelle intègrent l’architecture d’entreprise : DAD – Disciplined Agile Delivery-, SAFe – Scaled Agile Framework- et LeSS – Large Scaled Scrum.
Que nous manque-t-il alors pour vraiment travailler ensemble ?
Les architectes et l’agilité se connaissent !
D’un côté, les architectes ont travaillé à l’évolution de leurs pratiques et regardent l’agilité avec intérêt depuis plusieurs années déjà : article de 2008, article de 2010, conférence de l’Agile Tour en 2011, etc… Ils ont inventé la « Continuous Architecture »
La « Continuous Architecture » énonce des principes facilitant l’interaction avec les projets en agilité. Ces principes mettent en avant l’adaptation et l’intelligence qui doivent guider les travaux des architectes pour convenir au rythme et au fonctionnement des projets Agiles.
Voici quelques principes de « Continuous Architecture » qu’il est intéressant de noter : partager les décisions, partager l’information, être collaboratif, etc …
D’un autre côté, les framework d’agilité à l’échelle les plus connus (DAD, LeSS ou SAFe par exemple) ont pris en compte les architectes dans leurs modes opératoires. Des définitions de l’architecture sont proposées. Les livrables et interactions des architectes avec les projets / programmes agiles sont définis.
Quelles questions restent donc à traiter pour que les 2 travaillent en symbiose ?
Une bonne définition de l’architecture d’entreprise dans l’agilité
Les définitions proposées par les frameworks d’agilité à l’échelle reprennent les éléments essentiels de l’Architecture d’Entreprise :
Vision long terme et à haut niveau de la transformation de l’entreprise,
Réutilisation,
Interaction avec les projets,
etc…
Des exemples concrets mettent en avant les apports de l’architecture dans le cycle de vie d’un produit Agile. DAD a un chapitre « Pourquoi l’Architecture d’Entreprise » qui décrit les apports essentiels de l’architecture d’Entreprise pour les projets comme de pouvoir se concentrer sur la valeur ajoutée et une plus grande cohérence dans les solutions.
L’architecture devient agile – forcément
Les frameworks mettent en avant des principes d’agilité que les architectes se doivent de respecter. Ainsi SAFe recommande aux architectes de bien rester en contact avec les activités journalières de développement et les équipes projets. De ce rapprochement, un gain mutuel de confiance est espéré : les architectes auront plus confiance dans les équipes projet pour suivre les cadres d’architecture, les équipes projet auront plus confiance dans les solutions proposées par les architectes.
Pour être en conformité avec les principes agiles, on remarquera que dans DAD, tous les livrables de l’Architecture sont sujets à des feedbacks (retours d’expérience). Il n’y a pas de décision unilatérale. L’architecture est dans un processus permanent de discussion et d’évolution.
Continous architecture – l’architecture agile
Pour se mettre en accord avec les concepts de l’agilité, l’architecture d’entreprise a énoncé un certain nombre de recommandations. L’une d’elles est justement de donner des principes d’architecture et non des règles !
Une autre de ces recommandations consiste à prendre les décisions le plus tard possible, laissant aux projets la possibilité d’étudier plusieurs solutions avant de trancher quand vraiment il le faut.
Une autre recommandation consiste à dire « il faut partager de l’information et non de la documentation », nous rappelle la discussion du chapitre 2 de cette série d’article. En d’autres termes et pour citer le manifeste Agile : les individus et leurs interactions plutôt que les processus et les outils.
Mais parfois l’Architecture semble quand même trop éloignée des préoccupations des projets…
Less et les architectes powerpoint vs les master programmers
Le framework LeSS, dans son chapitre sur Architecture & design, consacre son introduction à préciser que l’architecture de l’informatique est dans le code : ceux qui font sont ceux qui savent. Les architectes qui ne font plus du code mais font de l’architecture pour les managers ou de l’architecture pour de l’architecture finissent par se couper du monde et ne plus être entendus par les projets. Ils deviennent des « Architectes PowerPoint dans leur tour d’ivoire ».
Même si tous les architectes, qui plus est dans les grandes entreprises, ne peuvent pas rester au contact du code (qui plus en est quand la politique d’entreprise est centrée sur l’intégration de progiciels plutôt que la conception d’applications), il est de leur devoir d’interagir avec les architectes plus opérationnels et de veiller à ce que leurs travaux restent compréhensibles par tous. Et bien sûr applicables !
LeSS rappelle que le principal intérêt d’un modèle est la discussion que l’on a en faisant ce modèle. Le modèle n’est pas la solution et ne doit pas rester figé dans le temps.
Ces images illustrent la différence entre ce qui a été proposé (chemin goudronné) et les usages (chemin tracé par le passage des piétons)
Coaching et agilité ?
La transformation vers l’entreprise agile se fait beaucoup à partir de coaching des équipes et des managers. Ils sont accompagnés dans une réelle évolution de leurs pratiques afin de développer des modes de travail plus collaboratifs et les conditions d’une meilleure coopération.
En général, des coachs agiles interviennent pour faire évoluer ces pratiques et accélérer la transformation. Il faut alors qu’un mode de fonctionnement soit établi et les parties prenantes (comme les architectes) impliquées dans ces transformations.
Les architectes doivent donc être inclus dans ces transformations afin de bien mettre en place les modes de fonctionnement adaptés à chaque entreprise.
Les architectes doivent-ils être certifiés SCRUM Master ou Product Owner ? Doivent-ils être formés aux frameworks d’agilité à l’échelle comme DAD, LeSS ou SAFe ? Doivent-ils être accompagnés de coachs agiles ?
Suivant la transformation en cours, chaque entreprise devra apporter sa réponse. Que cela soit pour les architectes ou d’autres fonctions d’ailleurs !
Pour que l’architecture d’entreprise et l’agilité puissent travailler ensemble, il faut que l’entreprise s’approprie l’un et l’autre et pense bien à les faire travailler ensemble. La communication est un élément clé de cette réussite.
L’architecture d’Entreprise doit être un facteur facilitateur de l’agilité car elle apporte une vision partagée de la stratégie d’évolution du SI et doit donc servir à guider l’ensemble des travaux de l’entreprise sur son SI.
Dans le chapitre suivant, nous parlerons de l’évolution d’un des travaux majeurs des Architectes, le Schéma Directeur du SI.
La révolution digitale est bien en route ! Les Chief Digital Officer ne se comptent plus et Node.JS est désormais partout. Toutes les entreprises, même celles orientées B2B, renouvellent sans cesse leurs frontaux clients et autres applications mobiles afin de satisfaire des utilisateurs toujours plus exigeants.
Un DSI qui se fierait uniquement à toutes ces interfaces dernier cri (responsive design, flat design, progressive webApp…) aurait de quoi paniquer : « Chez Plouf, nous sommes très en retard, il faut tout refaire au sein du SI pour pouvoir construire ce type d’interface » !
Doit-on réellement s’affoler ?
Même si depuis l’extérieur c’est une magnifique voiture de sport qui apparaît, lorsque l’on soulève le capot, on tombe bien souvent encore sur un moteur de 4L (voire de Traction !).
En effet, la majorité des sociétés ayant déjà mis en place des frontaux modernes n’ont pas eu le temps et/ou l’argent (et parfois la volonté) pour moderniser l’ensemble de leur système d’information.
De la magie alors ? Pas tout à fait !
Les frontaux mis en place ne servent en réalité que d’interface utilisateur et les données affichées sont des copies de celles contenues dans les systèmes de gestion. Au mieux, celles-ci sont copiées dans un Data Lake / Data hub avec une couche d’API qui permet de les exposer, au pire elles sont copiées dans une base propre à chaque frontal sans forcément de réflexion sur la gouvernance de ces données (lignage, source(s), qualité, fraicheur – vérité à un instant t, cycle de vie, …).
Dans bien des cas, la mise en place de ces interfaces utilisateur peut se faire car elles se basent quasi-uniquement sur de la consommation de données. Or lorsque les données sont disponibles, il n’est pas extrêmement complexe de monter des frontaux modernes en utilisant les dernières technologies.
Cependant, un certain nombre de problèmes peut subsister, notamment lorsque ces frontaux sont utilisés pour modifier des données qui doivent être prises en compte dans les systèmes de gestion. C’est en effet ces systèmes qui gèrent la complexité des règles métiers, de la qualité des données et ce sont ces mêmes systèmes que l’on ne sait pas remplacer facilement par des outils modernes.
Quels sont donc les principaux points d’attention à surveiller lorsque l’on souhaite mettre en place ce type de frontal digital orienté utilisateur final ?
Définir les cas d’usage, les données attendues associées et la fréquence d’utilisation. Cela permet notamment de :
Dimensionner les solutions à mettre en place (exposition de service par une « application », nécessité de monter un Data Hub pour déporter un grand volume de consultations…).
Vérifier que le nouveau frontal s’intègre bien dans la gouvernance de données, que la traçabilité des données est bien assurée.
Limiter les actions directes sur les données depuis le portail et privilégier la collecte de demandes à traiter en asynchrone au fil de l’eau.
Le portail ne doit être qu’un point de collecte de demandes qui seront transmises et traitées en aval par les systèmes de production en fonction de leurs capacités.
Centraliser les données au sein d’un Data Hub plutôt que de multiplier les copies de bases. Les nouvelles technologies permettent d’allier volumétrie importante et haute performance.
La mise en place d’API (et d’une plateforme d’API management) permet également de découpler les frontaux du reste du SI. Ainsi, la poursuite de la modernisation du SI pourra se faire en limitant les impacts sur les « applications digitales » (et sur le reste du SI). De plus, les API sont aujourd’hui particulièrement efficientes pour les cas de consultation / recherche de données.
Notons tout de même que malgré un découplage bien pensé, on ne pourra pas éviter tous les impacts. Lorsqu’il y a des évolutions structurelles, tous les éléments d’un SI sont susceptibles d’être impactés. Les frontaux modernes développés sur des technologies aujourd’hui matures, restent toutefois relativement facilement évolutifs.
Les frontaux digitaux sont les principaux vecteurs de l’image d’une entreprise vers le monde extérieur. Il est donc primordial de leur accorder de l’importance.
Pour autant, doit-on s’arrêter là ? Probablement pas !
Ces nouveaux usages permettent de développer d’autres pratiques :
Les frontaux digitaux peuvent également avoir une forte plus-value pour des usages internes. Ils évitent les connexions à de multiples applications hétérogènes qui finissent par user les collaborateurs. Lorsque c’est pertinent, le développement de solutions digitales internes pour les collaborateurs est intéressant en termes de UX mais aussi de rationalisation SI.
Les API mises en place pour ces frontaux peuvent éventuellement être exposées à l’extérieur et ainsi être valorisées. Des partenaires, des clients ou des start-up peuvent réutiliser les API exposées et fournir indirectement aux usagers des services de l’entreprise d’une information « propriétaire » sur des canaux externes plus adaptés à ses besoins. Plus généralement, ces nouvelles technologies peuvent induire une transformation du « business model » ou répondre à de nouveaux besoins.
Pour les entreprises les plus avancées, la mise en place de ces frontaux est également l’occasion de profiter de ceux-ci pour faire du tracking du comportement / du parcours digital omni-canal de ses clients. Cette connaissance permet de personnaliser la relation avec un Client, de lui proposer une offre adaptée au bon moment ou de déclencher la Next Best Action quelle qu’elle soit.
On s’occupe uniquement des frontaux digitaux alors ?
Des frontaux dernière génération permettent de faire illusion auprès des utilisateurs et peuvent ainsi servir dans un bon nombre de cas de « cache-misère ». Si ces différents frontaux digitaux que l’on peut mettre en place améliorent le quotidien, il ne faut pas pour autant oublier de continuer la rénovation du reste du SI. Cela reste en effet bien souvent le « Legacy » qui soutient réellement les processus métier et les données de l’entreprise. Il est donc critique et mérite un effort de modernisation adéquate.
Optimiser la valeur de votre cartographie et de votre documentation avec nos bonnes pratiques![/chapo]
Dans notre monde complexe, la transformation permanente devient un principe de fonctionnement des entreprises. Celles-ci doivent alors choisir les changements qu’il est nécessaire d’implémenter et avec le plus de valeur ajoutée.
Pour faire les bons choix, la connaissance du fonctionnement de l’entreprise est incontournable. Cette connaissance doit être correctement structurée afin que chacun puisse trouver aisément les informations dont il a besoin.
Cartographie et documentation, définition
Une entreprise ne doit pas compter que sur les connaissances de ses employés. Certains peuvent partir et la connaissance qu’ils ont acquise sera alors perdue. Pour se prémunir contre cette perte, une organisation dispose de 2 outils, la cartographie et la documentation :
• La cartographie est une représentation sous forme de listes (des applications, des processus, etc.), de diagrammes et de matrices. • La documentation est l’ensemble de la production sous format type Office (PPT, Excel, Word, etc.) pérenne ou non, créée par des collaborateurs.
Ces deux outils doivent apporter de la valeur et être utiles, sinon ils seront sans intérêt et l’effort à fournir pour les construire et les garder à jour en vain.
La cartographie doit structurer la documentation
A partir de retours d’expériences sur la mise en place d’un système de cartographie et de documentation chez différents clients, la conclusion est que la cartographie et la documentation devraient être complémentaires et cohérentes.
La cartographie est de valeur car elle offre une vue globale et synthétique de l’entreprise selon plusieurs points de vue: stratégique, métier, fonctionnel, applicatif, technique, données, etc. Comme pour un plan de bâtiment, cela permet de connaître le rôle et la structure de chaque étage. Aussi utile soit-elle, cette vue globale n’explique pas comment chaque élément de l’entreprise fonctionne.
La documentation vient alors enrichir la cartographie grâce aux informations détaillées apportées sur chaque élément représenté. Les informations de l’entreprise sont collectées, classées, exploitées et diffusées grâce à la documentation. Elle est utile grâce aux réponses apportées aux différents besoins de connaissance pour assurer le fonctionnement opérationnel et pour mener les projets de transformation de l’entreprise.
Un intérêt certain, mais des freins importants
Malgré la nécessité de la cartographie et de la documentation, dans plus d’un cas, elles sont incohérentes, incomplètes ou caduques. La cause majeure des problèmes rencontrés est l’absence de principes structurants. Ceux-ci doivent apporter la cohérence entre ces deux parties, veiller à un apport réel de valeur et garantir que seulement ce qui est utile à l’entreprise est documenté et/ ou cartographié. En effet, un esprit frugal visant l’adéquation entre les besoins de l’entreprise et la cartographie et la documentation permet de se prémunir contre des efforts avec peu de valeur ou de pertinence.
Les principes régissant la cartographie sont : • Identifier la catégorie des informations (métier, fonctionnelle, applicative, etc.) • Organiser les informations par catégorie (métier, fonctionnel, applicatif, etc.), • Prendre, si possible, la stratégie comme point de départ de l’organisation de la cartographie • Puis structurer la cartographie par couches qui se déduisent l’une de la précédente.
Le schéma ci-dessous illustre la relation entre ces différentes couches qui composent l’entreprise :
Les principes régissant la documentation sont :
Définir les types de documents pour faciliter la classification
Identifier l’objet, le type et la pérennité de chaque document
Associer les documents pérennes à la cartographie à partir de l’objet décrit
Organiser les documents pérennes à partir de la cartographie
Ranger les documents projets par projet
A la fin d’un projet récupérer la documentation pérenne et la ranger selon les principes mentionnés ci-dessus.
Procédez par petits pas.
Le système de cartographie et de documentation peut être construit et géré comme un bâtiment :
Identifier les fondations : les principes structurants
Définir le projet de construction : le guide de modélisation et de documentation
Définir la structure globale du bâtiment : la cartographie synthétique et détaillée
Définir les systèmes utilitaires du bâtiment: les flux d’informations et les liens logiques entre les objets cartographiés
Décrire de manière détaillée chaque élément du bâtiment : la documentation des différents objets de la cartographie.
Gérer chaque projet de rénovation : de chaque projet de transformation récupérer les plans de transformations et les documents pérennes produits.
Les fondations sont les principes mentionnés et qui peuvent être adaptés et enrichis en fonction du contexte de chaque entreprise.
De la même manière que la construction d’un bâtiment doit être maîtrisée et la rénovation également, la construction de la cartographie et sa mise à jour doivent l’être également. Un guide de modélisation définit les règles de cartographie. Un référentiel d’architecture d’entreprise implémente ces règles et assure la maîtrise de la construction de la cartographie. Les différents niveaux sont liés entre eux et une cohérence globale existe entre les informations. Ainsi, la valeur apportée par la cartographie est mise à disposition du plus grand nombre de manière structurée et adaptable aux besoins diverses dans l’entreprise.
Si possible, le point de départ pour la construction de la cartographie devrait être la stratégie. A partir de celle-ci le métier de l’entreprise est décrit. La réalisation du métier engendre des besoins pour l’entreprise qui sont catégorisés dans une vue d’ensemble fonctionnelle. Comme le système informatique et technique de l’entreprise existe pour répondre aux besoins de l’entreprise, la vue d’ensemble fonctionnelle le structurera.
Chaque étage de la cartographie de haut niveau est ensuite décrit en détail et enrichi des échanges d’informations. L’identification des liens entre les différents étages de la cartographie vient compléter cette démarche et est implémentée dans le référentiel d’architecture d’entreprise.
Une fois la cartographie structurée et le référentiel d’architecture d’entreprise mis en place, la base d’organisation de la documentation pérenne est assurée. Les principes de structuration de celle-ci peuvent alors être mis en pratique. La documentation deviendra bien plus utile, grâce à une organisation qui a du sens et qui évite la recherche inutile des informations.
Pour les projets de transformation, le référentiel d’architecture d’entreprise doit servir de point d’entrée dans la phase de cadrage afin d’offrir une vision partagée et globale du fonctionnement de l’entreprise. Les documents liés à la vie du projet peuvent être gérés grâce au référentiel ou séparément. A la fin du projet les différentes transformations apportées par celui-ci seront reportées dans la cartographie et la documentation pérenne produite ou mise à jour y sera associée. Cette inclusion de la cartographie et de la documentation dans les processus projet fera que celles-ci ne seront réalisées qu’au niveau strictement nécessaire. Cela libère du temps pour réaliser le projet au lieu de passer son temps à le documenter.
Différentes méthodes d’optimisation, souvent complémentaires
Mettre en place un système de cartographie et de documentation est important. Par contre, sans l’optimiser et le garder à jour, il perd vite de son intérêt. La pérennité de ce système peut être assurée par des solutions complémentaires comme l’agilité, le Lean ou le principe 5S.
Le principe 5S facilite l’ordre mais aussi la rigueur afin de prévenir les écarts.
Il préconise de structurer un système par catégories d’éléments, d’identifier les anomalies et de viser toujours la rigueur. Ainsi, 5S permet à partir des principes sur la cartographie et sur la documentation de constituer des systèmes ordonnés et cohérents. Cet ordre met en lumière ce qui est en double et réduit le temps de recherche de l’information. Par contre, 5S ne répond pas au besoin de cartographier et de documenter seulement ce qui est demandé.
Le Lean vient alors comme solution au problème de cartographier et de documenter le juste nécessaire. En effet, son principe de base est d’ajuster la production à la demande. Le Lean propose de regarder ce qui est demandé le plus, par qui, et pour quelle raison et s’organiser en conséquence. L’audit des chaînes de production documentaire et de cartographie fait ressortir ces éléments. Ainsi, le système de cartographie et de documentation déjà ordonné par le 5S, se voit allégé au juste nécessaire avec des temps de production optimisés.
L’agilité apporte une perspective orientée valeur des documents et de la cartographie. Seules les cartographies et les documents apportant le plus de valeur perdurent et sont traités en priorité. Au lieu de tout garder à jour comme parfois demandé, l’effort documentaire est concentré sur ce qui apporte le plus de valeur.
Ensemble, ces trois méthodes produisent un système ordonné par le 5S, rendu pertinent et accéléré grâce au Lean, et optimisé en termes de valeur grâce à l’agilité.
Pour conclure, la cartographie et la documentation doivent former un tout cohérent. Elles sont régies par des principes différents qui visent à la fois l’apport de valeur et limitent l’effort à ce qui est utile. Ce système se construit petit à petit comme un bâtiment. La maîtrise des impacts de la transformation de l’entreprise sur la documentation et sur la cartographie est réalisée grâce à un bon référentiel d’architecture d’entreprise et une démarche optimisée mêlant l’agilité, le Lean et le 5S.
Ensemble, la cartographie et la documentation cohérentes facilitent la réduction du time-to-market et l’élimination des redondances par une information structurée et rapide d’accès.
