Architecture Flexible et micro-services

Le développement de logiciels, après l’époque du SOA, et de ses architectures orientées services, a pris le chemin du développement fractionné en micro-services.

Les questions d’architecture se trouvent ainsi déplacées, sans que l’on puisse affirmer qu’elles gagnent en simplicité ou en complexité.

Dans le nouveau monde du bouillon de culture d’Hadoop, des solutions émergent, dans une découverte « botton-up » de l’architecture (Kafka est le produit phare de cette émergence).

L’architecture Flexible est, a contrario, une approche fondamentalement top down, partant des chaînes de valeur, de leurs invariants, avant d’entrer dans les visions du SI.

A la lecture de blogs d’évangélistes des microservices et des innovations des architectures événementielles, la synergie entre les 2 approches, l’une bottom up, l’autre top down, est fructueuse.

Sur ce sujet, voir le texte paru sur « Value-Architecture ».

Bonne lecture

La mutation de l’Architecture d’Entreprise avec le « Data Centric »

L’Architecture d’Entreprise « historique » en retrait

L’Architecture d’Entreprise s’est constituée par un lent processus de maturation, dans un contexte historique de technologies qui créaient de fortes contraintes, avec de multiples limitations, au regard des puissances technologiques que nous pratiquons maintenant.

Dans le monde actuel, nativement évolutif, cet historique pèse, et la discipline répond de plus en plus mal aux enjeux, se plaçant en retrait des mutations en cours.

L’Architecture d’Entreprise a toujours eu des leviers d’action limités

La fonction d’Architecte d’Entreprise provient du constat des errements créés par le désordre des projets.

Initialement, cette fonction se focalisait sur le périmètre des systèmes d’information, et a, pendant un temps, généré de grands projets avec une cible structurante pour le SI.

Cette époque est révolue, d’une part à cause des taux d’échec inhérents à de tels projets, de la complexité des migrations et intégrations, et de la réduction des moyens disponibles.

Une faible prise sur les projets

Dans l’idéal, ne pouvant casser le récif de corail du patrimoine SI, le plus efficace dans la durée serait un alignement progressif à une cible d' »urbanisme », au fil des projets.

Cet « urbanisme du SI » est une alternative pragmatique aux approches plus radicales fondées sur une démarche de structuration systématique et volontaire. L’Architecture d’Entreprise a en effet abouti à de lourdes méthodologies et une spécialisation professionnelle dont la justification est de plus en plus difficile, dans notre contexte d’agilité tout azimut (voir).

De toutes manières, tous ces efforts sont vains s’ils n’ont prise sur les projets.

Malheureusement, cette action sur les projets, dans le contexte méthodologique et technologique traditionnel, ne pouvait intervenir qu’à l’amont des projets. Dès lors plusieurs difficultés limitaient cet impact :

  • financement difficile des études nécessaires pour créer un apport de valeur tangible de la fonction EA,
  • multiplication des prérequis (cartographies, détours méthodologiques, gouvernance), discréditant la fonction,
  • rigidité de la démarche, adaptation aux aléas difficile, risque systémique accru (effet domino),
  • impossibilité de démontrer pratiquement l’intérêt pour le SI, et surtout l’apport métier.

De ce fait l’impact était affaibli, et on constatait que les projets prenaient, au long de leur cycle de développement, leur autonomie, continuant ainsi les errements habituels, au grand regret des Architectes d’Entreprise.

Finalement, les moyens de coercition de l’EA étant essentiellement théoriques, tout le monde se satisfaisait de la situation, les Architectes d’Entreprise dans leur « Tour d’Ivoire » et les acteurs projets dans leur « cambouis ».

Des investissements transverses minimalistes

Pourtant des besoins de transversalité apparaissent et motivent des actions pour sortir du cadre habituel des « silos » qui caractérisent la plupart des SI historiques.

Mais ces investissements transverses sont minimalistes. Ce sont :

  • les projets de Master Data Management, qui sont parsemés de difficultés et ont bien de peine à trouver les compromis qui satisfassent les divers points de vue, et des intérêts souvent divergents.
  • les projets de rationalisation des flux et échanges inter-applicatifs, qui se limitent à la mise en place de formats « pivots » entre les silos, et perpétuent, de fait, les fonctionnements lents et massifiés traditionnels.

Ces travaux ont une connotation technique telle que les métiers se sentent peu concernés.

Une discipline qui se réfugie dans la méthodologie et le détour

Du fait des fortes contraintes des anciennes époques technologiques, même si le besoin d’une vision globale procurée par l’EA était reconnu, cette approche s’est figée dans une posture académique.

La discipline s’est réfugiée dans une spirale méthodologique, accumulant les versions, le discours, et ne trouvant d’issue que dans le détour, et la recherche d’une cible idéalisée.

Avec l’inertie du bagage académique, l’évolution de l’EA ne pouvait être que de plus en plus en retard sur les évolutions du contexte, sur tous les aspects technologiques (méthodes agiles, micro-services, Big Data…), de Business, et d’usage.

L’Architecture d’Entreprise pilote stratégique des mutations

Cependant, la bonne nouvelle est que l’Architecture d’Entreprise peut disposer de moyens d’action opérationnels et de court terme, créant ainsi une situation totalement inconnue, une rupture, aux multiples effets bénéfiques.

Ainsi, l’Architecture d’Entreprise qui pourrait rester « à la traîne », peut-elle anticiper, selon son rôle traditionnel de visionnaire, et passer à l’acte au travers des projets. Elle peut devenir le pilote stratégique des mutations.

La possibilité d’action opérationnelle à court terme est un changement majeur pour l’EA

Par rapport aux acteurs des projets, l’Architecture d’Entreprise peut proposer une offre concrète de « composants d’intégration », qui leur permet de se focaliser sur la réponse aux besoins spécifiques d’un domaine métier, en s’appuyant sur des services transverses.

Les règles d’urbanisation proposent, et imposent, d’utiliser le levier des données et événements de référence, pour rationaliser progressivement le patrimoine SI, et le doter d’une flexibilité indispensable à l’agilité.

Ce nouveau moyen d’action est une rupture, qui rend obsolètes les lourds investissements méthodologiques, puisque le détour qu’ils préconisent peut être évité. Le chemin de migration et de découverte d’une cible se parcourt en effet progressivement, avec une validation et des apports de valeurs incrémentaux.

Une rupture visible et collant à l’actualité

Dans le parcours historique de la discipline d’Architecture d’Entreprise, cette rupture est majeure : elle donne, enfin, une visibilité et une crédibilité pratique, qui ont jusqu’à présent cruellement fait défaut.

Ce fait arrive à point nommé, car la mutation de la Société exige de l’Entreprise de plus en plus de transversalités, en particulier :

  • pour répondre aux exigences d’immédiateté et d’ubiquité du Digital
  • pour satisfaire des cadres réglementaires qui ignorent les divisions historiques par fonctions et métiers

L’Architecte d’Entreprise peut dès lors s’imposer comme l’acteur de référence, pragmatique, directement opérationnel pour la transformation de l’Entreprise.

Un acteur qui donne du sens

Ce nouveau positionnement opérationnel pourrait être confié à d’autres acteurs de l’Entreprise. Cependant, de par ses autres missions, d’intelligence des transversalités, de compréhension des cibles, raison d’être finale de la profession, l’Architecte d’Entreprise donne du sens à cette impulsion de court terme.

Car l’Architecte d’Entreprise doit intégrer, dans sa vision et ses actions, les principales dimensions  de l’Entreprise et de son modèle d’affaires. Traditionnellement, cette vision ne pouvait trouver d’aboutissement qu’à terme, au travers d’évolutions d’un patrimoine SI rigidifié. Le Data Centric, et plus particulièrement l’Architecture Flexible, permettent le changement de paradigme, et d’introduire de la flexibilité dès le court terme.

Les missions traditionnelles et cette ouverture opérationnelle se confortent en un ensemble ou chaque composante est indispensable : il faut de l’action et aussi du sens.

Un acteur clé du programme de transformation du SI et de l’Entreprise

La transformation de l’Entreprise, dans toutes ses dimensions, est tributaire de celle du SI. En particulier pour les exigences du « Programme Digital », et des contraintes réglementaires que nous avons cité.

Ce nouveau paradigme a de multiples conséquences :

  • sur la conduite du changement,
  • sur la démarche de conduite d’un programme « digital »,
  • sur la mise en oeuvre des composants d’architecture technique,
  • sur la stratégie d’achat (progiciels, composants du marché),
  • sur les méthodologies de projet (prise en compte des synchronisations, développement des API, gouvernance,…),
  • sur l’organisation autour des données,
  • et, bien sûr, le métier même d’Architecte d’Entreprise.

L’Architecte d’Entreprise devient ainsi un acteur incontournable de la transformation du SI, et par ce truchement, de l’Entreprise. Il participe au pilotage stratégique des mutations, et y apporte les composants essentiels.

Le quatrième pilier de l’EA

L’Architecture d’Entreprise a pris sa place en s’appuyant sur 3 bases fondamentales à son apport de valeur :

  • une vision à terme, indispensable pour converger, simplifier, réformer,
  • une conscience de la déformation du socle technologique, des dettes et opportunités associées,
  • le dépassement des silos, par la prise en compte des transversalités de l’Entreprise

L’Architecture Data Centric, et en particulier le type de solution proposée par l’Architecture Flexible, apporte un quatrième pilier, qui sera indissociable des autres.

On pourrait voir cet impact comme local, en certains points du SI, ou sur certaines particularités technologiques. En réalité il concerne tout le SI, toutes les technologies, toutes les chaines de valeur, pour le bienfait de l’Entreprise, et le renouveau d’une profession en voie d’assoupissement.

 

GDPR : Groupe de Travail du Club Urba-EA

Un Groupe de Travail du Club Urba-EA est constitué au sujet de la nouvelle réglementation Européenne GDPR sur les données personnelles (RGDP en français). Le premier semestre 2017 a permis de faire le tour des différents articles du règlement Européen, et de leurs nombreux impacts pour les Entreprises et Organisations.

Ces impacts sont à prendre en compte par l’Architecture d’Entreprise, en particulier :

  • Dans la définition des cibles de SI qui doivent être conformes aux prescriptions de protection des données personnelles (Privacy by Design)
  • Dans l’accompagnement des projets qui doivent appliquer les dispositions générales imposées par la Réglementation (portabilité, droit à l’oubli, consentement, …).

L’Architecture d’Entreprise permet d’éviter la dispersion des efforts, et met en commun un minimum de contrôle pour prouver la conformité et garantir l’alignement aux axes majeurs du Règlement.

Le Groupe de travail aura au deuxième semestre pour objectifs :

  • De produire une adaptation à la GDPR du Guide d’usage de la Trame des Activité d’Architecture d’Entreprise définie par le Club Urba-EA (ce guide est téléchargeable sur le site du Club),
  • De prolonger la définition de la Cible GDPR-EA, par un guide de mise en œuvre de cette cible,
  • D’identifier les produits d’aide à la mise en œuvre de la GDPR (composants GDPR, normes d’API, KPI, …), à élaborer en 2018 dans le cadre du Laboratoire du Club.

Pour ces travaux, le Club sera assisté par son partenaire juridique pour la GDPR, le cabinet DPO Consulting. Des contacts seront aussi pris avec des industriels de l’IT susceptibles de contribuer à la définition des produits envisagés.

Le Groupe de Travail sera animé par René Mandel, Nicolas Chevalier et Bruno Rizzi.

Le Groupe de Travail est ouvert sans conditions aux membres du Club Urba-EA.

Réglementation sur les données personnelles : partenariat Club Urba-EA DPO Consulting

Le Club Urba-EA a signé un partenariat avec le cabinet d’avocat DPO Consulting, cabinet spécialisé sur la protection des données personnelles.

Le Club dispose ainsi, dans ses actions sur la GDPR, du soutien d’une entreprise leader sur ce marché, et qui pourra nous apporter sa connaissance juridique et ses retours d’expérience sur les projets GDPR.

Dans le cadre de ce partenariat, lors du Collogue organisé par DPO Consulting, René Mandel a présenté l’analyse du Club des impacts SI de la GDPR.

Le polygone de Mandel de la GDPR protection des données personnelles

J’ai proposé, il y a quelques années, de représenter la combinaison de cycles et de parcours qui caractérise un écosystème, un type d’entreprise, … ou plus généralement l’activité complexe d’un système humain, social, économique, … sous la forme d’un polygone dont chaque segment symbolise un des cycles ou parcours typiques de la dite activité.

Ce « polygone de Mandel » (voir aussi) est en quelque sorte une signature.

Cette représentation permet une abstraction ultime, bien commode comme point de repère quand on aborde l’analyse des systèmes. Cela pourrait être une base de la systémique. D’une systémique adaptée au monde numérique, où l’événement est la source de toutes les transformations.

Après quelques temps d’analyse de la réglementation sur les données personnelles, le polygone typique apparaît clairement.

Parcourons les différentes faces de ce polygone :

Exercice des droits de la personne physique

La réglementation reconnait des droits de protection des données personnelles. Ceci existait déjà depuis la loi « informatique et liberté ». Les différents droits sont précisés, complétés et leurs modalités d’exercice explicitées. Plusieurs articles du Règlement Européen sont dédiés à ces définitions (droit à l’information, à la rectification, à la portabilité, à l’oubli, consentement, droit des mineurs, …) et modalités : par exemple le consentement doit être spécifique (pas de consentement passe partout), explicite, univoque (acte de la personne), libre (pas de relation de subordination).

Evénements et traitements

Tout système informatique réalise des traitements, et des données personnelles peuvent être impliquées dans de tels traitements.

La réglementation impose que ces traitements soient licites :

  • s’il s’agit de données « sensibles » (cf Article 9) un consentement de la personne est obligatoire
  • pour les autres données personnelles, le traitement doit avoir une base légale (contrat, intérêt légitime, obligation légale), sinon un contentement explicite est nécessaire.

Ce cycle opérationnel est donc encadré de façon fine (croisement personne, catégorie de données, traitements) et c’est le cœur de la « licéité ». Cette contrainte peut avoir un impact diffus au sein du SI et des processus de l’entreprise, même si, dans la majorité des cas, les traitements sont réalisés au titre de contrats existants.

La réglementation a une exigence structurante pour le SI : un registre des traitements doit exister et contenir des informations obligatoires sur chaque traitement (finalités, types de données, responsable, …).

Il ne faut pas perdre de vue que la GDPR est basée sur un changement de paradigme : finies les déclarations préalables à l’organisme de contrôle, maintenant la responsabilité est transférée à l’Entreprise. Celle-ci doit en particulier ouvrir son registre au contrôle, et disposer d’outils de démonstration de la conformité de ses traitements.

Ces exigences sont à la base de la proposition de plateforme de conformité mise au point par le Laboratoire du Club Urba-EA. En cible, cette plateforme, connectée aux services de traitement par APIs, attribue les droits à traitements en vertu des consentements. De façon plus immédiate, la plateforme centralise les traces de traitements concernant les données d’une personne, constituant ainsi un outil d’audit et de démonstration de la conformité. Elle trace aussi l’exécution des traitements de protection demandés (portabilité, droit à l’oubli).

Intrusions, violations, incidents

Du point de vue de la sécurité des données personnelles et des risques encourus par les personnes physiques, la réglementation souhaite un niveau de sécurité proportionné à ces risques.

Les défauts de sécurité apparaissent à l’occasion de divers événements, avec une menace croissante. Ce segment du polygone est donc un des plus sensibles pour respecter le droit à la sécurité. En cas de violations de données l’autorité de contrôle doit être prévenue dans un délai de 72 heures. Les personnes concernées doivent aussi être alertées explicitement.

Là encore, le principe de la Réglementation est de considérer l’entreprise comme responsable, à charge pour elle de faire la preuve de ses mesures de prévention (cryptage, anonymisation, architecture de sécurité,..), et de disposer d’outils de démonstration adaptés.

Administration de la Protection

Au centre du dispositif préconisé, et exigé par la Réglementation, est placé le Data Protection Officer. Il doit veiller au fonctionnement interne, et correspondre avec l’autorité de contrôle. Il sera aussi en première ligne en cas de contentieux, provenant d’associations, ou de procédure d’amende administrative initié par l’autorité de contrôle (les fameux 4% du chiffre d’affaires mondial).

Cette fonction de DPO doit donc être dotée d’outils pour surveiller la conformité, détecter les incidents, informer les personnes et l’autorité, … et démontrer la sécurité et la conformité. Certains outils plus généraux du marché peuvent remplis ces fonctions (pour la partie sécurité), mais des outils spécifiques GDPR ne sont pas matures. Il faudra faire appel à des développements internes ou des co-développements. Le fait de disposer de la cible de plateforme proposée par le Laboratoire peut dynamiser ce partage et faciliter une telle économie d’échelle.

Vie des traitements

Avec la vie des traitements apparaît un volet de la réglementation fondamental. On parle de « Privacy by Design » : il s’agit de faire en sorte qu’un nouveau traitement n’introduise pas de risque pour les données personnelles. Il faut donc qu’il soit « conforme » sur tous les aspects vus : licéité lors des traitements, exercice des droits (par exemple révocation d’un consentement, effacement des données qui ne sont plus nécessaires, portabilité,…) respect des finalités, sécurité (pertes, fuites de données …).
Dans ce but les nouveaux traitements, et évolutions de traitements existants, doivent faire l’objet d’une étude d’impact (PIA : Privacy Impact Assessement).

Cette étude d’impact doit examiner le volet informatique du nouveau traitement, en anticipant sur l’architecture, elle concerne donc les projets bien avant la date d’entrée en vigueur en mai 2018 de la GDPR. De ce point de vue beaucoup d’entreprises qui n’ont pas anticipé cette échéance auront quelques difficultés. En effet le projet GDPR est un projet transversal, impliquant de nombreuses dimensions de l’organisation, un projet complexe, pluri-disciplinaire (juridique, IT, sécurité, organisation, communication, formation,…).

Bien sûr une telle évolution ne pourra être immédiate pour l’ensemble du patrimoine des traitements, un délai de 2 ans pour la mise en conformité est prévu par le dernier des « considérants » qui accompagnent les articles du Règlement.

Vie de la Réglementation

Dernier des cycles à étudier : à tout seigneur tout honneur, la réglementation elle-même évoluera.

Des adaptations nationales sont prévues dès à présent, en nombre heureusement limité, car leur multiplication aurait un effet néfaste sur l’efficacité et la crédibilité du texte. On a raison en effet de reprocher à la Commission de vouloir tout régenter de Bruxelles, sans appliquer la subsidiarité.

De plus, avec le degré de complexité atteint, et la superposition avec d’autres réglementations, par secteur professionnel par exemple, il y a des zones de flou, de pratique, qui se révéleront. Et la jurisprudence sera aussi progressivement à prendre en compte.

La plateforme de conformité proposée par le Laboratoire répond à cette problématique, car elle se base sur des éléments d’architecture des données durables : les grains opérationnels, les grains d’exercice des droits, qui composent une architecture flexible.

Une entrée vers les chaînes de valeur

La méthode de la Trame Business dont ce texte est une illustration, permet d’aller plus loin dans cette approche systémique.

En effet les schémas précédents ne structurent ni les configurations économiques (par exemple la fonction de DPO peut être partagée, tel traitement peut être en tout ou partie sous-traité, …), ni l’organisation (qui peut être centralisée, répartie, subsidiaire), ni les processus, ni le SI.

Afin de quitter le niveau d’abstraction proposé par le polygone, il faut examiner les chaînes de valeur, segment par segment. C’est ce qu’on appelle l’analyse d’un « univers de valeur ». Notre polygone nous amène donc à l’analyse de 6 univers de valeur, chacun dédié à une « transformation » caractéristique, et à ses chaînes de valeur. Sur le blog de René Mandel on peut trouver plusieurs exemples de tels univers.

La séparation des cycles structure les processus, les transformations réalisées par les logiciels, et les informations elles-mêmes.

Dans le cas de la GDPR, on retrouve, dans l’organisation de la cible GDPR-EA proposée par le Club Urba-EA, l’articulation entre ces cycles. On en déduit clairement que l’organisation de la cible, loin d’être issue de la fantaisie d’un analyste, est rationnelle et durable, car fondée sur la segmentation illustrée ci-dessus.

Une architecture du SI indépendante de l’Organisation

L’architecture traditionnelle résulte de l’organisation de la maîtrise d’ouvrage

Traditionnellement l’architecture du système d’information était « moulée » sur l’Organisation. En effet, naturellement, la vision locale des « maîtres d’ouvrage » se traduisait, depuis l’expression des besoins jusqu’à la validation des projets, par une structuration du SI. Les synergies, les transversalités, entre les divers composantes du SI, se limitaient à un périmètre local.

Les SI se sont ainsi développés « en silos ». L’urbanisme des SI, puis l’Architecture d’Entreprise ont compensé cette tendance centrifuge, en proposant des projets transverses, une gouvernance centrale, des cibles communes, des architectures de confrontation, de consolidation.

Tous les modèles d’architecture sont désormais possibles

A l’époque du « data centric » faut-il que les architectures soient déformées, gouvernées, dans tel ou tel modèle ?

On voit bien qu’avec la technologie actuelle tout est possible : que le système évolue, au cours des projets, autour d’un modèle central, ou au contraire par une nébuleuse de systèmes synchronisés, ou toute solution hybride… tous ces modèles sont viables.

Mais les transformations d’architecture sont difficiles

En réalité, même si tout est possible sur une feuille blanche, le changement de modèle s’avère extrêmement difficile. Les migrations sont complexes. Les big bang sont coûteux et traumatisants. La gouvernance réveille de vieux conflits, pose des questions de principe, de préséance, … les positions figées sont archaïques au regard des potentiels technologiques.

Le problème est qu’on ne sait pas cibler l’usage de la technologie sur les quelques points de blocage de l’évolution d’ensemble de ces systèmes. On voudrait que les systèmes soient, dans toutes leurs composantes, mis en mouvement, ce qui est bien sûr complexe, et impossible dans une échelle de temps raisonnable. On pense au mieux que la définition d’une cible permettra d’atteindre progressivement l’objectif. Malheureusement ce type de solution, encore viable il y a quelques années, est dépassé et discrédite les Architectes d’Entreprise, et leurs diverses écoles, leurs certifications et lourdes méthodologies.

Pour transformer l’architecture, placer l’Architecture Flexible en son cœur

Abandonnant ces ambitions irréalistes, on se concentre sur le cœur d’une architecture en l’Etat de l’Art : une plateforme d’intégration. On agit sur ce noyau et sur ce noyau seulement. C’est ce que propose l’Architecture Flexible, en définissant une telle plateforme, qu’elle soit centralisée ou composée de systèmes autonomes synchronisés.

L’exemple de la réglementation sur les données personnelles

Par exemple, pour répondre aux impératifs de la gestion des données personnelles (RGPD alias GDPR), il faut introduire de nouvelles transversalités. Cela peut se faire de façon dispersée en instillant les fonctions nécessaires dans les différents silos. Cela peut aussi se faire grâce à une plateforme partagée, dite « plateforme de conformité ». Cette dernière solution permet une introduction progressive, et opportuniste, des fonctions de conformité, sans big bang, et avec une géométrie variable.

 

En somme, juste retour des choses, il devient alors plus facile de changer un SI flexible, pour l’adapter à l’Organisation, tout en préservant les transversalités, et les invariants, que de se lancer dans le changement frontal de l’Organisation. A terme, avec un tel SI flexible, l’optimum organisationnel, libéré des rigidités du SI, sera trouvé par transformation progressive, et adaptation darwinienne.

Puits de données et puits de meta-données

L’analyse de la réglementation sur les données personnelles donne l’occasion d’une réflexion sur les puits de données.

Dans le monde opérationnel, qui est l’objet des interactions, des flux, des échanges de données, on repère facilement les « puits de données ». En effet, dès lors qu’il y a un cycle, on peut lui consacrer un puits, qui, à l’occasion des événements du cycle, trace les données caractérisant l’objet concerné par l’événement (changement d’état de l’objet) et celles qualifiant l’événement.

De façon plus globale, la méthode « Trame Business » propose un modèle de tous les cycles et parcours : le polygone de valeur (ci-dessous, le cas des « utilities »).

Polygone de valeur : Identification des puits

Pour une description plus complète de cette méthode voir le site « Value Architecture ».

Dans le cas de la GDPR, il nous faut :

  • enregistrer les consentements pour les données d’une personne, vis à vis de traitements. Cet enregistrement doit être historisé, car la personne peut, à tout moment, retirer son consentement. Il s’agit donc d’un puits dédié au cycle des consentements. Il concerne des meta-données : le dictionnaire des informations de telle personne,
  • enregistrer les validations de traitement accordées lors des demandes de traitement des données de telle personne. Il s’agit là de données « opérationnelles » utiles aux traitements.

On aura donc, dans le premier cas, un puits de meta-données, et dans le deuxième, un puits de données.

En somme, la figure de style « puits » peut être utilisée quel que soit le cycle, tout est une question de vision. Il n’y a pas de monde opérant, mais plusieurs visions des mondes, comme dans un infini kaléidoscope.

Les visions amenées par ces différents cycles et parcours apportent leur lumière sur autant de transformations, qui se combinent en fractales à l’infini. Comme les multiples vies dans un écosystème.

On sort ainsi du cadre stéréotypé de la systémique.

 

Projet de « plateforme de conformité à la GDPR » (Privacy by Design)

La nouvelle réglementation européenne (GDPR) sur les données personnelles impose le consentement explicite, clair et révocable, des personnes physiques sur la finalité des traitements utilisant leurs données.

Elle doit être en application en mai 2018 pour les entreprises et administrations, avec un arsenal de pénalités dissuasif.

On comprend aisément que le patrimoine SI actuel n’est pas en conformité avec cette réglementation. Dans les grandes entreprises et organisations, au delà des finalités initiales, des « propositions de valeur » complémentaires sont apparues. Certaines clauses complexes créent une insécurité juridique, et on peut craindre alors qu’il faille revoir les règles d’alignement à la Réglementation. On se doute que les impacts sont multiples, diffus, voire évolutifs. Un travail difficile à évaluer, et des délais bien courts.

On est face à une problématique type An 2000 ou Euro, avec plus de subtilité juridique.

Une approche est d’évaluer les écarts, les risques, et de prioriser. Des prestataires sont sur le sujet. Des guides sont élaborés. La complexité du discours juridique est importante, et jette un trouble cachant l’essentiel.

Dans le fond, l’implication de l’Architecture du SI est évidente : l’Architecture existante a été conçue alors que certaines contraintes n’existaient pas, ou existaient sous une forme réduite (déclaration à la Cnil, pas de gestion fine des consentements,…) et fragmentée par pays.

Maintenant la question est différente, globale, et la responsabilité clairement transférée aux entreprises et organisations (désignation d’un DPO, Data Protection Officer qui est en première ligne).

Ce sujet ne pourra être traité au long cours sans un alignement de l’Architecture. Il ne pourra l’être par Big Bang, mais par une évolution progressive, et une adaptation aux impératifs et risques majeurs.

Typiquement une Architecture Flexible est nécessaire. Flexibilité d’adaptation au contexte architectural, flexibilité aussi pour coller aux évolutions. Justement le Club Urba-EA a créé le Laboratoire de la Flexibilité pour tester des Architectures innovantes.

L’opportunité est de monter un démonstrateur simplifié d’une « plateforme de conformité » à la GDPR. Dans le principe, il s’agit tout simplement, pour une Entreprise ou une Administration, de mettre au centre de son SI, et de ses échanges et interactions (quels que soient les protocoles ou latences), une plateforme du type de celle définie pour l’Architecture Flexible. Cette plateforme vérifie la conformité de ces interactions (au niveau du « grain » fin) : pour chaque personne, et selon les règles à appliquer (et en particulier l’état des consentements, validés ou révoqués), elle les autorise, ou émet le signal approprié, au cas par cas.

On peut démontrer ce fonctionnement pour un projet neuf, avec des cas types de traitements construits en symbiose avec cette plateforme de conformité. Cette simplification a du sens, car, si on ne sait pas traiter ce sujet, on ne pourra pas, a fortiori, s’attaquer au « plat de spaghetti » du patrimoine existant.

Dans le même ordre d’idée, on pourra démontrer le fonctionnement d’un « puits » destiné à tracer les interactions et traitements concernant les personnes. Ce composant, non intrusif, permettrait d’auditer le fonctionnement d’une partie du patrimoine, au regard de la réglementation. L’avantage est aussi qu’il préfigure le fonctionnement nominal en cible, en créant le puits d’historisation pour la traçabilité (nécessaire à la portabilité des données, aux droits à l’information, à l’oubli, à l’opposition, …).

Ce n’est donc pas techniquement un saut dans l’inconnu, on dispose largement des technologies nécessaires (API management, data integration, SGBD, …). D’une entreprise à l’autre la question de la conformité se pose dans une logique similaire, il faut simplement changer le paramétrage des finalités, traitements et consentements. La rupture, par rapport à la réglementation en vigueur actuellement, est l’exigence de finesse dans le croisement personnes-données-traitements et finalités qui est le « grain » opérationnel d’exécution des consentements. La gestion des consentements prévue à l’Article 7 du règlement (« le responsable du traitement est en mesure de démontrer que la personne concernée a donné son consentement au traitement de données à caractère personnel la concernant »… »La personne concernée a le droit de retirer son consentement à tout moment ») ainsi que le droit d’opposition à la prospection (Article 21) impliquent un grain d’exécution fin et daté.

La structure ainsi créée, plus exigeante que celle découlant de la réglementation précédente, place l’autorisation de conformité (la licéité) au cœur du SI. C’est un sujet générique global (tout pays, transverse aux métiers), et stable car fondé sur l’architecture de la réglementation.

Bien sûr, dans le cas du « démonstrateur », on se limitera à quelques cas d’usage typiques (rejet d’un traitement qui ne satisfait le consentement d’une personne, mise à jour par une personne de ses consentements, audit des traces enregistrées par la plateforme, …). On ne cherchera pas non plus à instancier ce moteur sur une architecture technique cible de référence, ni à l’adapter à celle de telle ou telle entreprise. Il s’agit d’un démonstrateur « fonctionnel ».

Les fonctions, enrichies et sécurisées, seront à reprendre par chaque entreprise pour les implanter sur son architecture interne, son espace sécurisé (résistance aux intrusions, scalabilité, cohérence…), et en vertu de sa stratégie de prise de risque juridique. Elle pourra dès lors faire état de son engagement vers ce qu’il est convenu d’appeler une « Privacy by Design« .

De ce fait le démonstrateur pourra être réalisé dans des coûts et délais raisonnables (le Club pouvant travailler par exemple en co-développement avec certains partenaires). Pour chaque entreprise partenaire, il pourra servir de base pilote dans le cadre d’une transposition en « vraie grandeur », sur son contexte spécifique. Il permettra aussi d’illustrer les chemins de migration et de bascule progressive, et par ensembles réduits, du patrimoine existant à mettre en conformité. On s’intéressera à des cas types représentatifs choisis par les partenaires (campagne marketing, …), en esquissant les solutions qui se présentent, dans tel contexte architectural (CRM, ESB, …).

Ce projet pourrait aussi montrer l’utilisation d’une « architecture inversée », laissant certains utilisateurs gérer leurs propres données personnelles. On peut envisager de prototyper ainsi, autour du démonstrateur, différents scénarios d’architecture plus ou moins inversée, par exemple se basant sur la technologie émergente de la blockchain, ou en liaison avec des projets concernant les données personnelles.

Au delà de cette première phase de réalisation d’un démonstrateur, le Club Urba-EA n’a pas vocation à finaliser un produit à mettre sur le marché. Le Laboratoire de la Flexibilité, ayant rempli sa mission, pourra développer une démarche similaire sur d’autres sujets.

Ce projet simple et rapide a un très fort ROI, permettant d’accélérer et de fiabiliser les travaux de mise en conformité à la réglementation. Un projet agissant au cœur du SI des grands opérateurs, tout en préparant les architectures de « self data » futures.

Une réunion d’information est organisée le 5 avril à Paris (une première réunion a intéressé 40 personnes de divers profils : CIL, Data Officer, Architecte…). Pour vous inscrire et recevoir une invitation.

Voir aussi sur le blog de René Mandel.

Gestion des données personnelles : impacts sur l’Architecture des SI

La Réglementation Européenne sur la gestion des données personnelles (GDPR) s’appliquera aux entreprises et organisations en mai 2018.

Cette réglementation implique une mise en conformité du patrimoine SI, pour répondre aux droits des personnes de contrôler leurs données personnelles et d’approuver les finalités des traitements.

Les conséquences de cette Réglementation sont donc multiples et étendues à l’ensemble du SI.

Afin de cibler l’initiative que peut prendre le Club Urba-EA face à ce sujet majeur, toute entreprise ou organisation peut répondre à l’enquête ouverte en suivant le lien ci-dessous :

Enquête GDPR du Club Urba-EA

Par avance merci pour vos réponses.

Laboratoire de la Flexibilité

Urba-EA officiel

LABORATOIRE DE LA FLEXIBILITE

 

Le 19/01/2017                                                                                                       version 1

Rédacteur : René Mandel

 

Projet

Projet de Laboratoire de la Flexibilité au Club Urba-EA

La fin de règne des méthodologies

Pendant plusieurs décennies, les concepts d’urbanisation, puis d’Architecture d’Entreprise ont été soutenus par des approches méthodologies, au niveau international, comme en France.

Il était en effet difficile de mettre de l’ordre dans les systèmes accumulés au cours des différents projets informatiques, sans de telles approches, et la définition de cibles permettant une convergence au moins partielle. Certaines approches ont proposé des modèles intégrés couvrant tout le domaine de l’entreprise (comme Ceisar, Praxeme, …), et des méthodologies globales se sont imposées (Togaf, frameworks des Administrations,…).

Le contexte actuel avec :

  • la transformation numérique, et l’accélération des ruptures business,
  • les nouvelles modes technologiques, et la remise en cause de l’ingénierie du développement traditionnel

est très défavorable à l’Architecture d’Entreprise.

Cette discipline apparaît déphasée des doubles réalités tant Business que IT.

Une évolution était nécessaire (voir l’alerte  sur le futur de l’architecture d’entreprise), et une rupture identifiée (voir l’article).

Les réflexions stratégiques du Club Urba-EA

Dans ce contexte, le Club Urba-EA a conduit des réflexions stratégiques, dont le cadre est repris ici.

Le déplacement du « centre de gravité » de l’Architecture d’Entreprise est une des orientations qui découlent de cette analyse. Il s’agit en particulier de positionner les Architectes d’Entreprise en relation plus directe avec la technologie qui permet la mise en œuvre des architectures.

Il a aussi été envisagé de participer à des travaux innovants, en inter-entreprises.

La diversification des modalités de travail du Club fait aussi partie des sujets envisagés.

Le présent projet de Laboratoire entre tout à fait dans ces orientations, qui visent à donner un nouveau souffle à l’Architecture d’Entreprise et à ses apports de valeur.

La mise en commun d’expériences et de moyens

 

Le Club Urba-EA permet aux membres de partager des retours d’expérience, et des analyses de l’état des marchés technologiques.

Les Grandes Entreprises et Organisations pourraient créer en leur sein, au-delà des Data Lab et autres structures transverses existantes, des Laboratoires pour formaliser la R&D sur l’Architecture d’Entreprise. De tels investissements pris isolément sont difficiles à justifier, surtout dans le contexte actuel de recherche d’économies et d’agilité de court terme.

Le recours à un Laboratoire externe présente plusieurs avantages :

  • Frais réduits, du fait du partage des ressources
  • Mise en commun des problématiques concrètes liées aux nouvelles réglementations et aux architectures nécessaires (données personnelles, écosystème bancaire, …)
  • Facilité de mobilisation d’un apport externe
  • Gouvernance de la transversalité réduite
  • Géométrie de l’engagement variable
  • Capitalisation sur un savoir-faire de mise en œuvre complète (de la conception aux architectures techniques) dans un cadre inter-professionnel
  • Mise en évidence de scénarios typiques, création de benchmark

Le Club Urba-EA apporterait à ce projet une garantie d’objectivité et d’intégration dans l’écosystème de l’IT. En particulier le Laboratoire aurait un apport original par rapport aux réalisations internes (Data Lab, veille technologique), se focalisant sur les sujets de l’EA, souvent laissés pour compte dans des visions précipitées et partielles.

Une « Charte » conforme aux attentes et déontologies

 

Le Club Urba-EA est aussi crédible pour élaborer la Charte du Laboratoire, en conformité avec la réglementation, et avec la déontologie pratiquée par le Club.

Il est crucial en particulier que soient réglées les questions de confidentialité et sécurité de l’action du Laboratoire. De même son objectivité vis-à-vis des différents prestataires (éditeurs, services dont Oresys) doit être garantie.

Une opportunité : la flexibilité

 

Le Laboratoire peut être amené à travailler sur de multiples sujets communs, et dans leur mise en oeuvre pratique.

Dans l’Etat de l’Art actuel existent des solutions de flexibilité qui bousculent les approches lourdes traditionnelles, et le Laboratoire pourra utilement mettre en œuvre ce type de levier, au travers de différentes solutions techniques.

En particulier l’Architecture Flexible est un concept maintenant stabilisé, dont tous les traits fondateurs ont été définis et publiés (voir en particulier le site dédié).

Ce concept novateur est susceptible d’être employé librement par les entreprises et organisations pour fonder leurs projets, et plus globalement leur SI. Comme son nom l’indique, cette Architecture utilise des bases conceptuelles qui facilitent les multiples évolutions prévisibles (du Business, des métiers, de l’organisation, des technologies), et les réactions aux imprévus sur ces différents sujets.

La mise en œuvre de ce type de flexibilité présente une innovation :

  • par rapport aux démarches classiques qui basaient un système sur des solutions techniques et conceptuelles figées, avec des cibles fixes,
  • par rapport au cycle projet « en cascade », en préconisant une démarche incrémentale tout au long du cycle de vie de l’Architecture.

Le Laboratoire permettrait de mener rapidement des POCs de telles flexibilités et de capitaliser sur les solutions concrètes, piliers de l’Architecture, domaine par domaine.

De multiples déclinaisons possibles

 

En effet la flexibilité est basée sur les invariants des informations, en ce sens ce type d’approche incrémentale est « Data Centric », synchronisée sur les événements fondateurs du Business et des transformations :

  • Adaptée au contexte et à ses spécificités,
  • Connectant l’historique du patrimoine (SI, métier, expérience) et le présent (projets en cours) et le futur (économie numérique, IoT, …),
  • Indépendante des variantes technologiques, des évolutions des processus et organisations.

A partir d’un même modèle générique, autant d’implémentations adaptées aux cas d’application sont déductibles et démontrables.

Par ailleurs ce type d’Architecture utilise les offres technologiques de la Data Integration et de l’API Management, ce qui ouvre à de nombreuses variantes technologiques selon les offres du marché et les choix des entreprises.

Comment initialiser

 

Les grandes lignes du Laboratoire sont décrites. Mais il reste beaucoup de questions à régler et de choix à faire pour positionner ce nouvel acteur de l’EA.

Une première liste :

  • Quels sont les modèles de saisie du Laboratoire, par exemple :
    • Sur des projets communs définis au sein du Club, pour étudier des scénarios face à une nouvelle réglementation qui s’impose à plusieurs membres.
    • A la demande d’un membre de Club, sur un projet où un POC d’architecture serait utile.
    • Pour créer un « benchmark » de référence à opposer aux éditeurs.
  • L’accès aux services du Laboratoire serait-il restreint aux membres du Club, ou, au contraire, ouvert à tout type d’organisme ?
  • Quels seraient les modèles de contrat avec le Laboratoire :
    • des utilisateurs : forfait annuel, contrat cadre, commande unitaire, …
    • avec les fournisseurs de ressources (éditeurs, mises à disposition,…)
    • Quelles clauses de confidentialité, de sécurité, de propriété sur les résultats
  • Quelles sont les étapes de lancement du projet, avec des échéances de court terme
  • Quelle ouverture pour des participations stratégiques, et quelle gouvernance.
  • Quelles ressources dédiées, au-delà des sous-traitances ponctuelles

Business plan

 

Le budget, en régime de croisière, dépasserait le budget actuel du Club. En effet, même s’il y a un recours à de la sous-traitance (freelance technique), il faut sans doute constituer le noyau d’une équipe permanente.

Les ressources pourraient venir :

  • d’une participation du Club Urba-EA (mais dont le budget reste limité)
  • des grands utilisateurs, qui pourraient contribuer par des ressources internes, ou investir dans des projets IT où le Labo serait un outil mobilisable,
  • d’éditeurs mettant à disposition leurs solutions.

En toute hypothèse il faudrait fonctionner en harmonie avec l’écosystème des associations IT (Cigref, CRIP, …).

Une ouverture pour le Club Urba-EA

 

Le concept de Flexibilité a donné lieu à des expériences limitées, face à l’étendue des usages possibles.

Les Entreprises et Organisations, en l’absence de référencement par les grands cabinets, par les chaires d’enseignement, les organismes de recherche, les doctrines  de marché, sont réticentes à faire le pas. En ce sens, par conformité aux standards « historiques », elles préfèrent les approches traditionnelles, dont on connait pourtant les risques et la sinistralité (voir le rapport « Chaos » du Standish Group).

Des alternatives ont vu jour, trop souvent ignorant la vision globale et de moyen terme qui est la raison d’être de l’Architecture d’Entreprise.

La mise en évidence de cas similaires, de retours d’expérience, permettrait une mise en mouvement des Architectes d’Entreprise, et une amélioration significative  de la sécurité et du ROI des projets, dès le court terme.

Au-delà des péripéties actuelles, les nécessités et justifications de l’EA, certes transformées, demeurent : transversalités ignorées, faible anticipation sur le moyen terme, opportunisme de courte vue, absence de vision globale, prééminence du détail et de la fébrilité de l’agile.

En somme le projet s’impose pour :

  • élargir l’audience du Club, hors des murs du Club
  • démontrer la réalité de la flexibilité du SI au service d’un Business en constante recherche d’agilité
  • diversifier les moyens d’action du Club
  • dynamiser l’image du Club comme vecteur de progrès