Sunday, September 24, 2017

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



L'originalité de l'Architecture Flexible


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

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

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

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

Un atterrissage technique à prouver


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

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

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

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


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

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

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

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

Une convergence nécessaire


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


On voit bien qu’il y a coexistence de base « classiques » sur SQL et d’autres de type Elastic Seach.
Cet "event log" correspond bien à un « puits d’événements ». Il est instancié sur Apache Kafka.

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

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

  • it’s more complicated
  • difficult to debug
  • since you have a delay when seeing events, you cannot make any assumptions about what other systems know (which you cannot do anyway, but it’s more pronounced in this model)
  • more difficult to operationalize
  • you have to pay even more attention to CAP Theorem and the technologies you chose to implement your storage/queues
A noter que ne mettre en place que Apache Kafka, sans formaliser le log, n’a aucun intérêt : l’architecture repose certes sur la techno mais aussi sur la conception. Tant que les événements sont noyés dans des batchs il n’y a rien de possible ! Sans parler de la tri-datation. Il faut reconstituer un flux événementiel, souvent effacé par la mise en base de données. Par ailleurs, l’article montre bien que cette architecture, en organisant la division en domaines autonomes (mais interdépendants via le log), simplifie l’ensemble.

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

Saturday, July 8, 2017

Voir les systèmes par les événements

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

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



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

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


Un défi de complexité


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

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

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

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

Abstraction, abstraction ? Quelles sont les clés ?

La vision par les données


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

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

Donner du sens par les événements


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

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

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

On lui demande pourquoi il pose cette question :

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

Simple et efficace.



Wednesday, March 1, 2017

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


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


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

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

Une situation paradoxale


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

  • s'appliquant dans toute l'Europe, elle devient de fait obligatoire pour les multi-nationales,
  • elle introduit de nouveaux droits (portabilité des données, droit à l'oubli, droits des mineurs, droit d'information en cas de piratage des données, ...) et des modalités de mise en oeuvre contraignantes (consentement clair et explicite, information compréhensible,...),
  • les procédures de recours et les amendes ont été sérieusement durcies par rapport aux règles précédentes, les amendes administratives pouvant s'élever jusqu'à 20 000 000 EUR ou 4 % du chiffre d'affaires annuel mondial de l'entreprise.
Pour les entreprises, dès lors qu'elles ont une activité qui nécessite l'usage de données personnelles, le risque est patent. On peut douter de cette réalité, mais divers "contre-pouvoir" auront là une voie de recours, et il serait étonnant qu'ils n'en fassent pas usage.

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

Un "tsunami" pour le SI ?


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

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

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

L'incertitude est aussi technique. La mise en conformité du SI, peu étudiée jusqu'à présent dans l'attentisme ambiant, sera-t-elle :
  • Rapide, peu coûteuse, localisée seulement en certains endroits du SI ?
  • Ou au contraire, au long cours, impliquant de multiples adaptations interdépendantes ?

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


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

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

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

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


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

La réglementation implique des fonctions "cœur" :
  • Fonctionnements des traitements réalisés qui doivent être conformes : ne pas réaliser un traitement correspondant à une finalité pour laquelle le consentement n'a pas été recueilli.
  • Limiter le champ sémantique et l'historique des informations au minimum requis pour les traitements consentis,
  • Exécuter le droit à l'oubli, etc ...
Ces fonctions sont complétées par des fonctions annexes, qui bien que majeures, s’appuient sur les fonctions "cœur" :
  • Recueillir et gérer les consentements
  • Informer les personnes des incidents survenus (atteinte à la sécurité, ...)
  • Tenir un registre des traitements,
  • Gérer les demandes de portabilité, ...
Bien sûr, ce n'est ici qu'une esquisse d'analyse du sujet, sommaire. Mais elle vise à faire un premier tri, et, par exemple, de clarifier les subsidiarités possibles (selon les finalités, les profils de personnes, les pays, ...) à prévoir dans l'Architecture.

La vision "cycle de vie du patrimoine"


L'Architecture d'Entreprise, par une approche méthodologique très orientée "grand projet", pourrait inciter à un "urbanisme" "haussmannien" : casser de grandes zones du SI pour les refaire à neuf.
Ceci serait possible dans le cadre de grands programmes, mais l'opportunité est rare. Le responsable de la mise en place de la GDPR n'aura certainement ni le délai, ni les moyens pour cette thérapie chirurgicale.

Le problème est dès lors :
  • d'une part de statuer sur le cas de nouveaux développements au sein du SI, pour qu'ils soient "nativement" conformes (approche dite "privacy by design")
  • d'autre part de faciliter une migration progressive du patrimoine, au fil de l'eau, de façon déconcentrée, pour s'aligner à la conformité.
On retrouve là encore un grand classique de l'EA, et des défis de long terme auxquels elle répond.

Propager la conformité au sein de l'iceberg SI


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

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

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

L'initiative du Club Urba-EA


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

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