Elle est au rendez-vous de presque l’ensemble des salons, conférences, webinar ou encore pause-café avant les premières réunions de la semaine et tend à devenir le principe clef dans l’intégration ou la mise en place d‘une plateforme data : La gouvernance de données.
Le mot peut paraître abstrait, brutal et directif mais tout l’enjeu est justement de la vulgariser un maximum pour la partager et évangéliser son adoption.
Il faut bien avoir conscience que si vous rencontrez des incidents liés à la qualité, la cohérence ou la fiabilité de vos données aujourd’hui c’est probablement lié soit à un manque de gouvernance soit à un manque de suivi de cette gouvernance.
Parce que mettre en place une plateforme permettant de brasser des Tera de data c’est bien mais le faire avec des principes clefs et des règles de sécurités c’est mieux, nous allons voir quelques notions clefs pour pouvoir mettre en place une gouvernance réussie.
Dans 76% des cas, la gouvernance existe mais elle est vite négligée au profit du time to market conduisant souvent à une perte de confiance des sponsors voir du déficit commercial.
Kezako la gouvernance de données ?
Sortant d’une mission de presque 6 ans sur le SI Data Architecture & Engineering chez Givaudan, je vais tenter de vous en donner ma définition et ma vision afin de vous familiariser avec le sujet.
Tout en ayant conscience qu’il n’est pas aisé de donner une définition simple de la gouvernance de données sans tomber dans un premier travers qui est sa mécompréhension conduisant inévitablement à sa dévalorisation puis sa négligence, je tente quand même ma chance :
Au-delà d’un simple ensemble de règles ou d’un outil, d’un concept ou d’une méthodologie, la gouvernance est un cadre stratégique qui regroupe à la fois l’ensemble des principes humains et machines liés aux acteurs de la data mais aussi la garantie du respect des normes et processus liés à l’utilisation de ces données.
Elle regroupe l’ensemble des pratiques et processus permettant de créer, maintenir, sécuriser et faire évoluer l’ensemble des data et metadata d’un SI.
C’est à la fois une déclinaison du RACI lié à la plateforme data et en même temps l’implémentation de ses règles de maintenance et d’utilisation. Le tout n’étant pas exclusif à la plateforme Data, mais doit s’inscrire dans la gouvernance SI dans son entièreté.
La gouvernance de données ne décrit pas uniquement la gestion de la donnée mais la politique contribuant à la manipuler et les responsabilités de chacun afin d’éviter les imbroglios de qui ou quel job a maintenu quoi, comment et pourquoi ?
Et c’est un point crucial à mettre en place dès l’introduction d’une nouvelle typologie de données en nommant un ou des responsables de la gouvernance de cette donnée qui auront la charge de documenter et garantir les règles d’ingestion, d’accès, d’enrichissement, dédoublonnage, maintenance, diffusion pour en citer quelques unes et en les faisant évoluer au grès de la politique d’entreprise.
Qu’est qui ne fait pas partie de la gouvernance de données ?
La gouvernance n’oriente pas les choix de plateformes, la mise en place d’une infrastructure. Elle n’est pas une composante de l’analyse d’une donnée ou dans le choix d’un scénario projet.
Pourquoi la gouvernance ?
Vous l’aurez compris quand le sujet traite de politique cela fait souvent vite fuir le business qui sera pourtant l’atout clé dans l’évangélisation de la pratique.
Les problèmes liés à un manque de gouvernance ont souvent pour résultat une initiative prise hors du champ de responsabilité ou un manque de clarté amenant des interprétations diverses voire faussées.
Les principaux piliers clefs permettant d’apporter un ROI notable de la gouvernance sont selon moi :
La Gestion et maintenance des métadonnées : Pour vulgariser un temps soit peu, les métadonnées sont le passeport des données. Les bonnes pratiques consistent à définir un modèle de métadonnées, à documenter les données et à mettre en place un catalogue de données.
Qualité des données : La qualité est essentielle pour prendre des décisions business éclairées. Les bonnes pratiques incluent la mise en place de processus de validation, l’utilisation d’outils de profilage et de nettoyage, et la définition de métriques de qualité.
Sécurité : La protection des données est une priorité absolue. Les bonnes pratiques consistent à mettre en place des contrôles d’accès, à chiffrer les données sensibles, à réaliser des sauvegardes régulières et à mener des audits de sécurité.
Conformité : protocol sécurisé d’échanges de données HIPP / instances réglementaires lié au stockage et à l’utilisation de la donnée.Le respect des réglementations est obligatoire. Les bonnes pratiques incluent la connaissance des réglementations applicables, la mise en place de processus de conformité et la désignation d’un responsable de la protection des données.
Politique et Standards: partager un socle de définition des données clefs de l’entreprise
Fiabilité : garantir la véracité d’une donnée à n’importe quel moment et n’importe quel endroit du SI
Et dans la pratique ça donne quoi ?
Tout d’abord, vous devrez avoir en tête les étapes clés pour pouvoir définir le cycle de vie de la gouvernance :
Obtenir le soutien de la direction : La gouvernance des données est un projet d’entreprise qui nécessite l’engagement de tous les niveaux hiérarchiques.
Effectuer un audit des données existantes : Identifier les manques et les redondances pour déterminer les axes de transformations.
Définir une stratégie: Aligner la gouvernance avec les objectifs de l’entreprise.
Mettre en place un comité de gouvernance : Définir les rôles et les responsabilités de chaque acteur.
Sensibiliser les utilisateurs : Former les collaborateurs à l’importance de la gouvernance.
S’en suivent les bonnes pratiques pour s’assurer d’une mise en oeuvre efficace :
Impliquer les métiers : Les utilisateurs finaux doivent être impliqués dans la définition des règles de gouvernance.
Utiliser des outils adaptés : Choisir des outils de gouvernance qui répondent aux besoins spécifiques de l’entreprise.
Adopter une approche agile : La gouvernance doit être évolutive et s’adapter aux changements de l’entreprise.
Mesurer la performance : Définir des indicateurs clés de performance (KPI) pour évaluer l’efficacité de la gouvernance.
Les bénéfices de la gouvernance des données
Amélioration de la prise de décision : Les données fiables et accessibles permettent de prendre des décisions plus éclairées et de réduire les risques.
Augmentation de la productivité : Les équipes passent moins de temps à chercher des données et peuvent se concentrer sur des tâches à plus forte valeur ajoutée.
Réduction des coûts : La gouvernance permet d’éviter les erreurs coûteuses et d’optimiser l’utilisation des ressources.
Amélioration de la réputation : Une bonne gouvernance des données renforce la confiance des clients et des partenaires.
Les défis et les tendances
Les défis :
La complexité des environnements de données : Big data, cloud, IoT.
La résistance au changement : Impliquer les utilisateurs peut être difficile.
Le coût des investissements : La mise en œuvre d’une gouvernance peut représenter un coût important.
Les tendances :
L’IA au service de la gouvernance : L’intelligence artificielle peut automatiser certaines tâches de gouvernance.
La gouvernance des données dans le cloud : Les enjeux spécifiques du cloud.
La gouvernance des données personnelles : Le respect des réglementations comme le RGPD.
La gouvernance des données est un voyage, pas une destination. Elle nécessite un engagement continu de la part de tous les acteurs de l’entreprise. En suivant les bonnes pratiques et en s’adaptant aux évolutions technologiques, les entreprises peuvent tirer pleinement parti de leurs données et gagner en compétitivité.
Nous vous accompagnons dans le pilotage de votre architecture
18 décembre 2024
– 3 minutes de lecture
Architecture
Olivier Constant
Senior Manager Architecture
Nous vous accompagnons dans le pilotage de votre architecture
Aujourd’hui, nous repartageons une success story de notre mission chez un acteur majeur du secteur bancaire. Olivier et ses équipes sont intervenus pour accompagner de façon globale ce client sur son architecture d’entreprise au travers d’un centre de services.
N’hésitez pas à nous contacter pour plus d’informations ! 💬
Les autres sucess story qui peuvent vous intéresser
Stoplight est un outil de conception d’API qui permet aux développeurs de créer, de documenter et de tester des API de manière efficace et collaborative. Il embarque les fonctionnalités que l’on retrouve en partie sur les outils accélérateurs de développement d’API tels que Postman, SoapUI ou encore l’écosystème Swagger.
Quelles sont les caractéristiques spécifiques de l’outil et ses limites le cas échéant ?
Comment se positionne-t-il par rapport à des outils implémentant des fonctions comparables ?
Pexels – Thisisengeneering
Étape 1 : Créer un nouveau projet
Stoplight permet de créer de nouveaux projets sous la spécification OpenAPI. A noter que GraphQL ou AsyncAPI ne sont pas encore supportés. L’outil pouvant s’interfacer avec GitLab, GitHub, BitBucket ou encore Azure DevOps, il est aussi possible d’importer des projets existants.
Étape 2 : Définir l’API
Une fois le projet créé, il faut maintenant définir notre API. Il est possible soit de la créer (fichier format JSON ou YAML), soit d’importer un fichier de spécification OpenAPI, ou une collection Postman. Diverses versions d’OpenAPI sont supportées (2.0, 3.0 et 3.1 à l’heure de la rédaction de cet article).
On pourra définir des modèles d’objets communs à notre projet ou spécifiques à une API. L’édition des endpoints, des paramètres et des réponses se fera facilement soit en utilisant la vue formulaire, soit la vue code, dans tous les cas avec une preview en temps réel.
Pour bien garder à jour notre projet, en se branchant par exemple à GitHub, il est possible de configurer les échanges souhaités et ainsi de mettre à jour l’API à chaque changement de Git et vice-versa.
Étape 3 : Linter l’API
Le linting d’une API est une analyse de son code pour faire remonter des erreurs, warnings et incohérences, à la manière d’un compilateur.
Stoplight propose des style guides de linting par défaut qu’on peut ensuite modifier ou importer. Ces règles seront utilisées pour l’outil de linting intégré basé sur Spectral.
Cela permet de vérifier que la définition de l’API correspond aux bonnes pratiques du marché et aux méthodes spécifiques à l’entreprise.
La configuration du linting est évidemment modifiable à souhait. On pourra ainsi garantir plus facilement une cohérence accrue entre des API qui auraient été faites par diverses personnes, ainsi que réduire le nombre d’erreurs. D’où finalement une API de meilleure qualité.
Étape 4 : Documenter l’API
La documentation de l’API dans Stoplight est gérée via le composant open source Elements intégré à la plateforme. Suivant la spécification OpenAPI, on pourra facilement créer la documentation des endpoints, des réponses, le tout avec un environnement interactif et non figé.
De plus, Stoplight supporte les fichiers Markdown (dans l’onglet Docs) permettant de documenter l’API davantage. Cela offre la possibilité d’y intégrer du contenu non textuel : tableaux, images, diagrammes Mermaid ou contenu d’autres sites (Twitter, Youtube, Giphy, Spotify, etc.). La documentation n’en sera que plus riche et la découverte de votre API facilitée, d’où une meilleure adoption.
Étape 5 : Tester, sécuriser et déployer l’API
Il est possible de tester l’API à l’aide de fonctionnalités nativement intégrées dans l’outil. Ainsi la vérification de contrat sera t-elle automatique via le cross checking de la spécification Open API.
Stoplight propose une interface à travers laquelle écrire et exécuter des tests pour évaluer la réponse de chaque endpoint et méthode. Il est également possible d’utiliser le module Prism pour simuler les appels, dans un environnement de test minimal intégré.
La plateforme supporte les méthodes d’autorisation OAuth2 et OpenIDConnect. L’outil met à disposition une interface dans laquelle il est ainsi possible de déclarer la modalité de contrôle utilisée, le flow et les paramètres évalués (clé d’API, token, credentials)
Enfin l’outil intègre également l’utilitaire de ligne de commande NPM et permet de pousser les mises à jour d’une API sur l’interface de navigation de Stoplight. L’API sera alors sur le Studio Web.
Étape 6 : Générer du code
Une fois l’API testée et validée, vous pouvez utiliser Stoplight pour générer du code serveur et client à partir de votre définition d’API. En effet la plateforme est équipée d’un générateur de code (stubs serveur, configuration…) supportant plusieurs langages de programmation (notamment Java, JavaScript…).
Les capacités de Stoplight à l’heure de la rédaction de cet article sont cependant plus focalisées sur la documentation et les features de collaboration, et sont plus limitées sur la génération de code que celles d’un Swagger Codegen par exemple.
On peut noter pour conclure que Stoplight est un outil avec une couverture relativement large des fonctionnalités de conception et de construction d’une API. Il supporte également les standards d’implémentation en la matière (norme OpenAPI, flux de sécurisation avec OAuth et OIDC…).
Il répond de manière plus complète à des besoins en amont de conception et de développement. Cependant, il présente des limites. Il offre également une couverture moins importante sur des fonctions plus aval, telles que la publication et le contrôle plus fin d’accès à des ressources exposées par API.
A notre niveau de cabinet de conseil et d’architecture des SI, il nous paraît indispensable d’ajouter notre pierre à cet édifice. D’autant que les précités n’ont pas tout dit…
Le Numérique Durable: pourquoi faire ?
On le dit et le redit et c’est bien le sous titre de notre travail : L’architecture est “Green by design”. En effet, depuis longtemps les architectes construisent des SI solides, non redondants donc sobres en fait…
Sans compter le temps passé à challenger les métiers sur leurs besoins. Et à éviter les travaux inutiles… Faire et défaire c’est du travail inutile et si on peut éviter c’est toujours ça d’économisé…
4 grands thèmes qui ne sont pas propres à l’architecture
Nous avons voulu que notre travail puisse être adapté en tant que guide à beaucoup d’expertise en plus de l’architecture :
Gouverner et former : qu’est ce que votre expertise / discipline / domaine de compétences peut mettre en place dans sa gouvernance et dans la formation des personnes pour intégrer les dimensions de responsable et de durable ?
Mesurer et montrer : que va-t-on pouvoir mesurer dans votre discipline et quels résultats va-t-on pouvoir montrer ?
Challenger : quels sont les thèmes ou autres domaines sur lesquels vous allez pouvoir challenger pour aller vers la diffusion des bonnes pratiques ?
Concevoir : quelles sont les bonnes pratiques lors de vos travaux de conception qui peuvent permettre d’aller vers plus de durabilité ?
Les architectes au coeur du Système d’Information
Le travail des architectes est on le rappelle ci-dessous :
L’Architecture d’Entreprise organise le dialogue entre les différents corps de métier pour définir une vision commune de l’entreprise de demain et de son SI, ainsi que la trajectoire pour y parvenir. Elle met en œuvre les approches nécessaires pour assurer la connaissance, la gouvernance et le pilotage opérationnel du SI.
A ce titre, les architectes sont au coeur des SI et des transformations et doivent donc jouer un rôle d’influenceur dans la direction du Numérique Durable. Ce guide est là pour fournir des clés à cette population particulière.
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.
