L’Architecture Flexible : synthèse

L’Architecture Flexible

Document déposé le 27 mai 2018 à fin de preuve de copyright.

Ce texte est reproduit ci-dessous :

L’Architecture Flexible, est une innovation proposée par René Mandel, à la suite de ses travaux sur la ©Trame Business, sur les ©Puits d’événements, et la tri-datation.

Comme son nom l’indique, l’Architecture Flexible permet de rendre un système d’information adaptable aux évolutions, et, par voie de conséquence, de rendre le système résiliant.

L’Architecture Flexible attribue, lors de la conception de l’architecture, la priorité à la recherche de flexibilité, pour ne pas enfermer le futur système dans des solutions bloquantes et complexes.

La Flexibilité est obtenue essentiellement par la technique de conception mise en œuvre, une conception créant les leviers de flexibilité. Elle est aussi résultante de l’emploi des technologies pour libérer les contraintes issues du passé, et en particulier du mode d’échange historique, non synchronisé et à date brouillée.

 

Les différentes flexibilités

 

Le schéma ci-après symbolise les différentes flexibilités procurées par l’architecture. Elles confèrent une agilité « stratégique » pour l’entreprise, impactant son devenir à terme :

 

  • Flexibilité « Ecosystème » : l’Entreprise en s’adaptant aux enjeux de son écosystème, peut mettre à profit ses atouts le long des chaînes de valeur, et réagir aux aléas économiques. Par exemple anticiper une désintermédiation, en disposant d’une Architecture SI adaptable à ce scénario. Ou bien prévoir l’éventualité d’une nouvelle répartition de la chaîne de valeur productive, par une co-production avec un nouveau partenaire (mise en œuvre de référentiels et de puits gérant la subsidiarité).
  • Flexibilité « Transversale » : l’Architecture connecte les silos et donne une vision transverse.
  • Flexibilité « Technologique » : l’Architecture inter-fonctionne avec l’ensemble du patrimoine, quelle que soit son histoire technologique. Elle permet d’hybrider l’existant avec les nouveaux composants, les micro-services.
  • Flexibilité de Migration : l’ingénierie des flux et l’orchestration des appels de services, basées sur les Puits d’événements, permet les migrations douces par l’organisation de nécroses et de couveuses des composants du SI.
  • Flexibilité de Transformation numérique : l’Architecture, fondée sur les événements, est nativement adaptée aux chaînes de valeur numériques (mobilité, IoT, collaboratif).

 

Les « piliers » de l’Architecture Flexible

 

L’Architecture Flexible[1] est basée sur un constat d’évidence.

 

 

 

 

L’Architecture Flexible utilise dès lors, de façon systématique, ces invariants comme « piliers » de l’Architecture. Les piliers sont des composantes fixes de l’Architecture, et toutes les autres composantes seront a priori interchangeables, modifiables, et il faudra faire en sorte qu’elles le soient.

En se focalisant sur les invariants, l’Architecture Flexible donne une vision simplifiée du SI, réduite à l’essentiel, et praticable.

Dans le contexte de transformation numérique, avec l’agilité requise, et l’émergence de logiques événementielles, l’Architecture Flexible est une réponse adaptée. Comparée aux approches méthodologiques lourdes prescrivant des visions exhaustives spécialisées soit par ressource (Zachman), soit par niveau de zoom (FEAF, Togaf). L’Architecture Flexible ne nécessite, pour les composants situés hors architecture, aucun choix de conception, de modélisation, de technologie : seules sont à respecter les standards de connexion à l’Architecture, ce qui laisse les « domaines » totalement libres de leur dynamique d’investissement technologique (traditionnel, versus ouverture vers le non structuré, le multimédia).

Dans un paysage SI et Business agité et de plus en plus incommensurable, il est irréaliste de vouloir le cartographier, le décrire dans une vision figée : l’Architecture d’Entreprise doit être une Architecture de la Flexibilité, ou migrer vers le placard aux oubliettes.

L’Architecture Flexible est fondée sur des « piliers » qui sont :

  • les invariants des chaînes de valeur(les cycles et parcours)
  • et les invariants des objets de l’écosystème (les entités du monde réel : personnes, patrimoine, produits, services, et leurs cycles de vie, leur datation).

Ces piliers ont des bases objectives, bien au-delà des choix et technologies SI, de la configuration des processus, de la fragmentation de l’organisation, des silos métier,…

Grâce à la ©Trame Business et à l’approche ©Puits d’Evénements, les invariants sont facilement identifiables : rien n’est dû au hasard et le design de l’Architecture Flexible est en grande part déterministe (voir ci-après).

 

Pilier 1 : les informations de référence statiques

Il s’agit de l’Identification et caractéristiques d’identité des objets du monde réel (personnes, clients, entités économiques, éléments de structure, d’organisation, produits, services, nomenclatures diverses et variées, …). Ce sont les informations que l’on peut organiser au sein d’un MDM, ou dans un ERP, ou dans tout dispositif technico-organisationnel de gestion de la cohérence, au sein de l’Entreprise. Ou de façon plus globale, au sein d’un écosystème, voire d’un périmètre social ou économique. Cette cohérence s’appuie sur des systèmes d’information, mais répond à des enjeux plus généraux (sociaux, sanitaires, synergie des métiers, efficacité, qualité des chaînes de valeur, …).

Du point de vue de la politique d’achat de l’Entreprise, la question de son autonomie par rapport aux fournisseurs des solutions « intégrées » se pose. Il peut être préférable de « sortir » la gestion des référentiels du périmètre de ces solutions. C’est aussi un degré de liberté ainsi créé, qui peut être nécessaire pour une Architecture Flexible.

 

Pilier 2 : Les informations de référence dynamiques

Les informations de référence dynamiques sont à l’origine des flux et échanges opérationnels entre les acteurs des chaînes de valeur, typiques des cycles de vie des objets du monde réel. Il est fondamental de distinguer ce type de pilier, par rapport au précédent, car les pratiques sont différentes, mal reconnues, partielles (pivot SI résolvant seulement une partie du problème). Ceci correspond au concept de ©Puits d’événements formalisé par René Mandel.

 

Pilier 3 Les modèles de chaîne de valeur

Les chaînes de valeur sont bien sûr variables, et ne peuvent être prises telles quelles, comme base. Par contre, pour un cycle particulier, la structure de ces chaînes est fortement invariante. La ©Trame Business permet de dégager cette structuration et de constater :

  • d’une part l’invariance des cycles et parcours, des événements initiateurs de chaînes de valeur,
  • d’autre part la grande stabilité de segmentation des chaînes de valeur, segmentation correspondant à des ruptures physiques (logistique, fabrication, …), réglementaires, professionnelles, ou d’optimisation économique (opérateurs spécialisés). Cette stabilité guide la conception de l’Architecture Flexible.

Dans le domaine étudié (un sous-ensemble de l’Entreprise, l’Entreprise dans sa globalité, voire un écosystème), ces piliers sont à repérer et à correctement identifier.

 

Le design de la Plateforme de Flexibilité

L’Architecture doit combiner et assembler les piliers pour constituer une « plateforme de Flexibilité », ou un réseau de telles plateformes. Selon les contextes d’entreprise on pourra baptiser ce ou ces plateformes « plateforme numérique », « plateforme événementielle », …

Pour définir la plateforme on dispose d’entrée de jeu d’une vision macroscopique des piliers 1 et 2 :

  • les principaux référentiels, qui correspondent aux principaux objets du périmètre, qui sont d’ailleurs des stéréotypes : clients, produits, structures, …
  • les cycles de vie de ces objets, à tracer et synchroniser dans des Puits

Il existe bien sûr plusieurs variantes pour périmétrer ces piliers et leurs contenus et interactions, ainsi que l’organisation qui les gère ou y accède. La définition de la plateforme a de forts impacts sur les métiers, et sur la stratégie d’Entreprise (position concurrentielle, leviers de la transformation numérique, gains de productivité).

 

 

L’Architecture Flexible se construit en respectant quelques règles simples.

Règle 0 : L’Architecture doit être vue avec le périmètre le plus large, pour gagner en stabilité, sans s’encombrer des questions subsidiaires

La ©Trame Business permet d’avoir une vision « écosystème » et d’anticiper sur des changements de territoires « stratégiques » où l’Architecture peut être un atout déterminant.

A contrario, l’Architecture permet de gérer la subsidiarité, en en réglant les espaces, la gouvernance, les droits.

Règle 1 : L’Architecture se limite à quelques composants, épine dorsale du SI, et à des règles d’intégration minimalistes mais complètes

L’Architecture est constituée :

  • De l’assemblage de ces composants au sein d’une plateforme,
  • Des règles d’interaction avec les autres composants du patrimoine, selon des standards fonctionnels et techniques minimalistes.

Les modèles d’intégration fonctionnelle doivent être réduits, afin de ne pas complexifier cette intégration. Par contre l’intégration fonctionnelle doit gérer la datation, afin de permettre la synchronisation.

Les standards d’intégration techniques doivent être très ouverts, afin d’imposer le moins de contraintes techniques.

Règle 2 : Distinction entre événements d’identification et événements de cycle de vie

Au niveau de l’Architecture, il faut d’une part assurer l’identification des « objets » concernés par le SI, et d’autre part être en mesure de synchroniser les différents systèmes à l’occasion des événements de vie de ces objets.

Par exemple les événements d’identification d’une entreprise sont ceux qui amènent à créer, modifier, supprimer le N° Siren, si le choix est d’utiliser cette numérotation comme système de repérage des entreprises. Mais il y a bien d’autres événements qui jalonnent la vie d’une entreprise, au sens économique, juridique, social, …

Cette règle s’applique à tous les types d’objets : entreprises, personnes, produits, services, …

La distinction de ces événements permet une gestion différentiée, d’une part dans des figures de style de type « Référentiel » (alias « Master Data ») pour l’identification, et d’autre part dans des ©Puits d’événements pour les cycles de vie.

Règle 3 : L’Architecture doit gérer la dimension historique et la tri-datation

Un SI qui ne dispose pas de datation correcte n’a pas de flexibilité, car il ne peut gérer la coexistence entre ancien et nouveau patrimoine SI. Il bloque aussi les évolutions du monde objet, ne pouvant le représenter en anticipation, en prévision, en simulation. Il bloque la mise en qualité car il ne peut comparer des situations de qualité distinctes.

La base de ces flexibilités est la tri-datation, concept défini par René Mandel pour les ©Puits d’événements.

L’historisation et la tri-datation sont des clés de l’Architecture Flexible, et sont à respecter dans tout le SI, en particulier pour les échanges entre composants. Par exemple la tri-datation est propagée par les APIs.

Règle 4 : les composants d’Architecture que sont les Puits et Référentiels ne doivent pas être chargés des fonctions annexes, déportables ailleurs

Dans la cible d’Architecture, ces composants restent dédiés à leur fonction essentielle, les autres fonctions étant systématiquement déportées sur d’autres composants, invoqués par appel de service.

L’objectif est d’éviter l’embolie du système par surpoids des composants d’Architecture. Cette règle apporte aussi beaucoup de flexibilité.

Règle 5 : les composants d’Architecture doivent pouvoir être accédés en différentes latences, avec obligatoirement un accès opérationnel selon la meilleure latence

Il s’agit en effet de ne pas figer le système sur des modes d’échange obsolètes, mais de permettre cependant un fonctionnement non intrusif avec le patrimoine existant. C’est le principe dit de « Janus ».

Règle 6 : L’extension « globale » de l’Architecture est obtenue par des extensions « locales » progressives et autonomes

Il s’agit d’éviter un plan global qui ne serait pas réaliste, mais de permettre des initiatives locales créant des « taches d’huile » appliquant la nouvelle architecture.

Règle 7 : Une extension « locale » de l’Architecture et du patrimoine SI qui y adhère doit être opportuniste, raisonnée, sans Big Bang

Il s’agit d’éviter l’illusion d’un plan déterminant sur longue période l’extension « locale » du système. L’expérience prouve que ces plans sont illusoires, voire dangereux car pouvant créer des erreurs de communication, des abandons, des pertes, …

L’extension ne doit pas se faire par Big-bang, mais être progressive, en utilisant la flexibilité de l’Architecture.

L’extension doit cependant être raisonnée, utilisant au mieux les possibilités technologiques, avec une anticipation à horizon maîtrisable.

Les projets de Puits et de Référentiels seront à gérer en cohérence, car Puits et Référentiels sont complémentaires et se confortent. La gestion de la datation doit en particulier être conforme dans les 2 figures de style.

Règle 8 : Les composants technologiques utiles à l’Architecture Flexible doivent être disponibles en avance de phase

Il s’agit en effet afin de créer une « offre d’Architecture » crédible et visible de l’ensemble des acteurs du SI.

Règle 9°: L’ensemble des plateformes doit être reconfigurable

La gestion des configurations de plateforme doit être basée sur un référentiel des composants (MDM, Puits) et des flux.

L’objectif des reconfigurations peut être un alignement par rapport aux évolutions règlementaires ou de la gouvernance.

 

 

Composants fonctionnels et composants technologiques de la plateforme

Une plateforme comprend des composants fonctionnels, typiquement des Référentiels et Puits. On y adjoint des composants technologiques de type :

  • Moteur de recherche
  • Gestionnaire d’API
  • Intégrateur de données, connecteurs
  • Hub de données, gestionnaires de flux
  • Gestionnaires d’événements
  • Sauvegarde, restauration, sécurité, reconfiguration

Cette liste est non limitative, de nouveaux composants technologiques pouvant apparaître au cours du temps.

Une plateforme peut être virtualisée, par exemple sous la forme de réseau de plateformes. Plusieurs plateformes peuvent partager tout ou partie des composants technologiques.

Introduction progressive de la Flexibilité

Intégration de données

La technologie est une aide précieuse pour ce sujet : des produits d’intégration de données permettent, à coût réduit et délais courts, de mettre le patrimoine en mouvement. Et aussi, de satisfaire aux exigences de rupture pour le Business (partenariats, écosystème numérique, …) et le SI : inter fonctionner avec le Cloud, les SaaS, les APIs, … tout en préservant l’existant (process réglementaires, flux « batch », patrimoine applicatif, cultures métier,…).

Stratégie de migration par étapes de leurre

La stratégie de migration par étapes de leurre est une méthode de migration des données qui permet une bascule progressive d’un patrimoine intégrant un ancien composant vers le même patrimoine intégrant un nouveau composant.

Un ©Puits d’événements, dans la mesure où il permet de gérer des flux d’alimentation ou d’invocation d’un système, peut être utilisé pour mettre en œuvre une telle stratégie.

Cela consiste :

  • d’une part en la « nécrose» progressive de l’ancien composant, en réduisant les cas où il intervient.
  • d’autre part, en parallèle, en la mise en « couveuse» du nouveau composant, en l’alimentant progressivement de cas où il intervient.

Ce processus est aussi facilité par un Puits, car celui-ci dispose de l’historique des flux, et peut donc les reconstituer à l’identique. Un retour arrière est toujours possible.

Autres effets induits par l’Architecture Flexible

  • La réduction de la taille des projets, car les projets sont débarrassés de la gestion des référentiels et des événements. Le risque projet, dont on sait qu’il devient majeur avec la taille, est réduit.
  • La réduction du périmètre confié aux progiciels « métier », qui ont tous tendance à embarquer des fonctions génériques (search, analytics, BPM, …) disponibles par ailleurs à moindre coût, et en mutualisation transversale.
  • L’ouverture à des solutions émergentes dynamiques (Open Source, intégration de données, Big Data), qui améliorent considérablement le rapport service rendu/coût.

Rappel des principes d’Architecture Flexible[2]

Étendue écosystème

L’architecture dépasse les périmètres de l’Entreprise

Elle concerne l’ensemble des partenaires de l’écosystème (cf ©Trame Business 2006)

Elle « résiste » aux recompositions des chaînes de valeur désintermédiation, ouverture de partenariats, synergie producteur-distributeur, …

Approche « multi-domaine »

Les composants d’architecture sont nativement « multi-domaine »

Ils sont transverses aux silos métiers traditionnels

Ils ne gênent pas, voire facilitent, les recompositions internes (changement d’organisation, externalisations, fusions de services)

Non intrusion pour le patrimoine existant

L’architecture s’insère sans coûts induits aux endroits « stratégiques » du patrimoine existant

Elle est agnostique par rapport aux choix technologiques passés (monde batch, monde message, …)

Elle facilite la migration (accélération des flux, dé commissionnement, …)

Anticipe l’avenir

Agnostique par rapport aux futures architectures (Interfonctionnements ESB, API, NoSQL, In Memory, …)

Fournit des services, cache les données

Conserve et trace tout (log systématique de « faits » immuables)

Facilite la migration

L’architecture est pivot de migration

Un réglage natif des « curseurs » de subsidiarité

Partagé par tous les composants de l’architecture

Aligné sur le cadre défini par la « ©Trame Business »

Autorisant une évolution des règles en souplesse (confidentialité, responsabilité, …)

Un réglage restreint aux informations objectives à partager

Identification et état civil des objets

Traçage des cycles de vie (identification des événements, historisation, localisation…)

Laissant la complexité dans les silos et dans le subsidiaire

Une défense contre la complexité

Gouvernance de l’essentiel : les biens communs

Limite les combinaisons et exigences inter-domaines (intégrité, synchronisation…)

[1] Pour plus d’informations sur l’Architecture flexible suivre le lien : http://trame-business.fr/mon-installation/index.php/architecture-flexible/

[2] Principes d’architecture flexible énoncés en 2016 : « Une architecture à géométrie variable »