La Data a le vent en poupe. Le monde du digital vous impose de travailler à partir de vos données et il devient de plus en plus exigeant avec celles-ci. Vous avez donc besoin d’augmenter* la valeur propre de vos données (niveau de qualité, accessibilité, connaissance…) afin d’optimiser des usages existants, ou pour répondre à de nouveaux usages et gagner les opportunités business qui assureront le développement de votre entreprise.
La data, un vaste sujet
La direction a décidé que la Data était prioritaire : la grand-messe Data est lancée. Maintenant il faut construire et des sujets clefs commencent à apparaître : modélisation, gouvernance, dictionnaire de données, reprise des données, qualité de données, architecture fonctionnelle, architecture de données, échanges de données.
Des sujets clefs trop souvent sous-estimés : pourquoi ?
Parce que bien souvent, la première idée qui nous vient en tête est qu’une solution du marché existe et répondra à tous ces sujets. Le projet data devient un projet d’intégration SI et bien souvent ce projet est un échec.
Ensuite, parce qu’on ne voit pas à très court terme l’impact de ces sujets sur la maintenance des applications, les performances, la productivité, le time to market, la satisfaction client et les possibilités offertes par vos SI.
C’est la transversalité de la data et les nouveaux usages qui rendent complexes la conception des solutions pour répondre aux besoins adressés par les métiers.
Prenons l’exemple de la modélisation de données
Si vous mélangez le modèle physique et le modèle conceptuel, ou si vous ne comprenez pas bien les concepts fonctionnels manipulés lors des processus métiers, alors votre modèle de données ne répondra pas à tous les besoins adressés.
Et si en plus, les modifications de ce modèle au fur et à mesure des nouveaux besoins adressés ne sont pas suivies et validées de manière transverse par un architecte de données expérimenté, petit à petit, le SI que vous construisez tendra à devenir moins flexible et moins agile face aux besoins qui se multiplient et où vous avez besoin d’aller vite.
Une conséquence est que la conception des portails qui vont utiliser vos données sera plus complexe et pourra avoir des impacts forts sur les performances. Une autre est que vous ne serez pas capable d’absorber les données d’autres SI à l’échelle de l’entreprise (futures acquisitions, futurs décommissionnements pour obsolescence, changement d’architectures, etc.).
La modélisation n’est qu’un exemple
C’est un processus lent et qui ne se voit pas. Face au marché qui ne vous attendra pas, vous serez alors plus lent que les nouvelles demandes qui apparaissent, et vous ne serez pas en mesure de les anticiper. Mal modéliser c’est lentement se créer des blocages SI quand il faudra répondre à de futurs besoins. Adressez donc le sujet modélisation à une personne experte dans votre organisation.
La modélisation est un exemple, mais la gouvernance, la qualité des données, les habilitations sur les données ont des impacts tout aussi similaires.
Exigez le savoir-faire
Donc non tout le monde ne peut pas se décréter Modélisateur, Analyste de données ou Chief Data Officer. Ne lancez pas des projets Data si vous n’avez aucune expérience sur le sujet, ni les compétences nécessaires. Sachez les identifier. L’enjeu se joue au niveau de chaque data utile à un usage. Chaque data manipulée, modélisée, mappée, extraite et exposée sur lesquelles travaillent chacune des personnes qui vont construire votre SI.
Comme pour la modélisation, est-ce que les équipes de vos projets ont l’expérience nécessaire pour visualiser l’impact de leur microdécision à chaque phase de la conception ? Je vous garantis que non !
Des compétences et de l’expérience sont absolument nécessaires pour prendre du recul et traiter le projet selon les exigences spécifiques liées à la data, en plus des besoins des métiers et des exigences SI.
Alors entourez-vous, recrutez les profils qui l’ont déjà fait et cherchez les acteurs du marché** qui sont au fait des dernières technologies, car c’est votre survie digitale qui en dépend !
* Comment valoriser vos données ? Le livre blanc ‘Augmentez la valeur de vos données’ Rhapsodies Conseil est là pour répondre à vos interrogations.
Rhapsodies Conseil accompagne les Chiefs Data Officer ou toute personne ayant une responsabilité sur les données à tirer parti de cet actif stratégique.
Les dimensions et les activités à traiter pour augmenter la valeur des données sont nombreuses : usages, culture data, maîtrise et gouvernance des données, amélioration des compétences, technologies data… Indispensable pour une organisation qui veut gérer ses données comme des actifs stratégiques, le rôle de CDO est encore récent dans de nombreuses organisations, où il faut trouver la meilleure articulation avec les Métiers, la DSI, mais aussi la Direction Générale.
Nos collaborations avec différents CDO ont motivé la formalisation d’un cadre complet et opérationnel au service de la transformation data : “Le Framework du CDO”. Les fiches pratiques de notre Framework pose le cadre qui structure la mise en œuvre de la transformation data d’une organisation avec l’ambition d’être un guide et un accélérateur de cette transformation au quotidien.
Celui, ou celle, que l’on appelait avant Architecte Fonctionnel et que l’on appelle à présent Architecte d’Entreprise (AE), a vu son domaine d’intervention être siloté avec une approche qui a privilégié les processus souvent au détriment des données.
La notion d’Architecte Data a donc vu le jour sur le marché, ou même Data Architect pour lui donner une aura internationale. A la manière des architectes SI ou techniques qui sont complémentaires aux AE, Est-ce la cas pour l’Architecte Data ? L’est-il ou fait-il exactement la même chose que l’AE sur les données ?
Mais pourquoi tout le monde veut ma place ?
De mon point de vue, l’architecte d’entreprise subit les conséquences d’une posture qui a fini par lui porter préjudice. Le fameux « architecte dans sa tour qui ne comprend pas les contraintes des gens qui font vraiment de l’informatique », réputation contre laquelle nous luttons tous les jours mais qui, nous devons bien nous l’avouer, existe encore parfois.
Un autre problème est lié au vocabulaire que nous utilisons. Un but de notre métier consiste à savoir si tel ou tel développement doit être fait dans telle ou telle application, et pour cela nous travaillons avec les fonctions. Alors une fonction, tout le monde pense savoir de quoi il s’agit mais ce n’est souvent pas le cas, et cela est moins parlant qu’une « Donnée ». De plus, les justifications pour regrouper des fonctions sont floues : cohérents, logiques,… sont des mots à bannir de notre vocabulaire.
Pour commencer : qu’est-ce qu’une fonction ?
Si on demande à Larousse, la définition d’une fonction est la suivante : « Ensemble d’instructions constituant un sous-programme identifié par un nom, qui se trouve implanté en mémoire morte ou dans un programme ». Personnellement, j’en ai une autre : une fonction est une instruction visant à modifier une caractéristique d’un objet.
La raison pour laquelle je préfère ma définition est que le mot objet permet de faire le lien avec un des éléments qui permettent de construire l’architecture fonctionnelle de votre SI.
Comment construisez-vous votre plan fonctionnel ?
Lorsque notre ami architecte d’entreprise définit un plan d’urbanisme fonctionnelde son système d’information, c’est qu’il veut mettre en évidence les fonctions nécessaires aux métiers. Mais quels sont les critères de regroupement ?
Le principal critère de regroupement, c’est la donnée. Pour bien comprendre, prenons l’exemple de l’objet, et donc de la donnée, « Personne » dans le cadre simplifié d’un site de distribution. Toutes les fonctions de l’objet « Personne » sont donc rangées dans le bloc Personne. Prenons ensuite les fonctions rangées dans le quartier Adresse. Ce sont des fonctions qui sont appelées, et donc des données qui sont modifiées, dans un même cas d’usage. Quand une personne déménage, les données liées aux fonctions dans le quartier Adresse sont modifiées. Enfin dans un ilot, vous allez retrouver toutes les fonctions qui peuvent modifier une information particulière : Modifier la rue, modifier le numéro, modifier la ville.
Cet exemple est concentré sur l’objet « Personne » mais cela est vrai pour la globalité de l’entreprise. Le modèle de donnée de l’entreprise est donc nécessaire pour construire un plan fonctionnel global de l’entreprise.
Mais comment parler avec les projets ?
Il faut arrêter de parler de fonctions avec vos projets, ne dites pas « quelles sont les fonctions que vous voulez ajouter » mais « quelles sont les données que vous allez impacter ». Charge à l’architecte d’identifier ensuite les fonctions. Il faut parler le même langage que lui, lui faire comprendre la valeur qu’on lui apporte et ce sera gagné.
L’Architecte Data est un architecte comme les autres. C’est son approche par les données qui met en avant les problèmes de gouvernance auxquels l’architecte fonctionnel était déjà confronté auparavant, alors « Reprenons notre dû, reprenons les data ! »
La question de l’organigramme dans nos missions d’organisation surgit toujours, à un moment ou un autre, comme un diablotin hors de sa boite… Comment traiter ce sujet qui est l’objet de tant d’attentes ?
L’organigramme qui cache la forêt (de l’organisation)
Dans certaines entreprises, l’organigramme est mis à jour et diffusé régulièrement, dans d’autres, il est inexistant et implicite. Il peut être éternellement transitoire, ou parfois faux ou approximatif. Sa consultation et son analyse sont, dans tous les cas, essentielles pour comprendre une organisation.
Avant d’être une source d’information factuelle, l’organigramme porte une dimension symbolique, la répartition du pouvoir, réel ou supposé, au sein de l’entreprise. De ce fait, l’organigramme revêt une grande importance pour tous les collaborateurs, particulièrement pour ceux avec un positionnement hiérarchique, comme source d’affirmation de sa position dans l’entreprise : nombre d’échelons hiérarchiques entre soit et la direction, nombre de personnes encadrées, intitulés des postes et des entités, font partie des informations scrutées. Tout le monde essaye d’y lire « entre les ligne » et tout changement alimente frustrations et espoirs.
Lorsque que l’on conduit une mission touchant à l’organisation opérationnelle (optimisation des processus, évolution des modes de management, transformation des équipes, etc.), la question de l’évolution de l’organigramme finit toujours par surgir : va-t-il évoluer ? Qu’est-il prévu pour moi ? A quel moment sera-t-il publié ? Est-ce une version définitive ? Etc.
Même si les organisations ont changé, que les pyramides hiérarchiques ont été aplaties, que les postes de travail sont plus évolutifs, l’organigramme reste emblématique de l’organisation. Il demeure une source intéressante d’informations. Donc, pour tout projet de transformation, c’est une dimension importante à utiliser. Comment aborder le sujet ? Voici une liste de questions à considérer face à un organigramme.
En préambule, il faut rappeler que l’évolution de l’organisation, avec sa traduction dans l’organigramme, doit être soumise au CSE lorsque les changements sont structurels et substantiels. L’avis du CSE n’est que consultatif mais n’en est pas moins obligatoire. Il est bon de garder ce point en tête pour ne pas oublier de le traiter.
Venons-en à l’organigramme lui-même : comment le lire ? comment l’aborder ?
Le taux d’encadrement : il s’obtient en comptant le nombre de collaborateurs par manager et en divisant le tout par le nombre total de managers. Il permet de mesurer la taille moyenne des équipes. Plus le chiffre est bas, plus l’organisation est « pyramidale ». La multiplication de petites équipes, de moins de 3 personnes, doit interroger sur l’atomisation du management et la répartition de l’activité.
La lisibilité de l’organisation : est-ce que les fonctions ou les noms des structures correspondent à une réalité opérationnelle ? S’agit-il de fonctions-types sans rapport avec la réalité des rôles assumés dans l’organisation ? S’agit-il d’un organigramme statutaire et administratif? Il arrive parfois de constater que l’organigramme ne permet tout simplement pas de comprendre l’organisation.
Le degré d’alignement de l’organigramme par rapport aux besoins-cibles de fonctionnement : Il s’agit là de comprendre la répartition de l’activité et la logique d’organisation de l’entreprise. Est-elle construite par rapport aux chaînes de valeur (processus et missions), par rapport aux marchés (clients et produits -ou services-) ou encore par rapport aux compétences (logique de filières et de pool de ressources) ?
La capacité d’exécution : l’organigramme renseigne enfin sur les capacités de l’entreprise en nombre de collaborateurs. L’analyse du dimensionnement et de la répartition des collaborateurs complète l’analyse des compétences et de leur adaptation rapport aux missions à accomplir et aux postes à occuper.
Toutes ces questions à se poser sur l’organigramme aident à comprendre l’organisation, et viennent compléter les autres axes d’analyse : catalogue de service, processus, règles de fonctionnement, fiches de postes, gouvernance (instances et process de reporting et de décision).
L’organigramme est une riche source d’informations (explicites et implicites). C’est un instrument de management et de communication. Dans tous les projets touchant à l’organisation il faut se poser la question de l’organigramme et le cas échéant en faire l’objet de toutes les attentions, en se remémorant qu’au-delà du fonctionnement réel de la structure, il a pour les collaborateurs toute une dimension symbolique.
Lorsque l’on recherche sur Linkedin des experts en micro-services, les résultats sont nombreux… Y a-t-il une explosion des pratiques micro-services au sein des entreprises ou est-ce une surévaluation des expériences professionnelles ? Qu’est-ce qui nous rend pertinents sur le sujet ?
Qui fait réellement des micro-services ?
Ceux qui n’ont en fait pas compris ce que c’est…
Un micro-service est un service qui embarque des composants applicatifs et des données : nous entendons souvent parler de « frontal découpé en micros-services » ou « code applicatif découpé en micro-services » ou « j’ai créé un container Docker, j’ai produit un micro-service ».
Sans vouloir rentrer dans le débat de la pertinence de ces pratiques, nous pouvons affirmer qu’elles ne suffisent pas pour déclarer adhérer à une démarche micro-services.
Ceux qui font des micro-applications…
Il s’agit là de micro-services que nous n’avons pas besoin d’appeler micro-services.
Il s’agit d’une application, créée pour un besoin très spécifique.
Le découpage autour d’une seule API, liée à un domaine bien spécifique, pour un cas d’usage très précis, avec une base de données dédiée, est logiquement associable à un micro-service. Néanmoins, bien que l’appellation soit correcte, avoir contribué à ce type de réalisation ne nous rend pas forcément éligibles à des projets micro-services d’envergure…
Ceux qui font réellement des micro-services…
Seuls ceux qui y ont réellement contribué connaissent les vrais enjeux : sachez les identifier. Nous parlons ici d’une vraie approche micro-services qui suppose une réflexion data, mais également de l’orchestration et de la gestion de la cohérence.
Nous allons donc amorcer une première analyse de ces enjeux majeurs en nous focalisant surtout sur un des points clés de complexité : la gestion des adhérences entre micro-services (nous n’allons pas aborder les sujets de sécurité et gouvernance au sein de cet article, ils seront abordés dans une publication à venir).
Un micro-service, comme décrit dans le précédent article, doit être indépendant et isolé. Ces caractéristiques sont difficiles à obtenir quand le micro-service est créé et utilisé au sein d’un processus complexe demandant des orchestrations complexes.
Quels enjeux pour l’orchestration et la gestion de la cohérence des micro-services ?
L’orchestration des micro-services
Les micro-services, par leur nature, peuvent ne pas entièrement satisfaire à un processus ou à une étape de ce processus.
Pour pallier à ce besoin, une orchestration peut être réalisée en se basant sur des architectures de référence, selon le degré de complexité. Pour les cas les moins complexes, nous pouvons utiliser les backends des frontaux (avec par exemple une application BFF, Back For Front). Cette orchestration restera très spécifique à un cas d’usage. Il s’agit ici de l’enchaînement par exemple des appels vers deux micro-services, en lecture, car un seul ne suffit pas à garantir une expérience utilisateur complète (je retrouve les contrats d’un client et pour chaque contrat je lui montre les commandes associées).
Dans des cas plus complexes, ou hautement réutilisables, nous pouvons baser notre démarche sur d’autres outils. L’orchestration pourra alors être réalisée :
Par un moteur d’orchestration maison, spécialement conçu et dédié
Par des outils de BPM, qui peuvent y voir une seconde jeunesse après les promesses de la période SOA
Ces cas de figure permettent comme dit auparavant, également de mieux gérer le second point, la cohérence des données.
La gestion de la cohérence des micro-services
La cohérence canalise le sujet sur l’aspect données. Nous allons le résumer aux questions suivantes :
Comment assurer la cohérence si on travaille sur plusieurs bases de données ?
Rollback ? On se complique la vie avec les micro-services ?
On oublie l’ACID et on perd donc tous ses avantages ?
Probablement, ce qui va résoudre la moitié de ces cas de figure est le pragmatisme. Voici quelques exemples :
Un axe de simplification est porté par le découpage des micro-services : un découpage trop fin implique forcément une complexité croissante, donc attention à ne pas scinder là où on n’en a pas besoin.
Un autre est de s’assurer de la bonne conception fonctionnelle maximisant les couplages lâches entre les objets, les taches et les processus, pour qu’on ait le moins de rollback à faire si une des opérations orchestrées n’aboutit pas.
Un troisième est une analyse de la rigueur / la sécurisation demandée pour chaque cas d’usage. N’oublions pas que chaque information traitée demande une attention différente. Les données de tracking des utilisateurs sur mon site internet peuvent avoir un niveau de certitude inférieur par rapport à la gestion des transactions bancaires liées aux achats sur le même site.
C’est à partir de ces réflexions qu’on balaie une partie des interrogations et qu’on peut se focaliser sur les sujets complexes d’intégration et gestion des micro-services, demandant la mise en place de pratiques d’orchestration visant à pallier à ces sujets de cohérence.
Les exemples discutés dans cet article n’ont pas vocation à être exhaustifs mais aident dans l’élaboration et la mise en application d’une démarche micro-services.
Les contraintes imposées par une démarche micro-services obligent à une réflexion très structurée dès la conception. D’où l’importance, comme nous avons pu le dire auparavant, de ne pas se focaliser uniquement sur du découpage fin mais de bien mener la réflexion autour des données, des interactions, des orchestrations et de la spécificité de chaque micro-service.
NB : nous n’avons pas distingué l’orchestration et la chorégraphie des micro-services dans cet article, ce sera le sujet d’une publication à venir !
[Vidéo] Maîtrisez et Augmentez la valeur de vos Données
[Vidéo] Maîtrisez et Augmentez la valeur de vos Données
Maîtrisez et augmentez la valeur de vos données – la méthode rhapsodies conseil
Considérée comme matière première de l’économie numérique, la data et son exploitation créent une effervescence continue. Elle est devenue un acteur central de notre quotidien et de celui des organisations. Mais comme toute ressource de grande valeur, il faut apprendre à exploiter cet actif.
Vous souhaitez développer les usages de vos données ? Vous souhaitez augmenter le potentiel de vos données ?
Nous avons synthétisé pour vous dans cette vidéo les 5 étapes de notre méthodologie pour mesurer et augmenter la valeur de vos données !
