Avec l’arrivée récente de différentes réglementations impactant les données (RGPD, Bâle III, Bâle IV, BCBS 239), il est devenu primordial de connaître son patrimoine de données afin de pouvoir identifier et appliquer les bonnes politiques de gouvernance de la donnée (qualité, sécurité, accessibilité). Il faut que les entreprises voient cette contrainte comme une opportunité qui leur permettra à terme de faciliter leurs différents projets de transformation et de mieux valoriser leurs données.

Quel Data Scientist ou Responsable de Traitement métier ne s’est pas interrogé sur la source d’une donnée à utiliser pour son cas d’usage ? Comment connaître son origine et son cycle de vie et s’assurer de sa qualité ? Comment savoir, au sein d’une entreprise, qui est le Data Owner sur une donnée en particulier ? Ou trouver le glossaire des termes métier associés à cette donnée ? Comment montrer à un RSSI, un DPO ou un Régulateur que les mesures de sécurité liées à une réglementation ont été associées à une donnée et mises en œuvre ?

C’est là où une solution de Data Catalog (ou catalogue de données) devient essentielle et peut vous aider à répondre à ces différentes questions. Celui-ci deviendra la base d’information centrale, un peu comme une bibliothèque, qui vous permettra de rechercher, trouver et connaître les bonnes sources de données pour vos cas d’usages Big Data ou vos traitements métiers. Ceci permet de regrouper les données au sein d’un même référentiel, de collecter, d’enrichir et de partager toutes les métadonnées associées.

Mais comment faire pour s’y retrouver ? Les différentes offres du marché se vantent toutes de pouvoir gérer et maîtriser votre patrimoine de données, générant, ainsi, de la valeur. Il faudra d’abord définir le périmètre de la gouvernance de données à mettre en œuvre et recueillir les exigences fonctionnelles et techniques. Ce qui suit vous aidera ensuite à comprendre ce que pourra couvrir une solution « Data Catalog ».

La fonctionnalité de base est déjà de pouvoir récupérer automatiquement les métadonnées techniques, c’est-à-dire les informations décrivant vos données d’un point de vue infrastructure (fichier, base de données, table, colonne, etc). Les éléments différenciant pour le choix de la solution vont dépendre de votre écosystème et des connecteurs nécessaires. Est-ce que vos données sont structurées, non structurées ou sont-elles sous format document ? Est-ce que vos données sont contenues dans des bases de données SQL ou noSQL ? Quel socle technologique Big Data utilisez-vous ? Avez-vous des données dans des Cloud Public ? Comment transporter ou partager vos données ? Via des traitements spécifiques, un ETL, un ESB ou via une API Gateway ?

Ces métadonnées décrivant vos données techniques comme un dictionnaire devraient être reliées à une donnée logique et une donnée métier qui sera elle-même à l’aide d’un glossaire métier.

Un cadre de gouvernance des données avec une organisation, des acteurs, des processus et des livrables documentaires doit aussi pouvoir être décrit et déployé via un métamodèle opérationnel .

Ce métamodèle implémenté dans  l’outil devra permettre de gérer des rôles et des organisations afin de pouvoir définir des responsabilités pour appliquer cette gouvernance de données. Celle-ci ne pouvant être mise en œuvre que si la donnée a d’abord été classifiée et que des politiques de gouvernance liées à un référentiel d’entreprise ou demandé par un Régulateur ont été identifiées et reliées à cette donnée métier. Tout ceci n’étant possible que si l’outil permet de gérer un modèle opérationnel de gouvernance des données personnalisables.

Parmi les autres fonctionnalités attendues pour cet outil il y a également la capacité de générer des états de Data Lineage.

Cette fonctionnalité est majeure et permettra de traduire visuellement la vision 360° de vos données. Ceci vous habilitera par exemple à réaliser des analyses d’impact en cas de changement sur un système aval vous fournissant la donnée. Ces états peuvent vous aider également à analyser l’écart entre deux KPIs ou de répondre à une exigence réglementaire demandant de documenter de bout en bout comment tel indicateur aura été généré. L’outil vous permettra aussi d’avoir une vision sur la qualité de ces données via par exemple du data profiling ou des indicateurs. Ceci permettra de faire gagner du temps à vos Data Scientist pour sélectionner l’algorithme le plus approprié ou motivera votre Data Steward à sélectionner le jeu de données le plus approprié pour votre cas d’usage ou traitement métier.

Enfin pour terminer, cet outil devra être accessible via une application web, fournir un moteur de recherche et proposer un référentiel de cas d’usages avec les sources de données associés. Ceci activera le partage de la connaissance de ce patrimoine au travers de votre organisation et l’identification des sources de données critiques à vos traitements métiers. A terme, ce patrimoine permettra plus facilement aux métiers de générer de la valeur pour votre entreprise tout en maitrisant les règles de sécurité et accessibilité de cette donnée.

Voilà pourquoi le Data Management ne peut plus se faire via un tableau Excel et qu’un catalogue de donnée devient essentiel.

Ma série d’articles sur l’Architecture et l’agilité en arrive à son 5ème chapitre. J’ai fait beaucoup de recherches, échangé avec des agilistes et des confrères Architectes. Mais avais-je vraiment pris le temps d’intégrer l’agilité dans mon mode de fonctionnement ? Pris le temps d’en discuter et d’y travailler avec mes équipes ? Et qu’a fait notre cabinet de conseil pendant ce temps-là ? Voici mon retour (d’expérience) sur ce qui s’est passé dans mon écosystème dernièrement.

Avoir dans notre cabinet une équipe dédiée à la Transformation Agile est vraiment un atout dont je n’avais pas encore mesuré toute la portée. L’évolution se fait doucement mais sûrement et en profondeur. Que ce soit par des formations, des conseils ou des exemples, elle se fait sentir à tous les niveaux du cabinet. Nous sommes en train de trouver notre voie et c’est bien là le secret !

Former les managers

En tant que consultant d’abord puis manager, je suis des formations régulièrement. Depuis plus de 15 ans ces formations portent sur mon expertise, l’Architecture, mais aussi sur le métier de consultant et de manager d’équipe.

Notre équipe de Transformation Agile propose une formation au Management 3.0. Comment refuser une telle opportunité ? Prendre 2 jours de réflexion sur ma pratique de management qui n’avait pas évolué depuis quelques années. Avoir les bonnes pratiques et de nouvelles techniques autour du management à intégrer dans mon fonctionnement et celui de mon équipe.

Je pensais bien que le changement était en marche, mais là, j’ai vraiment réalisé le retard que j’avais pris. Nous sommes donc en train de changer notre fonctionnement interne, nos modes de réunions, de travail etc. L’équipe en parlera surement plus en détail dans un prochain article.

Je ressemble à ça maintenant, j’ai bien changé, non ?

La formation pour tous, mais laquelle ?

En parallèle, la réflexion m’avait mené aussi sur la formation des consultants vers l’agilité et les changements que cela implique. Quelle formation ? Pour quel but ? Pour commencer, 2 formations fondamentales tiennent la corde. Elles correspondent aux 2 rôles principaux des projets agiles aujourd’hui : le Scrum Master et le Product Owner.

Les 2 formations sont pour partie les mêmes. Les bases de l’agilité y sont présentées. La suite diffère selon le rôle que l’on est amené à jouer. Est-ce que vous allez travailler en tant que responsable du produit ou en tant qu’animateur du projet ?

• Le Product Owner se focalise sur la valeur, les finances, la stratégie, et est connecté avec les différents intervenants et clients autour du projet.
• Le Scrum Master est un facilitateur de l’atteinte des résultats, un leader non autoritaire qui connecte les gens et les aide à tirer le meilleur d’eux-mêmes dans la constitution de l’équipe. Il est là pour catalyser les résultats.

Pour le métier d’Architecte, les 2 aspects semblent importants. Dans ce cas, pourquoi choisir ?

Nous avons alors pris le parti de former certains architectes en Scrum Master et d’autres en Product Owner. L’avenir nous dira si nous devons compléter par la suite la formation des uns ou des autres.

L’essentiel est de se lancer.

Nous ferons au fur et à mesure des projets et des missions, les constats et les retours d’expérience des uns et des autres sur l’utilité et la spécificité de chacune des formations (par exemple, sous le format des rétrospectives présentées dans SCRUM !)

La détection des faux positifs

Maintenant que nous sommes formés à l’agilité, que nous en connaissons les principes, le 1^er changement qui nous vient à l’esprit est de détecter tous les projets qui se prétendent Agile (le terme étant très galvaudé en ce moment) et qui ne le sont pas. Et surtout de pouvoir dire en quoi ils ne sont pas agiles.

Un projet qui conserve un découpage de ses travaux en lots. Un projet sans autonomie. Autant de projets avec lesquels nous travaillons, qui se prétendent agiles, voire sont convaincus de l’être.

Nombreux sont les exemples que nous voyons dans les entreprises au quotidien.

Un des principaux défauts, que j’avais souligné dans un article précédent, est qu’il est très difficile pour un projet d’être vraiment Agile si les managers ne le sont pas et ne font pas évoluer leur posture.

Même s’il est toujours aussi difficile de travailler avec ces projets, au moins nous pouvons échanger avec eux, les aider aussi et peut être trouver des axes d’amélioration ?

Et au niveau du cabinet, le LAB !

En parallèle, notre cabinet a initié une pratique de Lab : dispositif de créativité, de co-construction et d’intelligence collective aussi bien orienté vers l’interne que vers l’externe. Les initiatives sont venues, les projets ont commencé, les premiers résultats arrivent. La dynamique est en place et le mode de fonctionnement se rode.

Il y aura des réussites, des échecs, mais surtout plein de belles histoires.

Mais le plus important dans tout ça, ce n’est pas le Lab, c’est bien le symbole. Dans notre cabinet, comment trouver une place dédiée pour le Lab où nous puissions travailler avec les bons outils ? Le seul endroit qui s’y prêtait était déjà occupé. Et pas par n’importe qui, pensez donc : le président et ses 2 DG Adjoints. Ce sont eux-mêmes qui ont proposé de laisser leur bureau pour le Lab.

Si ça, ce n’est pas un changement visible !

Fini la V1, vive le MVP !

Dans l’ancien mode de fonctionnement d’un projet, nous annoncions toujours la mise à disposition d’une V1, complète et exhaustive. Elle prenait du temps et consommait des ressources. Pour un résultat rarement satisfaisant.

Avec l’agilité, nous faisons des MVP (Minimum Viable Product). Un produit suffisamment complet du 1^er coup pour qu’un client y trouve de l’intérêt (juste les bonnes fonctionnalités). Pas avec toutes les fonctionnalités bien sûr mais plus qu’une V1 bancale. Une approche qui oblige à se focaliser sur l’essentiel.

Nous essayons de démocratiser cette approche pour tous nos projets, y compris pour nos projets en interne.

Et cela fonctionne mieux. Les MVP sont mieux acceptés, consomment moins de ressource, apportent plus de retours d’expérience.

Est-ce que ça change vraiment ?

Oui ça change. Surtout la perspective avec laquelle on aborde les sujets.

La mise en pratique se fait avec un plus grand partage de toutes les informations. La transparence est primordiale.

Les échecs sont permis. On apprend à marcher en tombant. Il faut essayer. Les nouveaux modes de fonctionnement ne marchent pas du 1^er coup ? Quoi de plus normal. Apprendre de nos erreurs et continuer à avancer.

La confiance était déjà de mise dans notre cabinet mais le management agile va encore plus loin.

Ne plus imposer mais fournir les informations pour que chaque niveau puisse décider de son mode de fonctionnement, de ses actions et de ses buts.

Rome ne s’est pas faite un jour, mais les changements sont visibles et je pense maintenant que personne ne pourrai / ne voudrai retourner en arrière.

Aller très loin ou aller trop loin ?

Dans la formation Management 3.0 certains aspects bouleversent complètement nos modes de fonctionnement. « Ne pas promettre de récompense », « Récompenser des comportements pas des résultats » sont des exemples de préconisations de cette formation. Ces règles visent à valoriser le collectif plutôt que l’individu / l’individualisme.

Quel changement quand on est habitué à avoir des objectifs fixés en début d’année et d’être jugé, et récompensé, sur la base de l’atteinte ou non de ces résultats.

Imaginer des commerciaux qui ne soient plus récompensés sur l’atteinte de leurs résultats mais sur leur comportement ! Impensable de nos jours dans la plupart des entreprises. Et pourtant, on sent bien la justesse des arguments de ces nouvelles techniques de récompense.

Certaines habitudes auront la vie plus dure que d’autres, et le trajet sera d’autant plus long.

Conclusion

C’est une révolte, sire ? Non, juste une belle évolution ! En faire moins (exit les V1 fastidieuses) mais mieux (les MVP).

Le principal est que cela soit le fait d’une volonté commune et que les dirigeants (un fort niveau de sponsoring est indispensable) comme les collaborateurs y adhèrent. Nous avons tous à y gagner et à grandir dans ces nouveaux modes de fonctionnement.

Nous avons les techniques, des formations sont à disposition et des vidéos pour nous guider.

A nous de jouer !

Chapitre(s) suivant(s) ?

Je ne vais plus annoncer de suite, car cela évolue / change tellement vite ! Mais ne vous inquiétez pas, vous ne serez pas déçus.

• Découvrez toute la série
  • Chapitre 1 : C’est quoi l’Agilité
  • Chapitre 2 : Détournement des valeurs en cours
  • Chapitre 3 : Un SI entre Architecte & Agilité 
  • Chapitre 4 : Comment les Architectes peuvent interagir avec l’Agilité 

Le triptyque Big Data, Data Science, Data Lake a fait naître l’espérance de nouveaux débouchés pour l’entreprise, basés sur une meilleure exploitation de la valeur supposée des données. Ce nouvel eldorado inspiré par des technologies créées par les GAFA est souvent perçu comme une solution purement technique. Il apparaît pourtant nécessaire d’aborder les apports essentiels de l’architecture d’entreprise dans la valorisation et le succès d’un Data Lake à travers trois chapitres distincts :

• L’activité urbanisation des systèmes d’information qui permet d’anticiper la place que le Data Lake occupera dans le « paysage applicatif » et dans l’organisation du système d’information.
• L’activité modélisation de données et mise en place de référentiels afin de garder le contrôle de son Data Lake et empêcher la transformation du lac (Data Lake) en marais (Data Swamp).
• L’activité pilotage du changement centré sur les données et les usages, pour être en capacité de transformer les futures idées innovantes issues de votre Data Lake en avantages compétitifs réels pour l’organisation.

En effet, si le Data Lake démonte techniquement les silos de données et ouvre la porte à des analyses globales et instantanées qui étaient inaccessibles jusque-là, il ne permet pas de disposer automatiquement d’une avance sur ses concurrents.

Chacun des chapitres qui suivent rappelle que le décloisonnement de la donnée n’est utile qu’à condition de faire évoluer en conséquence son système d’information et son organisation. Non par une démarche dogmatique qui imposerait un cadre, mais par une concertation autour des mutations à venir de l’organisation.

Si la résistance au changement, celle qui annihile les bonnes intentions, terrasse votre initiative de Data Lake, c’est probablement que certains des points qui suivent ont été sous-estimés.

Urbanisation : la place du big data dans la big picture

Si l’on s’en tient à une définition technique du Data Lake – un espace de stockage de données brutes à partir desquelles les Data Scientists effectuent des analyses pertinentes – la stratégie d’adoption est souvent la même. Un environnement moderne d’analyse est créé et un espace de stockage y est adjoint. Il s’ensuit une alimentation progressive en flux de données. Comme un POC qui ne dirait pas son nom. Cela ne permet aucune démarche d’urbanisation et n’embarque aucune réflexion sur les enjeux de l’industrialisation future. Pourtant, les sujets sont nombreux et porteurs d’enjeux forts.

Types d’utilisations et qualité des données

Un Data Scientist utilise toutes les données pour ses expérimentations, mêmes les erronées et les « incertaines ». Un responsable produit veut des données consolidées et visualisables quotidiennement. Un Marketing veut de la segmentation à la volée pour proposer les meilleurs produits. Les commerciaux sont sensibles au « time-to-market », de l’idée à son exploitation commerciale. Sans parler des préoccupations du RSSI, du DPO, du management, du DSI, du DAF, des partenaires…

Ces différents modes de fonctionnement évoluent dans le temps et définissent des séparations logiques dans le Data Lake. Non pas des silos, mais des contraintes d’utilisations qu’un Data Lake n’embarque pas par défaut, et qui nécessitent une certaine maturité dans l’urbanisation du Data Lake. Le Data Lake n’est pas un COTS – un produit informatique standard « vendu sur étagère ». Définir un écosystème est nécessaire pour découpler ces utilisations. Echanges de flux, orchestration des processus, supervision, autorisations d’accès, tout cela est nécessaire pour que le Data Lake évolue en phase avec le reste du SI.

Processus de collecte

En rapatriant toutes les données brutes dans le Data Lake, l’industrialisation des collectes de données ne peut pas faire l’économie d’une réflexion globale sur les qualités prioritaires attendues des échanges et de l’urbanisation qui en découle. Et toutes les entreprises n’auront pas les mêmes contraintes. Un opérateur de téléphonie peut générer un million de données par seconde de mille sources différentes, dont certaines sont soumises à des obligations légales de traçabilité et d’autres à des obligations comptables. Une petite mutuelle génèrera péniblement cinq mille données par jour, mais certaines seront des données de santé sensibles. D’autres auront leurs données dans des progiciels, dont certains en mode SaaS. D’autres encore exploiteront les données de partenaires de fiabilités variables. Des entreprises au SI de plus de trente ans passeront par des couches d’encapsulation de leur mainframe. Et toutes ces contraintes peuvent se combiner. Une logique urbanisée est vitale.

Sécurité des données

Le Data Lake a aussi pour vocation de faire circuler une part très importante des données de l’entreprise pour des usages dont le nombre, la nature et les utilisateurs finaux seront amenés à évoluer. Cela ne peut pas se faire sans une automatisation de la traçabilité, de la supervision et de la sécurisation des échanges et du stockage. C’est même bien souvent une obligation légale (RGPD, données de santé, Sarbanes-Oxley…).

La gestion des identités et des accès (IAM), l’API Management, leur intégration avec les données sensibles ou réglementées sont des sujets que l’architecture d’entreprise et le RSSI doivent orchestrer.

Quels modules dans l’écosystème data lake ?

D’autres éléments structurants de votre SI doivent être pris en compte dans l’urbanisation du Data Lake :

• Le « catalogue des données », les référentiels associés et leurs cycles de vie,
• L’orchestration des processus entourant la gestion des créations, évolutions ou disparitions des sources et destinations,
• Le transport physique des données, la gestion de l’intégrité et de l’unicité des transactions, la reprise sur erreur…
• La normalisation des données doit retrouver sa place autour d’un Data Lake qui favorise la donnée brute d’origine. La repousser en aval dans la chaîne de traitement ou faire cohabiter anciennes et nouvelles chaînes en parallèle, les choix dépendent des contraintes et attentes.

Chaque SI étant spécifique, cette liste est loin d’être exhaustive.

Se lancer dans la constitution d’un Data Lake sans faire le point sur les impacts, les contraintes et les opportunités mène généralement à une mauvaise adéquation par rapport aux enjeux stratégiques et aux besoins pressentis. Qui d’autre que l’architecte d’entreprise pour donner le recul nécessaire à la définition de la solution de bout-en-bout qui correspond à vos impératifs ?

Référentiels : connais-toi toi-même

Le principal avantage du Data Lake est aussi son principal inconvénient : il casse les silos de données en acceptant n’importe quelle donnée sans surveillance ni gouvernance. Or, il est bien hasardeux, en ces temps de RGPD, de laisser accéder n’importe qui à n’importe quelle donnée.

Autant il est facile de déverser en vrac des données non-dénaturées dans une couche persistante accessible par des personnes autorisées (le Data Lake dans sa forme épurée), autant se passer de référentiels qui permettent la mesure de la valeur des différentes sources de données fait perdre la maitrise du contenu du Data Lake et de tous ses usages possibles.

Les référentiels sont principalement des données de référence sur les données, des métadonnées. Savoir quelle donnée est disponible dans quelle source. Discriminer les données de référence, les données opérationnelles et les données d’exploitation. Connaître les fréquences de rafraîchissement, les versions disponibles, les responsables, la classification, les moyens de les visualiser.

L’utilisation qui en est faite dans le Data Lake est également un élément essentiel pour éviter la création de « silos logiques » venant remplacer les « silos physiques ». Le référentiel peut permettre de connaître le responsable des autorisations d’accès, l’endroit où elle est utilisée, son usage dans des expérimentations, des processus ou des rapports, les référents techniques, fonctionnels ou Métiers…

Si une donnée se trouve dans plusieurs sources, il faut savoir quelle source fait référence (« golden source »), les applications possédant une copie locale, celles pouvant mettre à jour la référence et les règles de propagation des modifications dans le SI, les mécanismes détectant et remédiant les inconsistances entre sources…

Il n’est pas possible de lister ici toutes les informations qui, dans un contexte ou un autre, peuvent être pertinentes. Mais c’est bien l’architecture d’entreprise qui définit le périmètre et les limites de cette gouvernance des données.

Cette gouvernance doit faire en sorte que l’utilisation des données ne reflète pas les anciens silos techniques. Elle permet aussi de faire contribuer les experts Métiers, fonctionnels et techniques sur la façon d’utiliser ces données qu’ils connaissent bien. Leur engagement et leur implication participent grandement du décloisonnement.

La technologie Data Lake pourrait permettre d’accepter n’importe quelle donnée sans surveillance ni gouvernance. Mais les organisations qui ont profité de cette possibilité de ne plus surveiller, ni mettre en place une gouvernance se sont retrouvés avec un Data Swamp dont la gestion est plus complexe, les bénéfices plus aléatoires et les risques opérationnels sans commune mesure avec ceux d’un Data Lake sous le contrôle des architectes d’entreprise.

Transformation continue et pilotage par la donnée

Commencer par aligner dans les deux sens

On se prive d’opportunités lorsque l’alignement entre le système d’information et les Métiers se fait toujours au détriment du SI. La complexité technique invisible aux demandeurs d’évolutions et la difficulté de rendre le SI adaptable aux exigences imprévues, rendent l’alignement difficile.

Dans le cas d’un Data Lake, lorsque différents acteurs Métiers accèdent au catalogue de données et aux services associés, le Métier s’aligne de lui-même sur ce que le SI lui rend disponible. En ouvrant son catalogue et en étant capable d’afficher ce qu’il est techniquement possible de fournir, le SI rationalise les exigences du Métier. Il le doit au socle urbanisé qui assure la maîtrise technique des flux et à la gouvernance pour la maîtrise fonctionnelle des données.

Certes, un travail effectué par le SI est toujours nécessaire pour s’aligner sur le besoin. Mais ce besoin sera plus naturellement cadré et les impossibilités techniques seront beaucoup plus rares.

Puis baliser la propagation de l’innovation

De même que le DevOps est le chaînon manquant entre deux mondes aux fonctionnements difficilement compatibles (le développement et l’exploitation), de même, il manque une étape importante entre la Data Science – qui extrait la valeur et valide la pertinence d’une nouvelle utilisation d’un ensemble de données – et le Métier qui attend une mise en production rapide de cette segmentation, cette visualisation ou cette publication.

Votre Data Lake va peut-être vous apporter de nombreuses idées de nouvelles utilisations de votre patrimoine de données. Il est rationnel de mettre en place des processus simples pour l’industrialisation de ces différents types d’utilisations.

Un « DevOps Data » avec des outils plus proches de la gestion de paramétrage que de la gestion d’une intégration continue. Il s’agit moins d’injecter de nouvelles versions applicatives dans le SI que de faire cohabiter des usages à différents degrés de maturation dans le même SI. A partir du Data Lake, il sera permis d’enrichir en continu des API à usages internes ou externes, ou d’automatiser la création de Data Sets pour des besoins de BI et de reporting. Ce DevOps se met en œuvre principalement autour :

• D’outils d’orchestration des processus,
• D’une bibliothèque extensible de connecteurs,
• Du travail algorithmique des Data Scientists,
• De la gestion des droits et des accès aux différents services,
• D’une gestion des sources, des environnements et des déploiements, plus classiques du DevOps.
• De convertisseurs en sortie pour fournir les formats utiles.

L’architecture d’entreprise associée à un Data Lake vous permet de créer du logiciel robuste, professionnel et évolutif sans vous lancer dans des appels d’offres de COTS qui reproduisent prioritairement les besoins du plus grand nombre, et non vos besoins spécifiques. Votre Data Lake devient l’élément central d’un applicatif adressant vos innovations sur-mesure.

Data lake et transformation

Cette évolution continue à l’échelle de l’entreprise fera le succès du Data Lake. Ce changement de paradigme a beau être souvent problématique, la nécessité d’une conduite du changement amenant à une modification de l’organisation est rarement perçue ; alors même que les Data Lake sont issus de GAFA et de startups dont la culture et l’organisation sont souvent à l’opposé des organisations matricielles qui s’emparent actuellement du Big Data et des Data Lake.

Ce mode de fonctionnement va bouleverser des pans entiers de votre organisation, modifier les circuits de décisions, les périmètres de responsabilités, les modes de communications internes et externes, les cycles de vie des produits et services, le contrôle des mises en production. Ces nouveautés sont anxiogènes et vont entraîner des résistances et des stratégies d’évitement.

C’est justement pour adopter plus facilement une démarche transverse affectant aussi bien l’architecture technique, les processus métiers, que l’accompagnement de la transformation de l’organisation, que l’architecture d’entreprise a été créée.

La mise en place d’un Data Lake est un saut dans l’inconnu. L’architecture d’entreprise est votre parachute.

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 architectes, de leur côté, ont défini la « Continuous Architecture » (conférence OpenGroup en 2016) pour édicter les principes de l’Architecture d’entreprise dans le cadre des projets Agile.

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.

Nouveau frontal digital, cache-misère du legacy IT ?

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.