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 » 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. Elle 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 apparait 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 accompagnes les articles du Règlement.

Vie de la Réglementation

Dernier des cycles à étudier : à tout seigneur l’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.

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

Initialisation du Plan Stratégique du Club Urba-EA

Les travaux sur le Plan Stratégique du Club Urba-EA ont été engagés en début 2016.

Le texte ci-dessous a recueilli un large consensus au sein du Conseil d’Administration. Il date du 17/3/2016. Il ne détaille pas les projets qui sont issus de cette réflexion, projets qui ont été examinés courant 2016 et début 2017.

Le texte ci-dessous est le schéma stratégique, sans aller au plan d’action.

Préambule

Le plan stratégique se décline en plusieurs niveaux :

Chapitre 1 : La vision

  • L’entreprise et son architecture
  • La place de l’Enterprise Architecture par rapport à ces enjeux
  • Les parties prenantes de l’EA

Chapitre 2 : Le projet stratégique du Club Urba-EA

  • Positionnement dans l’écosystème de l’EA
  • Déontologie
  • Apports de valeur, intelligence
  • Influence
  • Appartenance

Chapitre 3 : Le plan stratégique du Club Urba-EA

  • Produits, prestations
  • Clients, membres
  • Organisation
  • Communication externe
  • Développement

Ces 3 chapitres s’organisent du général au particulier.

Chapitre 1 : La vision

Il s’agit ici de se donner une perspective du contexte dans lequel l’Architecture d’Entreprise apporte sa valeur.

L’entreprise et son architecture

Les enjeux

Perspectives

L’Architecture d’Entreprise s’est développée pour la Transformation du patrimoine IT.

Du fait de la rigidité des « applications », de leur imbrication, des effets de cricket, l’EA traditionnelle apporte les « 3T » :

  • Transversalité
  • Compréhension Technologique
  • Moyen Terme

Cet apport, par transition, atteint les métiers, et le Business.

L’EA n’est pas un but en soi, et prend du sens dans ces perspectives.

Des finalités élargies

Les finalités traditionnelles demeurent :

On aura toujours besoin d’architecture:

  • pour les entreprises issues de « l’ancien monde » dans le développement de nouveaux modèles d’affaire
  • mais aussi pour les start-up qui ont intérêt à construire durable, l’architecture est vitale pour garantir leur développement
Inversion des contraintes et causalités

Au fur et à mesure que les contraintes IT s’effacent, les exigences de Business, les contraintes sociales et sociétales apparaissent avec plus d’importance.

Le SI est de plus en plus en lien direct avec les partenaires de l’écosystème, et le monde objet, et contribue à le formater. De nouvelles synergies sont apparues (Big Data, …) et apparaîtront.

De nouvelles « responsabilités » :

Les causalités du SI, dépassant les frontières de l’entreprise, participent à des responsabilités nouvelles (sécurité, protection, transformation économique, sociale, sociétale).

L’EA accompagne ce mouvement, contribue à ces responsabilités, en apportant la vision « 3T » au-delà des sujets traditionnels.

 

Un territoire extensif

Au-delà des frontières de l’Entreprise

La technologie efface les frontières de l’Entreprise, et les étend à l’ensemble de l’écosystème.

Les chaînes de valeur se transforment, et une vision plus globale devient nécessaire, au-delà de la vision traditionnelle centrée sur l’Entreprise.

Multiplication des cyberespaces

Les espaces immatériels, cyberespaces, sont des territoires économiques de plus en plus importants. Cette économie est en synergie, et en compétition, avec l’économie traditionnelle. L’Entreprise voit aussi son territoire d’opération étendu à ces espaces, où la compétition est globale. Le tissu industriel des cyberespaces est aussi en constante évolution, créant un chaos difficile à prévoir.

Des bases technologiques agitées

Le contexte Business est étendu, chaotique. Et la technologie n’est pas de reste, tout aussi secouée, les bases traditionnelles remises en cause par une extension protéiforme et en évolution extrêmement rapide (plateformes, monde connecté, …).

Des alternatives aux méthodes traditionnelles sont reconnues : méthodes « agiles », DevOps

Des coûts ont été réduits de façon drastique : mémoire de stockage, virtualisation, Cloud.

Ainsi l’appropriation des nouvelles solutions, elles-mêmes remises en cause dans un rythme accéléré, est un défi. Il implique des redéploiements, des changements culturels, des évolutions d’organisation, des partenariats.

Un contexte fortement imprévisible

Les évolutions, tant au niveau Business que technologique, rendent le contexte imprévisible. De plus des facteurs généraux renforcent cette difficulté.

 

Aléas sanitaires, climatiques, géopolitiques

Les économies nationales sont de plus en plus interdépendantes, avec une globalisation générale. Les aléas globaux, sanitaire, climatiques, géopolitiques, peuvent être destructeurs.

La « vivacité » pour conquérir ou survivre

L’Entreprise, et les organisations publiques, doivent accroître leur « vivacité » pour conquérir de nouveaux espaces de développement, ou simplement pour survivre dans le contexte de redistribution des cartes induit par la révolution en cours.

Contribuer aux paris stratégiques

Cette vivacité résulte de paris stratégiques, auxquels l’Architecture d’Entreprise doit contribuer.

 

Le projet « architectural »

Composante clé du projet d’Entreprise

 

L’Architecture est un sujet central

 

L’architecture est au centre du projet d’entreprise :

  • Dans les innovations Business et techniques, plateformes de mobilité, d’objets connectés,
  • Pour la sécurité, la gestion des informations individuelles,
  • L’insertion dans l’écosystème, les relations partenaires,
  • L’agilité à capter les marchés,
  • La conformité réglementaire.

 

Pour la Start-up comme la multi-nationale

 

Le projet « architectural » est déterminant dans le cas d’une start-up du numérique, qui parie sur lui comme outil central.

A l’opposé, le projet « architectural » est clé pour une grande structure, car il détermine son agilité, sa pérennité, son fonctionnement interne et au sein de son écosystème. Il règle la subsidiarité, la cohérence, la synergie entre les différentes transformations réalisées. Il organise la constellation des données au service des opérations, et de l’intelligence.

Pour le présent comme le futur

 

L’Architecture relie de fait le patrimoine du SI et des processus actuels, aux fonctionnalités futures.

Dans cette transition, elle conditionne les migrations applicatives et des données.

L’Architecture d’Entreprise, adaptée aux présents enjeux, doit proposer un projet synergique entre l’Ecosystème, où opère l’Entreprise, et l’espace traditionnel du patrimoine de l‘Entreprise (le « SI régalien »). Elle doit le faire dans la durée.

Un défi de complexité

Dans le contexte mentionné ci-dessus, le projet « architectural » est confronté à un défi de complexité.

Un alignement « dynamique »

 

Le « pari » n’est pas simple. L’époque de « l’alignement stratégique » est complétement dépassée.

L’EA, en tant que force de proposition du projet « architectural », doit intégrer toutes les dimensions du problème, dans l’instant comme dans la durée.

Cela remet en cause les fondements historiques de la fonction.

Un déficit de connaissance, de reconnaissance

L’architecture, au sens donné ici, souffre d’un déficit de reconnaissance.

Elle a longtemps été considérée comme un moyen faiblement stratégique, comme un centre de coût. Elle n’était pas reliée à de la valeur Business.

Les grandes méthodologies d’Enterprise Architecture ont été focalisées sur des « couches » intermédiaires, peu lisibles pour le management. La fonction EA apparait ainsi comme très spécialisée, fortement méthodologique, et, à la limite, bureaucratique.

Ce déficit de reconnaissance est préjudiciable à l’Entreprise, car de nature à troubler les enjeux du projet « architectural ».

Pour acquérir cette reconnaissance, la connecter aux enjeux, un effort de définition et de valorisation de la fonction EA est à conduire. En particulier en explicitant les « 3T » mentionnés ci-dessus, et en les contextualisant.

 

 

Place de l’Enterprise Architecture par rapport à ces enjeux

Il s’agit ici de la « fonction » EA, au service de l’Entreprise.

Une période d’instabilité et de remise en cause

Une géométrie variable

L’entreprise a besoin de la fonction « Architecture d’Entreprise », mais celle-ci peut être assurée selon diverses modalités d’organisation.

Dans les petites moyennes structures il n’y a pas de service dédié. Dans les grandes structures, la réponse organisationnelle peut être variable, et adaptée au cours de l’évolution des enjeux, en particulier avec l’évolution technologique et la transformation numérique.

Le positionnement historique de l’Architecture d’Entreprise est hérité des défis informatiques des décennies passées, il est remis en cause.

Une ouverture en perspective

Il faut que la fonction consolide les apports potentiels, qui découlent des enjeux actuels et futurs.

En outre, l’approche EA doit s’ouvrir, au-delà des disciplines IT, vers des disciplines plus orientées vers le management, le social, l’économie.

 

Déplacement du « centre de gravité » de l’EA

 

Les activités de l’EA à revisiter

 

Dans le cadre de la Trame des Activités

 

Les activités de l’EA sont représentées par la Trame des activités définie par le Club Urba-EA.

Ce schéma générique demeure une référence pour exercer les activités, mais il devra être revisité. En particulier le contenu de chaque activité est à adapter.

Redéployer l’énergie

 

L’énergie consacrée est à quantifier et redéployer. De sorte que le centre de gravité des activités se déplacera. Par exemple, on évitera de lourds investissements méthodologiques, rendus caduques par la flexibilité des solutions. On privilégiera la réalisation de socles d’architecture évolutifs, compatibles avec des scénarios de rupture, plutôt que des projets « tunnel », des migrations par Big Bang, des refontes ambitieuses, des déploiements massifs.

Changement de posture

Les Architectes d’Entreprise préfèreront expérimenter que cartographier, prototyper que prescrire. Ils passeront à l’acte, en développant et gérant des composants d’architecture, diffusant des normes fonctionnelles et techniques

Orientation Business et Data Centric

Plus impliqués dans la mise en œuvre pratique, les Architectes seront force de proposition pour le Business (voir à ce sujet les recommandations du Gartner).

Ils seront aussi en avance de phase pour utiliser le levier des données, dans les approches « Data Centric ».

Intermédiation (API, …)  :

L’AE devra en parallèle intermédier les nouveaux modèles d’affaires avec le Legacy qui ne peut être abandonné.

 

La définition de poste de l’Architecte d’Entreprise suivra ces repositionnements.

 

Les parties prenantes de l’EA

 

L’EA concerne plusieurs acteurs de l’Entreprise, voire à l’extérieur de l’Entreprise.

La Direction Générale

Les Directions Stratégiques

Les Directions de l’IT

Les prescripteurs généraux

  • « changement de posture » des autres parties prenantes du SI vis-à-vis de l’AE

 

Chapitre 2 : Le projet stratégique du Club Urba-EA

Positionnement dans l’écosystème de l’EA

Acteur de référence en France

Déontologie

Pas de parti-pris

Pas de « commerce »

Apports de valeur, intelligence

Influence

Communication

      • explication et vulgarisation,
        • Pour mémoire les travaux faits par le CEISAR sur « la fable du boulanger » sont exemplaires en terme de communication sur l’AE.
      • démystification et démythification

 

Appartenance

Chapitre 3 : Le plan stratégique du Club Urba-EA

En construction