Conduire la transformation vers le Data Centric

Le modèle de projet en spirale (Spiral Project Model)

En cette nouvelle année 2018

Polygone de Mandel

 voyons comment conduire la transformation de l'Entreprise vers le "Data Centric"

Dans les contextes d'informatiques héritées d'années de projets, et d'empilement d'applications de tous types, le patrimoine SI des entreprises est tout, sauf "Data Centric" : les données y sont éparses, redondantes, incohérentes, mal synchronisées, et dans des états de qualités mal maîtrisés.

La transformation de l'Entreprise, pour qu'elle dispose d'un SI "Data Centric", est un programme de changement compliqué, à conduire avec méthode. C'est une approche où les grands classiques de l'Architecture d'Entreprise ne proposent pas de référence.

La promesse du Data Centric

Un monde de processus et de logiciel, articulé sur des données de qualité, permettrait :

• de capitaliser sur les connaissances (expérience client, ...), en mobilisant les atouts technologiques actuels,
• de limiter les redondances et incohérences, néfastes à l'image, freins à l'efficacité,
• d'évoluer plus rapidement, en s'articulant sur les invariants portés par les données.

L'Architecture Flexible est la réponse typique, conceptuellement solide, à cette promesse. Nous avons vu que son approche top-down rencontrait maintenant le savoir faire acquis autour des micro-services. Ceci est en passe de révolutionner le monde du développement logiciel, et celui des architectures, en association avec la généralisation des démarches agiles (voir à ce sujet la synergie agile vs flexible).

Disposer d'une telle solution flexible, idéale dans l'absolu, en rupture par rapport aux Architectures calées sur une cible immuable, est un précieux acquis. Mais comment parvenir à cet objectif, comment migrer le patrimoine et les données ? Il n'y a pas de recette miracle qui nous dote instantanément d'un système répondant aux imprévus, et d'une agilité tous azimuts. Certes on s'accorde sur la nécessité de mettre de l'ordre dans les référentiels, mais les résistances sont multiples et le projet aléatoire.

La solution du Big Bang, jadis systématique, est impraticable, car le SI existant reste la référence opérationnelle, et sa transformation est infiniment complexe.

Dès lors, comment évoluer pas à pas, prudemment, en minimisant les risques, et apportant le plus de valeur au plus tôt ?

Naviguer dans l'incertain

Pour migrer vers le Data Centric, nous devons mener de front plusieurs projets, chaque projet ayant sa propre incertitude.

On pourrait imaginer un chemin rationnel, une "road map" rassurante : On sait d'expérience que cette rationalité est illusoire, car les projets ne se dérouleront pas comme prévu. Nous avons déjà utilisé la métaphore du labyrinthe pour expliquer ces aléas, sources d'échecs.

Imprévu des projets, mais aussi incertitudes dans l'assemblage des projets : autant d'occasions de surprises et déconvenues.

La démarche déterministe aboutit, comme dans un labyrinthe, à de fausses issues. Pour autant faut-il abandonner toute anticipation et se précipiter tête baissée dans les projets, par exemple en  comptant sur son agilité ? Ceci ne protège pas cependant des errements, blocages, et volte-faces impossibles. En effet, même si l'on est magicien du logiciel, les rigidités des comportements humains, les contraintes économiques, les faits d'image, ... rappellent les imprudents à la réalité. Un projet ne se réduit pas à la validation de spécifications et à la simple réalisation de code.

A défaut donc de disposer d'un chemin tout tracé, comment naviguer dans l'incertain ?

Une approche méthodique

Il nous faut découvrir notre chemin pas à pas, et, à chaque étape, se protéger au maximum des aléas de chaque projet, et des dépendances entre projets.

Le parcours doit être opportuniste pour s'adapter aux difficultés rencontrées. Il doit aussi être méthodique pour progresser dans la transformation globale, vers le Data Centric.

Identifier les axes d'amélioration

Le patrimoine existant n'a pas les atouts du Data Centric. Il convient de l'améliorer progressivement, par parties, selon les opportunités, à des vitesses adaptées...

Pour cette progression, dans le contexte de l'entreprise, quelques axes d'amélioration ont du sens. Ce sont par exemple, selon le contexte :

1. Normalisation des objets
2. Multiplication des interactions
3. Développement technique, fonctionnel, organisationnel
4. Gestion des latences et temporalités
5. Industrialisation

Ces cinq axes sont génériques, et on les retrouve facilement d'un cas à l'autre (publication à venir sur le site de l'Architecture Flexible).

Un indicateur de maturité des projets

Sur chacun des axes des incréments sont définis. On peut se référer des incréments standards (publication à venir sur le site de l'Architecture Flexible).

Les bases d'un indicateur générique de maturité des projets sont ainsi constituées : cet indicateur est la boussole nécessaire à la "navigation" mentionnée ci-dessus.

Indicateur de maturité : cas MDM

Le schéma ci-dessus présente le cas d'un projet MDM en approche Data Centric de l'Architecture Flexible.

Dans le contexte particulier de l'Entreprise, on identifiera les axes d'amélioration et on caractérisera les incréments souhaitables sur chaque axe. Nous pourrons dès lors objectiver le mûrissement de chaque projet en le positionnant sur ces axes et incréments.

La démarche incrémentale : expansion en spirale

Pour maîtriser l'expansion d'un projet, on engage alors une démarche incrémentale : à chaque étape, on change d'un incrément un seul des paramètres du projet.

L'expansion du projet se fera alors en spirale, depuis son "nid" initial vers sa pleine maturité où ses composants son pleinement opérationnels sur tout le périmètre.

Expansion en spirale

L'exemple ci-contre schématise l'évolution de l'indicateur de maturité au gré des cinq étapes d'un projet.

La transformation globale de l'Entreprise par son SI

En utilisant le levier des composants de l'Architecture Flexible, c'est toute l'Entreprise, par son SI devenant progressivement Data Centric, qui est mise en mouvement  : ouverture vers le Digital, réduction des latences, dématérialisation, fonctionnement matriciel, agilité dans les écosystèmes...

Le rebond de l'Architecture d'Entreprise

Un concept qui vient de loin

Le concept d'Architecture d'Entreprise provient des premiers ages de l'informatique, où l'empilement des systèmes a commencé à poser problème.

Quelques décennies, mais, au train où vont les choses, c'est une éternité dans la courte histoire de l'informatique.

Par analogie avec les constructions matérielles (construction navale dans le cas de Zachmann...) où la maîtrise de projets complexe est aussi une nécessité, les "Framework" ont poussé comme champignon après la pluie.

Ils ont tous eu des points communs : 

• analyser le système par couches, par exemple pour l'axe Business-technologie
• se focaliser sur la nécessité d'une cible, comme aboutissement de la transformation de l'existant.

Le schéma ci-dessous est une représentation caractéristique de cet état d'esprit, et du cadre dans lequel voulait se développer ce concept d'Architecture d'Entreprise.

• En somme un guide pour un double passage : comment satisfaire, voire générer, le business par un socle technologique,
• comment atteindre la cible qui marque l'aboutissement et le succès d'un épisode de transition.

Cette logique s'est imposée dans tous les pays et dans beaucoup de grands comptes, diffusée par des prescripteurs, les enseignements, les opérateurs globaux.

Elle est encore largement dominante au niveau académique et de la profession d'Architecte d'Entreprise, ne serait-ce que par les certifications qui la perpétuent, et sécurisent les employeurs.

L'accélération tout azimuts bouscule l'EA

Une banalité est de dire que toutes les transformations se sont accélérées, tant au niveau du Business, qu'au niveau technologique. Malgré cette litanie, l'Architecture d'Entreprise continue à s'imposer. Sans doute pour de bonnes et de mauvaises raisons !

Pour de mauvaises raisons, car penser que les vérités du passé s'appliqueront toujours et doivent guider le métier et les méthodes de l'Architecte d'Entreprise est fatalement illusoire... On voit clairement que la tenaille, l'éteinte, formalisée par l'EA sur le schéma ci-dessus, ne peut plus fonctionner avec les cycles de transformation actuels : l'inertie du "système" EA reste la-même, avec tous ses pre-requis, ses cartographies, de sorte que son échelle de temps ne peut se raccourcir : son process est manuel et organisationnel, gouverné, donc tributaire des pesanteurs des organisations, et du caractère artisanal de la profession.

Adapter la méthode de l'EA

Bien sûr, le poids des acquis pourrait inciter, en préservant le capital méthodologique, à adapter la "méthode", quelle que soit la variante qui est référencée dans chaque entreprise.

La Méthode, partant du principe d'amélioration continue, préconisait une "Roue de Deming" repensée pour l'Architecture d'Entreprise, avec une série de phases séquentielles incontournables.

L'adaptation fait apparaître des allers-retours entre phases, multipliant les cycles.

Voir par exemple l'adaptation de la fameuse boucle de l'ADM de Togaf.

ADM de Togaf

Est-ce suffisant ? 

L'écart de temporalité entre l'EA et les projets, sensés lui être fidèlement assujettis, ne peut que croître. L'EA se discrédite, et perd alors son utilité par inefficacité pratique.

Nous avons ici, à plusieurs reprises, sonné l'alarme sur ce sujet, et le point semble maintenant s'approcher du consensus.

Le refuge dans "l'Agile"

D'ailleurs, la généralisation des projets "agiles" contribue à ce discrédit. On peut en effet laisser croire, somme toute assez naïvement, que du désordre des projets, jaillira naturellement un ordre merveilleux. On retrouve cette croyance en une "main invisible", dans le manifeste agile qui avance cette pétition de principe :

"The best architectures, requirements, and designs emerge from self-organizing teams."

Résultats du rapport Chaos du Standish Group pour 2015

La démarche agile améliore les chances de succes des projets, c'est indéniable. Voir à ce sujet les résultats du rapport Chaos du Standish Group. L'amélioration est-elle dûe à une meilleure "architecture" ? Les chiffres disponibles ne parlent pas. L'agile est une bonne pratique, mais elle ne saurait garantir une architecture, qui dépend en bonne part des efforts de conception réalisés avant le lancement des projets.

 De toutes façons, le pourcentage de projets en échec reste important. Quoiqu'on fasse, le parcours d'un projet est l'exploration d'un labyrinthe, ou la part d'imprévisible est, en quelque sorte "mathématique" : c'est, dit savamment, un "processus stochastique", avec, à chaque porte du labyrinthe, un tirage selon une loi de probabilité. Plus le projet est important plus il y a de portes à franchir, et donc de tirages, et la probabilité de réussite, qui est une probabilité composée, tend vers 0. Car un projet est parsemé de voie sans retour, de déconvenues et détours imprévus (voir à ce sujet l'effet bollos dans le post sur l'évolution darwinienne des SI).

Bref, le déterminisme des projets est en bonne partie illusoire. Le déterminisme d'un EA "Requirement Centric", tel que présenté par ADM, est trompeur car il ne restitue pas cette mouvance.

Cependant, dans ce contexte parsemé d'inconnus, et de fausses certitudes, il y a de bonnes raisons de croire encore dans la nécessité, et en les vertues d'une Architecture d'Entreprise revisitée.

Là où l'EA peut reprendre pied

Traditionnellement l'Architecture d'Entreprise trouve sa justification dans 3 fondements :

• Transversalité : la prise de recul par rapport aux visions fragmentaires, celles des fameux silos que l'on retrouve dans toute organisation, est indispensable pour la cohérence, la synergie, la subsidiarité que l'EA peut préconiser. La position transverse nourrit l'apport de valeur de l'EA.
• Technologie : l'EA tire de la quintessence de l'offre technologique, et de son évolution, les propositions pertinentes tant au niveau business que sur les couches fonctionnelles, applicatives, techniques, ainsi que pour la composition des systèmes d'information.
• Vison à Terme : par delà la précipitation des différents métiers, avides de voir leurs "besoins" satisfaits, l'EA apporte une perspective indispensables pour assembler ces initiatives et les faire converger.

Ces fondements sont durables, même dans un contexte plus agile et plus frénétique. Ils en sont d'ailleurs renforcés. Et les enjeux auxquels l'EA contribue changent de nature, se portant au delà du SI, dans les chaînes de valeur elles-même.

Ces fondements ne suffisent plus. Heureusement l'EA peut reprendre pied : La technologie, par l'émergence du "Data Centric" et de ses fidèles bibliothèques de Data Integration, d'API management, de Master Data Management, ouvre un nouveau levier pour l'EA : l'action de court terme.

L'EA peut ainsi se reconnecter au monde actuel, retrouver une crédibilité indispensable, et prouver concrètement son apport de valeur.

L'action de court terme change tout

L'Architecte d'Entreprise était un grand ingénieur de cible, et producteur de cartographies. L'action de court terme lui permet de devenir le praticien des Architectures Data Centric. Ces Architectures désimbriquent les composants et préparent un SI recomposable facilement, adaptable aux aléas du Business comme aux ruptures technologiques.

Avec l'Architecture Flexible, nous avons posé les principes de telles architectures, et proposé d'articuler le SI sur les invariants.
Par delà la méthode, il s'agit pour l'EA d'un changement de posture aux multiples conséquences.

Le rebond stratégique de l'EA : changement de posture

Même si l'EA demeure fondée sur ses 3 raisons d'être traditionnelles, la posture comme acteur du court terme, et du changement, est prééminente : plus visible, plus concrète, plus présente le long du cycle de vie des projets.

Dès lors, l'idole de la cible passe au second plan. Le mouvement prime sur la théorie des exigences. Et surtout le cœur de métier de l'Architecte devient la constante recherche de flexibilité.

• La Flexibilité à introduire au gré des opportunités,
• La Flexibilité à démontrer à chaque instant dans les scénarios les plus improbables,
• La Flexibilité à maintenir contre vents et marées.

Enfin, l'Architecte d'Entreprise abandonne ses rivages méthodologiques et entre dans un nouveau paradigme, où il défend la transformation de l'Entreprise par le levier du Data Centric, au fil de l'eau des projets.

Le SI reste vu comme un système, mais non plus dans une systémique déterministe et utopique, dont on connait les écueils et les échecs, mais dans une systémique active.

Cet EA à vision systémique, darwinienne, met en place progressivement les catalyseurs de transformation du SI. Le métier de l'EA est celui d'un concepteur et praticien de ces catalyses (puits d'événements, référentiels pivots) introduites à des points clés du patrimoine SI. Au sien d'un SI qui mute alors naturellement, sans cible impérative, par tâche d'huile, et décisions décentralisées.

Architecture flexible : le rendez-vous avec les architectures événementielles

L'originalité de l'Architecture Flexible

L'Architecture Flexible, telle que définie ici et sur le site qui est dédié à ce concept, est d'abord une approche conceptuelle.

Elle trouve son fondement dans les chaînes de valeur, qui structurent le Business, au delà des processus, et des systèmes d'information. Le framework de la "Trame Business" explique cette structuration du Business.

Au niveau des systèmes d'information la figure de style propre à l'architecture flexible, qui lui donne toutes ses capacités, est celle du puits d'événement (ce terme est mieux adapté que celui de puits de données qui peut prêter à confusion).

C'est en combinant judicieusement puits d'événements, référentiels de données (généralement qualifiées de données maîtres d'où l’acronyme de MDM), dans le domaine étudié, que l'Architecture Flexible offre une solution innovante et pérenne. La Trame Business fournit un guide à cette analyse, lui donnant une efficacité inconnue dans les approches cantonnées au seul SI, qui peinent à définir des domaines objectifs, et stables.

Un atterrissage technique à prouver

Conceptuellement, l'Architecture Flexible peut fonctionner avec toutes technologies. En particulier, le modèle du Puits d'événement étant simple, il peut sans probléme être implanté sur une base de données classique, avec un modèle raltionnel en somme rudimentaire par rapport à celui de bien des bases existantes. De plus ce type de base est peu évolutif.

Cependant, en plaçant des Puits d'événements comme clés de voute de toutes les interactions, l'architecture technique doit être particulièrement efficace et sûre. Elle doit fonctionner en 24/7 et en temps immédiat.

De plus, il est souhaitable de pouvoir ajouter cette couche d'intelligence à moindre coût et sur des solutions "scalables".

L'émergence de nouvelles offres basées sur des "log d'événements"

L'évolution du monde de l'Open Source donne lieu à de nombreux projets, dont certains répondent aux besoins des entreprises natives de l'internet, typiquement confrontées aux grosses volumétries, aux multiples interactions, et un écosystème nativement événementiel.

Grosso modo, l'organisation des données a toujours été séparée en deux phases : celle de l'enregistrement et de mise en forme et celle de l'utilisation. C'était déjà le cas dans l'ancien temps, avec les registres de naissance par exemple, qui nécessitaient un gros travail manuel de préparation pour rendre les recherches faciles. Avec les bases de données, l'accent est mis sur la structuration sur des dimensions de recherche, ce qui en complique grandement la gestion. Avec les technologies traditionnelles, c'était le prix à payer pour rendre les bases de données exploitables. Avec la technologie actuelle, la performance des recherches permet d'imaginer des bases où la préparation est minimaliste. Ceci rendra probablement les bases classiques obsolètes... Sans pour autant dévaluer les vertus du modèle relationnel, des travaux sur la qualité des données, ... bref tout un acquis qui n'est pas à remettre en cause dans le monde dit "de la gestion".

De fait, le modèle technique qui tend à s'imposer est celui des "log d'événements immuables" : c'est justement le modèle des faits invariants défini pour les puits d'événements. Pour une argumentation convaincante sur ce nouveau modèle voir le long et lumineux article de Martin Leppmann : "Turning the data base inside-out with Apache Samza".

Les experts des micro-services, confrontés à la réalité de l'entropie naturelle, imaginent des architectures, dans une démarche "bottom-up". Ces démarches convergent de façon flagrante avec l'approche "top-down" de l'Architecture Flexible. Lire en particulier l'article très clair de Chritian Posta : "The hardest part about microservices : your data".

Une convergence nécessaire

Le schéma central de l'article de C. Posta correspond avec le type d'organisation de SI ciblé par l'architecture Flexible :

On voit bien qu’il y a coexistence de base « classiques » sur SQL et d’autres de type Elastic Seach.

Cet "event log" correspond bien à un « puits d’événements ». Il est instancié sur Apache Kafka.

Tout les avantages de la "promesse" de l'architecture Flexible sont repris par C. Pasta, avec un vocabulaire plus concret et technique :

This comes with some great advantages:

• we avoid expensive, potentially impossible transaction models across boundaries
• we can make changes to our system without impeding progress of other parts of the system (timing and availability)
• we can decide how quickly or slowly we want to see the rest of the outside world and become eventually consistent
• we can store the data in our own databases however we’d like using the technology appropriate for our service
• we can make changes to our schema/databases at our leisure
• we become much more scalable, fault tolerant, and flexible

Notably, this comes with disadvantages:

• it’s more complicated
• difficult to debug
• since you have a delay when seeing events, you cannot make any assumptions about what other systems know (which you cannot do anyway, but it’s more pronounced in this model)
• more difficult to operationalize
• you have to pay even more attention to CAP Theorem and the technologies you chose to implement your storage/queues

A noter que ne mettre en place que Apache Kafka, sans formaliser le log, n’a aucun intérêt : l’architecture repose certes sur la techno mais aussi sur la conception. Tant que les événements sont noyés dans des batchs il n’y a rien de possible ! Sans parler de la tri-datation. Il faut reconstituer un flux événementiel, souvent effacé par la mise en base de données. Par ailleurs, l’article montre bien que cette architecture, en organisant la division en domaines autonomes (mais interdépendants via le log), simplifie l’ensemble.

Il y a bien convergence, et possibilité d'enrichissement mutuel, entre ces approches.

Voir les systèmes par les événements

Suite à une mission concrète pour une entreprise, comment ne pas se perdre dans le SI ? avec ses strates, les a priori, les incompréhensions, les recettes miracles ?

La "Méthode" une sécurité ?

Chacun est friand de Méthode, de "pattern", de tour de main reconnu. Auteur moi-même de tels outils (la Trame Business, l'Architecture Flexible), la référence à ces efforts de conception est commode. Et l'on a toujours en réserve un catalogue de cas d'usage, précieuse justification de la Méthode.

Cependant, chacun doute toujours. Et il le faut, c'est la garantie du progrès. La Méthode n'est qu'un guide qu'il faut transgresser. Confronter ce guide à la réalité : on trouvera des faiblesses. Mais aussi des forces imprévues. Il en est une que j'affectionne particulièrement : la simplicité.

Un défi de complexité

Une mission brassant en un coup d'oeil l'intégralité de l'Entreprise est toujours un défi de complexité.

Un défi à lever dans un délai court et avec un temps d'analyse réduit. Il est clair qu'une approche d'Entreprise Architecture sophistiquée n'est d'aucun secours. Quand il faut plusieurs mois pour l'apprendre, on aura une mise en oeuvre en cohérence avec cette temporalité.

Comment rester pertinent en entrant cependant dans le sujet ? Il me semble que seule une approche "systémique" peut à la fois résumer le système et ouvrir des pistes pour l'analyse détaillée.

Mais cela ne suffit pas : il faut aussi comprendre les fonctionnement actuel, dans ses travers et subtilités.

Pour ce deuxième aspect, l'approche par les données permet de s'abstraire de multiples détails.

Abstraction, abstraction ? Quelles sont les clés ?

La vision par les données

La vision par les données est à la mode. A une époque, le concept de "puits de données" provoquait une incompréhension quasi totale. Les choses changent petit à petit. Le Data Centric est encore trop centré sur la découvert des technologies Big Data et des merveilleux Data Scientists.

Par les données, on réinvente l'Architecture du SI, et surtout on peut la mettre en mouvement avec quelques composants clés (les roulettes de la cathédrale...). Par les données on peut contourner les énormes blocs du Legacy, et préparer un fonctionnement du SI plus fluide. C'est tout le jeu de Lego de l'Architecture Flexible, pour lequel les bases technologiques existent. Mais un jeu qui est bien ailleurs, dans la conception même d'un SI : décider de ce qui est partagé et de ce qui est subsidiaire.

Donner du sens par les événements

La mécanique de l'Architecture Flexible doit répondre à des enjeux de transformation. Chercher le Business Model ? En a-t-on vraiment besoin ? On peut si facilement s'abstraire des configurations d'affaires, de l'organisation, des processus et des SI : il faut voir le système par les événements.

La Trame Business propose le modèle et permet une analyse fondatrice. Une abstraction salutaire.

Comme disait un interlocuteur découvrant une Trame Business réalisée lors de la mission récente : "Comment avez vous fait cela ?"

On lui demande pourquoi il pose cette question :

"Parce que cela représente bien la réalité."

Simple et efficace.

La réglementation GDPR défi d'Architecture d'Entreprise

La prochaine réglementation de protection des données personnelles (GDPR) sera en application dans l'ensemble de l'Europe dès mai 2018.

Pourtant, les entreprises et organisations ne semblent pas prendre la mesure de l'enjeu, de la sensibilité du sujet, de sa complexité, et des risques.
Par exemple peu de DPO (Data Protection Officer) ont été désignés. Pourtant ce prérequis est nécessaire. Face à une réglementation complexe, les DPO auront-ils le temps de l'assimiler ? Auront-ils les moyens d'agir d'ici l'échéance ?

Chaque entreprise devra faire des choix pour appliquer cette réglementation d'une centaine d'articles, et d'autant de "considérants"... et faire face à d'éventuelles procédures individuelles et collectives. Dès la promulgation de cette loi, européenne, les responsabilités sont clairement posées. Les DPO seront en première ligne, comment seront-ils outillés ?

Une situation paradoxale

Certes la nouvelle réglementation prolonge les réglementations précédentes, mais elle en change la magnitude :

• s'appliquant dans toute l'Europe, elle devient de fait obligatoire pour les multi-nationales,
• elle introduit de nouveaux droits (portabilité des données, droit à l'oubli, droits des mineurs, droit d'information en cas de piratage des données, ...) et des modalités de mise en oeuvre contraignantes (consentement clair et explicite, information compréhensible,...),
• les procédures de recours et les amendes ont été sérieusement durcies par rapport aux règles précédentes, les amendes administratives pouvant s'élever jusqu'à 20 000 000 EUR ou 4 % du chiffre d'affaires annuel mondial de l'entreprise.

Pour les entreprises, dès lors qu'elles ont une activité qui nécessite l'usage de données personnelles, le risque est patent. On peut douter de cette réalité, mais divers "contre-pouvoir" auront là une voie de recours, et il serait étonnant qu'ils n'en fassent pas usage.

Paradoxe donc entre l'apathie des entreprises et organisations, et les risques encourus, juridiques, financiers, et de dérapage d'image au cas où une pratique non conforme apparaîtrait au grand jour.

Un "tsunami" pour le SI ?

La GDPR est une problématique globale, systémique, pour le SI. Un enjeu aux infinies répercutions, dans les dédales du patrimoine SI. Un problème de type "An 2000" ou "Euro", genre de dépense qui n'apporte pas de valeur, et dont le coût est imprévisible ?

Le sujet est, en soi, plus complexe qu'à l'ordinaire. Complexe et incertain, car, sur bien des articles du texte, plusieurs interprétations seront possibles.

L'incertitude est stratégique : quelle anticipation, quelle vision ? qui croire des plus optimistes (doute sur l'application du texte, probabilité de contournement,  jurisprudence favorable à l'entreprise,..), au plus pessimistes (rigueur des procédures, exigences sociétales croissantes, ... ) ?

L'incertitude est aussi technique. La mise en conformité du SI, peu étudiée jusqu'à présent dans l'attentisme ambiant, sera-t-elle :

• Rapide, peu coûteuse, localisée seulement en certains endroits du SI ?
• Ou au contraire, au long cours, impliquant de multiples adaptations interdépendantes ?

Une question typique "d'urbanisme du SI", "d'Architecture d'Entreprise" 

La problématique centrale de l'Architecture d'Entreprise (EA), est de faire évoluer "en douceur" et à moindre coût, un patrimoine SI. La GDPR, par delà les questions stratégiques posées, relève typiquement d'une telle problématique.

Avec le temps qui passe, le défi prend de la force : le temps de cycle de l'EA est un temps plus long que celui des développements agiles, de par la complexité de systèmes empilés, imbriqués et étendus.

Particulièrement dans de grandes structures, tous les systèmes ne sont pas centralisés, il existe des silos organisationnels, des filiales, des entités locales... alors que le risque propagé par la GDPR est un risque d'image global. Le risque technique existe dans ces diverses configurations, et, par la structuration du SI qu'elle a créé, l'Architecture est critique pour ce risque.

Du point de vue "architectural", distinguer "cœur GDPR" et annexes

Au vu de la réglementation, et de ses multiples dispositions, il faut se donner un point de vue architectural,  Ainsi peut-on distinguer, dans les fonctions requises, des fonctions "cœur" et d'autres "annexes".

La réglementation implique des fonctions "cœur" :

• Fonctionnements des traitements réalisés qui doivent être conformes : ne pas réaliser un traitement correspondant à une finalité pour laquelle le consentement n'a pas été recueilli.
• Limiter le champ sémantique et l'historique des informations au minimum requis pour les traitements consentis,
• Exécuter le droit à l'oubli, etc ...

Ces fonctions sont complétées par des fonctions annexes, qui bien que majeures, s’appuient sur les fonctions "cœur" :

• Recueillir et gérer les consentements
• Informer les personnes des incidents survenus (atteinte à la sécurité, ...)
• Tenir un registre des traitements,
• Gérer les demandes de portabilité, ...

Bien sûr, ce n'est ici qu'une esquisse d'analyse du sujet, sommaire. Mais elle vise à faire un premier tri, et, par exemple, de clarifier les subsidiarités possibles (selon les finalités, les profils de personnes, les pays, ...) à prévoir dans l'Architecture.

La vision "cycle de vie du patrimoine"

L'Architecture d'Entreprise, par une approche méthodologique très orientée "grand projet", pourrait inciter à un "urbanisme" "haussmannien" : casser de grandes zones du SI pour les refaire à neuf.

Ceci serait possible dans le cadre de grands programmes, mais l'opportunité est rare. Le responsable de la mise en place de la GDPR n'aura certainement ni le délai, ni les moyens pour cette thérapie chirurgicale.

Le problème est dès lors :

• d'une part de statuer sur le cas de nouveaux développements au sein du SI, pour qu'ils soient "nativement" conformes (approche dite "privacy by design")
• d'autre part de faciliter une migration progressive du patrimoine, au fil de l'eau, de façon déconcentrée, pour s'aligner à la conformité.

On retrouve là encore un grand classique de l'EA, et des défis de long terme auxquels elle répond.

Propager la conformité au sein de l'iceberg SI

De ces premières réflexions émergent quelques idées simples :

• le cœur d'architecture est clé pour la conformité à la GDPR, que ce soit pour le "privacy by design", ou pour la propagation de cette conformité au sein de l'iceberg du SI existant
• ce cœur d'architecture est fortement générique, car reposant sur un modèle semblable quelques soient les organisations (personnes, finalités, activités, consentements)
• le schéma typique, pour ce cœur, fondé sur des référentiels pour la structuration, et des "puits de données" pour le traçage des interactions, relève de l'Architecture Flexible.

En somme, malgré la complexité inhérente au sujet, pour les entreprises et organisations, une possible voie est tracée. 

L'initiative du Club Urba-EA

Le  Club Urba-EA a décidé de prolonger ses travaux sur les pratiques en entreprise, par la mise en oeuvre d'un Laboratoire de la Flexibilité, dans le but de tester et démontrer des architectures innovantes. Dans le cadre de ce Laboratoire, la question des données personnelles sera l'objet de réflexions et de réalisations concrètes de prototypes.

Le cas de la GDPR, par sa généricité et son universalité, permettra de réaliser un démonstrateur de "moteur de conformité GDPR". Il illustrera le framework dont les bases sont indiquées ci-dessus.
Un tel produit simplifié sera un accélérateur, et levier d'architecture, pour les projets que les entreprise et organisations auront à conduire dans les mois qui viennent.