fatalité entropie-v1

L’ACCROISSEMENT DE L’ENTROPIE DES SYSTÈMES D’INFORMATION EST-ELLE UNE

FATALITÉ ?

René MANDEL

www.value-architecture.com

Version 113/04/2015

SOMMAIRE

Table des matières1. PRÉAMBULE.......................................................................................................................1

1.1 LA MAÎTRISE DE LA COMPLEXITÉ DES SI.............................................................11.2 UN DÉFI SCIENTIFIQUE ET TECHNIQUE................................................................1

2. L’INTÉGRATION DES SYSTÈMES D’INFORMATION..............................................3

2.1 L’ALGEBRE DES COMPOSANTS DU SI....................................................................32.2 FATALITÉ DE LA COMPLEXITÉ................................................................................4

2.2.1 Dérive vers la complexité.........................................................................................42.2.2 Existence de données « de référence ».....................................................................42.2.3 L’intégration imparfaite des composants de référence.............................................5

2.3 MECANIQUE DE LA COMPLEXITÉ...........................................................................72.3.1 Divergence selon le taux d’imperfection..................................................................72.3.2 Les vraies raisons des particularités.........................................................................7

3. AGIR SUR LE CŒUR DE L’INTÉGRATION.................................................................9

3.1 RENDRE LE MARCHÉ DES COMPOSANTS PLUS PARFAIT.................................93.1.1 Quel ROI du SI avec une algébre parfaite................................................................93.1.2 Agir sur le marché interne......................................................................................10

3.2 DOTER LES COMPOSANTS DE RÉFÉRENCE DE CAPACITÉS D’INTÉGRATION GÉNÉRIQUES (PRINCIPE DE « JANUS »).....................................10

3.2.1 Les fonctions de « traduction » et d’intégration de données génériques................113.2.2 Modélisation générique des « puits de données »..................................................133.2.3 Cas des « référentiels de données »........................................................................143.2.4 Gérer la subsidiarité................................................................................................15

3.3 PROFESSIONALISER LES ACTEURS DU SI...........................................................15

4. VERS UNE ALTERNATIVE À LA « GOUVERNANCE »...........................................17

4.1 RÉSISTANCES À LA GOUVERNANCE PYRAMIDALE ET AUX MÉTHODES LOURDES...........................................................................................................................174.2 LES DÉCISIONS DES PROJETS NATURELLEMENT DANS LE BON SENS.......174.3 SYNCHRONISER LES DONNÉES SUR LA SIMPLICITÉ.......................................184.4 CHANGER DE PARADIGME.....................................................................................18

fatalit-entropie-v1-150331122602-conversion-gate01-reupload.doc 13/04/2015

L’accroissement de l’entropie des systèmes d’information est-elle une fatalité ? PAGE N° 1

1. PRÉAMBULE

1.1 LA MAÎTRISE DE LA COMPLEXITÉ DES SI

Les systèmes d’information résultent d’une réalité de plus en plus complexe : multiplication des capteurs, extension des domaines applicatifs, empilement des technologies, sédimentation applicative, …

Intuitivement on peut qualifier cette dérive, au cours du temps, comme un accroissement d’une « entropie » des systèmes (distincte des autres entropies connues car un facteur humain entre en ligne de compte). L’Architecture d’Entreprise a pour ambition d’imposer un modèle pour donner de l’ordre. C’est une approche rationnelle et autoritaire qui suppose que le modèle est respecté et applicable dans la durée. En pratique, une planification rationnelle, certes souhaitable, est en grande part irréaliste et dispendieuse. L’Urbanisme des Systèmes d’Information est une approche plus modeste qui compte sur la mise en ordre progressive, au fil des projets, à moindre coût. Mais il est clair qu’en l’absence d’effort collectif et central, le désordre s’accroit « naturellement ». Qu’elle est donc la quantité d’énergie nécessaire pour revenir à l’ordre, en l’imposant ou en facilitant l’agilité ? D’ailleurs comment définir l’entropie des SI ?

Mais l’accroissement de l’entropie est-elle une fatalité ?

On peut penser que les mêmes causes, qui provoquent l’imbrication fatale, et l’embolie, dans un fonctionnement en cercle vicieux, pourraient agir au contraire par cercles vertueux et réduire progressivement l’entropie. Cette simplification serait naturelle, non planifiée et dirigée par une gouvernance. Une des pistes, pour cette transformation naturelle du patrimoine, est d’introduire quelques composants clés, catalyseurs de vertu et tueurs d’entropie : le système sociotechnique se transformerait alors de lui-même, de façon déconcentrée. L’effort de mise en ordre serait minimal et relayé naturellement par toutes les parties prenantes des SI. Cependant cette piste, ouverte comme exposé ci-après par des avancées technologiques, est ignorée par l’idéologie rationnelle dominante.L’accroissement de l’entropie des SI n’est pas une fatalité, elle résulte d’une part de la dérive naturelle des SI, et d’autre part de l’utopie d’une maîtrise irréaliste ignorant la dynamique des micros décisions de construction des SI, et des opportunités technologiques. Il faut changer le paradigme de l’EA. Et étudier l’alternative aux approches purement méthodologiques.

1.2 UN DÉFI SCIENTIFIQUE ET TECHNIQUE

L’activité de développement de logiciels est devenue, au cours du temps, majeure dans l’économie :

René MANDEL Mars 2015


• Les composants logiciels sont présents partout, dans tous types de supports matériels, et de façon virtuelle dans le « nuage »,

• Toutes les organisations disposent d’équipes internes, ou sous-traitent pour assembler, intégrer des composants et constituer des SI de plus en plus déterminants pour leur activité, pour l’analyse, la stratégie, l’engagement des clients,…

• Le poids économique de ces activités est une préoccupation macro-économique primordiale : nombre d’emplois, redistribution mondiale des compétences, flux financiers induits,…

En somme l’ingénierie du logiciel devrait s’appuyer sur une science du logiciel à la mesure de ces enjeux, comme par exemple les enjeux écologiques justifient le programme de recherche ITER sur la fusion nucléaire.

Force est de constater que cette science du logiciel n’a pas été jusqu’à présent à la mesure des enjeux, et qu’en pratique les SI des grandes organisations se heurtent à des défis de complexité. Les SI s’avèrent en effet rigides, sur-complexes, coûteux, fragiles, cloisonnés « en silos », et, finalement difficiles à maîtrisés.

Les efforts de gouvernance, et les méthodologies d’Enterprise Architecture, visent à pallier à ces difficultés pratiques et organisationnelles. Cette approche autoritaire et rationnelle a des limites, en particulier par sa lourdeur et son implantation organisationnelle pyramidale, même si elle cherche à se réformer en intégrant les approches « agiles ».

En effet l’extension des SI est dans une phase explosive, qui ne permet plus de s’en remettre exclusivement aux anciennes recettes basées sur un passé technologique obsolète et des outils artisanaux.

Le défi est à la fois scientifique et technique :

• Scientifique car on ne dispose pas de recul suffisant pour expliquer, modéliser les comportements des acteurs des projets qui aboutissent aux imbrications, duplications, dysfonctionnement constatés.

• Technique, car le monde technologique est en évolution rapide, et des bases technologiques nouvelles permettent d’espérer un changement de paradigme pour que la maîtrise de la complexité soit consubstantielle au développement du logiciel. Ce fait majeur est une opportunité méconnue qui doit bousculer les approches méthodologiques. Encore faut-il que le sujet soit examiné avec une rigueur à la mesure de ces enjeux.



2. L’INTÉGRATION DES SYSTÈMES D’INFORMATION

Dans l’activité de production de logiciels, depuis plusieurs décennies, les limitations sont connues. En particulier les effets pervers de l’intégration mal maîtrisée ont amené à élaborer des méthodes d’Architecture d’Entreprise (Zachman, Togaf, …) et de gouvernance. Une des questions clé est celle de l’intégration des composants pour constituer, par assemblage, les SI.

2.1 L’ALGEBRE DES COMPOSANTS DU SI

Les SI sont constitués, quels qu’ils soient, à partir de divers composants (logiciels, techniques).

On peut donc avoir une vision globale d’un SI, comme un tout qui évolue :

• Par l’assemblage et le désassemblage de composants• Par les cycles de vie des composants eux-mêmes.

Ce cycle d’un SI, qui n’est pas celui du « run time » mais celui du logiciel et des composants techniques, est complexe et résultante de toutes ces évolutions.

Chaque composant a son propre cycle de vie, avec une phase de création, des épisodes de maintenance, de refonte, de nécrose (abandon progressif), ….

Une forte particularité des SI est l’interdépendance entre les composants. En effet de multiples interactions sont nécessaires, voulues, ou mêmes involontaires.

On peut dire qu’entre 2 composants il y a une « fonction » d’interaction qui permet de considérer l’ensemble qu’ils constituent comme un nouveau composant. Ce nouveau composant peut lui-même interagir avec d’autres. Cette fonction est « transitive » et par assemblages successifs se constituent des ensembles de plus grande taille (associativité).

Ainsi, du point de vue ensembliste, les composants obéissent à des lois particulières.

On pourrait faire l’analogique avec la physique moléculaire, et au comportement des atomes entre eux (voir http://www.value-architecture.com/2015/03/les-limites-de-la-complexite-des-si.html) …

Les interactions voulues se dénomment « l’intégration ».

Les composants, en s’intégrant, respectent une « algèbre » qui leur est propre (on peut la représenter par une formulation algébrique).


http://www.value-architecture.com/2015/03/les-limites-de-la-complexite-des-si.html

http://www.value-architecture.com/2015/03/les-limites-de-la-complexite-des-si.html


On pourrait faire l’hypothèse d’une algèbre des composants « parfaite » respectant une loi de composition associative ((x * y) * z = x * (y * z) et commutative : x*y*z = x*z*y. Mais en pratique, les particularités d’intégration comme la dispersion des projets entre équipes et dans le temps, laissent penser que cette hypothèse n’est pas réaliste dans l’état de l’art actuel.

2.2 FATALITÉ DE LA COMPLEXITÉ

2.2.1 Dérive vers la complexité

Au cours du temps, de nouvelles interactions apparaissent, par « transitivité » de l’intégration : de proche en proche des dépendances involontaires et non objectivées se créent ainsi. En effet, l’intégration est maîtrisée « par proximité » (des maîtres d’ouvrage, des maîtres d’œuvre, technique, temporelle, …) mais la propagation de la connaissance est toujours limitée, et repose sur une base humaine. Ainsi, au-delà des cercles de proximité, des dépendances indirectes et involontaires sont créées.

Les imperfections s’accroissent aussi au cours du temps :• la connaissance se dilue progressivement• de nouveaux besoins apparaissent auxquels il faut répondre par de nouvelles

intégrations, voire ne pas répondre en admettant des lacunes ou incohérences.

Ce phénomène est classique et bien connu sous ses différentes manifestations : effet spaghetti, adossement des systèmes avec risque systémique (effet domino), rigidité du patrimoine rendant les évolutions couteuses (nécessité de refontes lourdes) voire impossibles, empilement technologique, …

Par exemple l’effet spaghetti est dû à la combinaison des particularismes des émetteurs et des récepteurs : s’il y a n émissions d’un même ensemble d’informations sous n variantes, et p réceptions de cet ensemble sous p autres variantes, se construisent au fil des projets n X p types d’échanges, alors que le passage par un point focal, du type « puits de données » n’en nécessiterait que n + p. De façon plus générale n + p intégrations sont complexifiées en n X p.

De ce fait, les SI sont « sur-complexes » s’étant développés en « récif de corail » par ajouts opportunistes et intégrations privilégiant la proximité et le court terme. Ils sont sur-complexe car un assemblage plus simple pourrait produire un résultat identique, voire un meilleur résultat, si l’on prend en compte l’amélioration en flexibilité.

2.2.2 Existence de données « de référence »

Dans tous les SI on constate qu’il existe le besoin de partager des « données de référence ». Cet état de fait général, qui ne souffre aucune exception, est connu lui aussi de longue date. Le rôle clé de ces données pour maîtriser le désordre des systèmes, bien au-delà de la stricte sphère des SI, est aussi admis par toutes les organisations.

La réponse organisationnelle est de mettre en place une gouvernance de ces données, gouvernance minimaliste, ou au contraire maximaliste, mais qui est souvent source de tensions internes. En effet un équilibre des pouvoirs est à trouver pour préserver



l’indispensable cohérence « centrale » et la non moins indispensable autonomie « périphérique ».

Du fait de cette recherche de l’équilibre, on constate des excès, soit dans un sens soit dans un autre, qui génèrent des dysfonctionnements : incohérences, redondances, rigidité, confusions, doubles saisies, contournements. Et dans de nombreux cas les données de référence, par exemple sur le client (notion de « golden data ») qui ne sont pas en qualité.

2.2.3 L’intégration imparfaite des composants de référence

Toujours dans la vision ensembliste, on doit s’intéresser à une classe particulière de composants qui est celle de ces composants « de référence » (de type « master data » ou « puits »).

Un composant de référence joue un rôle particulier dans un périmètre (la totalité du SI ou un sous-ensemble) : il est susceptible d’être « intégré » avec tous les autres composants de ce sous-ensemble, et cette intégration est parfaitement transitive : un composant intégrant une telle référence hérite de cette faculté et peut servir de référence à son tour, et à l’identique.

En quelque sorte la loi de composition serait associative : (x * y) * r = x * (y * r) et l’héritage des propriétés de la référence pourrait se noter Hr(x*y*r)=Hr(y*r)=Hr(r).

En réalité, on constate toujours que l’intégration de ces composants est « imparfaite » et donne lieu à des aberrations. Comment expliquer les imperfections de cette « algèbre » ?

2.2.3.1 Composants usurpateurs

Des composants, qui ne sont pas classés parmi les composants de référence, peuvent, pour des raisons variées (absence de connaissance, volonté de contrôle, volonté de modifier le modèle, …) être substitués à un composant de référence au sein de son sous-ensemble.

L’usurpation peut être :

• Conceptuelle : modification du modèle, introduction d’une variante sans réel apport, refus de la généricité, imbrication d’un complément,

• Syntaxique : introduction d’un dialecte local, rendant les échanges locaux particuliers et nécessitant une traduction pour être compris dans le périmètre d’élection du composant de référence,

• Sur les modes de latence : introduction d’une cinématique d’échange particulière (lots, rythme de mise à jour, messages, invocation de services…).

2.2.3.2 Intégration opportuniste

Sans qu’il y ait création volontaire de composants usurpateurs, les liens d’intégration peuvent se développer dans le désordre, par proximité, sans respecter la qualité de l’intégration proposée par les composants de référence.



Par exemple, si un composant de référence n’offre pas le mode d’échange attendu, la temporalité requise, … un composant usurpateur pourra paraître illusoirement légitime, et prendre une position durable, même si la lacune la justifiant disparait.

Ainsi un maillage aléatoire des composants se crée, et rend le système de plus en plus complexe.

Perver

Vraie source Usurpeur

Sain

Vraie source

Développement d’un maillage sur-complexe

Conduisant progressivement à :

2.2.3.3 Lacunes d’intégration



Il est aussi fréquent, devant les difficultés à intégrer les composants, qu’on fasse l’impasse, en se reportant sur des solutions « manuelles » : saisies en double, consignes, reports de données à vue, …

Ces solutions, satisfaisantes si les volumes sont faibles, sont peu sécurisantes à moyen terme, et doivent être encadrées par des contrôles qui posent aussi la question des données de référence.

2.3 MECANIQUE DE LA COMPLEXITÉ

2.3.1 Divergence selon le taux d’imperfection

Au cours du temps les composants évoluent, la population change, et les liens d’intégration se font et défont.

Il y a donc une certaine intensité de projets, et une démographie de tous ces éléments.

Il y a d’abord une dérive du périmètre, qui va en général dans le sens d’une extension du système, et de sa population. Il devient ainsi plus complexe. Mais il ne faut pas qu’il devienne au cours du temps « sur-complexe » par augmentation des dysfonctionnements indiqués ci-dessus.

En pratique, avec un taux d’imperfection élevé, la complexité s’accroît de façon combinatoire, rendant des refontes et réingénieries coûteuses nécessaires, et une gouvernance lourde indispensable.

En somme la complexité obéit à une loi de série qui est rapidement divergente : des imperfections naturelles s’introduisent au cours du temps, et ont un effet pervers cumulatif.

Par contre si de nouvelles imperfections ne se produisent pas, les anciennes imperfections seront naturellement résorbées au fil des évolutions (une intégration imparfaite étant remplacée par une intégration parfaite). La série sera convergente et la complexité se réduira naturellement. Sur la base de quelques hypothèses paramétrées (taux de couplage entre générations, taux d’imperfections dans ces couplages, effectif des générations successives, …) on pourrait créer un modèle numérique pour simuler cette série. L’entropie serait mesurée au sein du graphe des dépendances entre composants de base (les « atomes ») : nombre moyen d’arcs par composant.

2.3.2 Les vraies raisons des particularités

De fait, dans l’interposition des « composants usurpateurs », il existe de vraies raisons :

• Absence de modélisation de la subsidiaritéo exemple du référentiel des structures, des identités, …o exemple de la subsidiarité sémantique

De fréquentes divergences sont en réalité dues à une subsidiarité cachée, qui n’est pas objectivée. Une façon pratique de lutter contre cela est d’objectiver la subsidiarité par une modélisation adaptée, et de paramétrer ce modèle pour le rendre flexible et évolutif.



• Pas de gestion des multiples latences :o services de flux de fichier à différentes échéances,o lots de population variables : mis à jour, stock,…

• Séparation entre 2 mondes (Batch, temps réel) et multiplication des protocoles et formats

• Pas de gestion des 3 dates et de l’historique (voir à ce sujet l’approche « puits de données »).

Ces sujets, mal étudiés au plan conceptuel, divisent les éditeurs, et balkanisent le SI. Pourtant il s’agit des mêmes facettes des objets du SI, traitées comme particulières, sans objectiver le « modèle » commun.



3. AGIR SUR LE CŒUR DE L’INTÉGRATION

Comme dans d’autres sciences, on peut d’une part étudier le système dans sa globalité, ou dans son fonctionnement détaillé. Par exemple la physique a d’abord dégagé des lois générales, bien que l’intuition de l’existence des atomes soit très ancienne. La physique quantique est venue ensuite formuler les modèles de comportement et d’interaction à l’échelle des atomes.

Mais, en physique, l’homme n’intervient pas dans ces interactions atomiques. Dans le cycle de vie des SI, par contre, les comportements humains, aussi bien ceux des individus, et surtout ceux dus aux conditionnements sociaux, sont déterminants.D’ailleurs les outils disponibles dans les activités de conception des SI, et lors de la maintenance, sont frustres, à base de cartographies élaborées de façon artisanale.

3.1 RENDRE LE MARCHÉ DES COMPOSANTS PLUS PARFAIT

3.1.1 Quel ROI du SI avec une algébre parfaite

La question du ROI d’un SI est primordiale : un SI coûte et apporte de la valeur tout le long de sa durée de vie, et on ne peut juger de son utilité que sur cette durée. Nous avons proposé un modèle mathématique pour formuler ce ROI (voir : http://fr.slideshare.net/RenMANDEL/roi-infrastructure-v8).

L’intégration de 2 composants, qui crée logiquement un nouveau composant, altère ce ROI. D’une part elle a aussi un coût, et une valeur, et a un impact sur les coûts et valeurs des composants intégrés. On peut ainsi considérer que cette intégration a aussi un ROI, et que la fonction d’intégration, active dans l’ensemble des composants, se « projette » sur l’espace des ROI. Et si l’on est rationnel, l’intégration ne se réalise que si elle améliore le ROI.

Ce modèle « atomique » est simple. On peut le propager au niveau macro en faisant des hypothèses, et en particulier que l’algèbre des composants est « parfaite » :

• Un composant qui serait utile à d’autres composants serait « intégré » quelle que soit la « distance » entre eux.

• Les effets pervers mentionnés ci-dessus seraient connus et maîtrisés par les acteurs concernés, et limités pour ne pas dégrader le ROI en toute hypothèse (on pourrait formuler cela dans une approche probabiliste).

Bien sûr ces calculs sont difficiles et arbitraires, car, alors qu’on sait répartir les coûts, il en va autrement pour la valeur qui est fluctuante et dépendante du contexte externe. Les composants de référence trouvent leur justification dans leur intégration aux autres, comme s’il y avait une transaction interne, avec un prix de cession.Cela pose donc la question du « marché » interne des composants.


http://fr.slideshare.net/RenMANDEL/roi-infrastructure-v8


3.1.2 Agir sur le marché interne

Ainsi, au-delà de cette perfection de l’intégration souhaitable, la question est celle de la « perfection » du marché interne d’échange de composants : un composant de référence sera « intégré » (une sorte de transaction économique interne) s’il permet une évolution optimale du ROI (voir la note citée ci-dessus sur le ROI). Ceci rappelle le besoin de rendre l’information symétrique, dans un marché « parfait », pour que les « acheteurs » ait une connaissance des avantages, des garanties, des risques. Une approche contractuelle (cf. la théorie des contrats en économie industrielle) permettrait de répondre à cet objectif.

Cette transparence du marché interne des composants, appliquée aux composants de référence, permettrait d’éviter « l’usurpation », qui place dans le patrimoine des composants usurpateurs, avec des effets pervers à court terme et surtout à moyen terme.

Cela implique aussi que les composants de référence soient disponibles sur le marché « en avance de phase » par rapport aux cycles de développement des autres composants.

3.2 DOTER LES COMPOSANTS DE RÉFÉRENCE DE CAPACITÉS D’INTÉGRATION GÉNÉRIQUES (PRINCIPE DE « JANUS »)

Une autre clé pour optimiser les intégrations autour des composants de référence est de doter ceux-ci de capacités d’intégration « génériques » leur permettant d’être assemblés dans tous les contextes, de façon « parfaite » et sans surcoût.

A cet effet les qualités sont :

• L’anticipation d’évolutions futures, pour garantir aux projets un « service » adapté aux nouvelles technologies et aux exigences futures : préfigurer, pour les projets, des modalités nouvelles, plus alignées sur les possibilités actuelles (ESB, latence faible, Cloud, ...) et les attentes imposées au SI (tout connecté, mobilité, traçabilité, transparence, toutes sources, agilité,...).

• L’offre d’interfaces variées pour une insertion « non-intrusive » au sein du patrimoine existant : admettre toutes les modalités d'échange et d'intégration, pour une cohabitation avec le patrimoine existant sans surcoûts, et dans des pas de temps courts.

On peut qualifier cette capacité de « Janus », à l’instar du dieu Romain au double visage, l’un tourné vers le passé, l’autre vers l’avenir.



Cette capacité est obtenue par le développement de services de données utilisant une bibliothèque d’intégration de données (plusieurs solutions existent sur le marché), et le la conception d’un modèle générique adapté au type de données de référence.

Une architecture d’interopérabilité peut par exemple être constituée pour s’appliquer aux mondes de la répartition de flux (batch, messages) et à celui de l’orchestration de services (services web, Soa, …) et les faire converger.

Puits de données

Web

GRC LEGACY …

Web

ERP

Référentiels de données

Dispositif d’interopérabilité

Orchestration

des échanges

Répartiteur

De flux

Puits de

données

3.2.1 Les fonctions de « traduction » et d’intégration de données génériques

La bibliothèque d’intégration de données se décompose en plusieurs fonctions. Elle doit aussi être enrichie par une couche de services et de pilotage. Ces fonctions sont décrites ci-dessous (on peut aussi se référer aux publications du Gartner sur le sujet).

3.2.1.1 Le « transport »

C’est le niveau de la tuyauterie qui permet de transporter les messages ou les lots de données.Il y a d’une part les transferts par fichier en lots de données, d’autre part ceux de messages, par exemple au travers d’un ESB.


http://4.bp.blogspot.com/-gBtfHiso00U/VQGhm4hCeAI/AAAAAAAALOM/-B5sOUFDHBw/s1600/janus.jpg


3.2.1.2 La « connectivité »

Ces composants permettent de se connecter à une grande variété de bases de données de divers éditeurs ou du monde open source. D’autres permettent d’interagir selon divers formats: champs fixes, balisés (XML, JSON, EDI), spécifiques à des ERP, …

3.2.1.3 Les fonctions de « conversion »

Grace aux composants de connectivité, il est possible de convertir les divers formats les uns vers les autres. En outre, par quelques clics certaines bibliothèques permettent un travail sur les métadonnées: le mapping de données consiste à recomposer de nouveaux échanges ou flux à partir de données choisies dans les flux ou échanges existants.Ces composants peuvent être activés dans un contexte de type « batch », par exemple dans un ETL classique, comme dans un contexte « message » ou temps réel.

3.2.1.4 Fonction de « stockage »

Cette « couche » est d’utilité variable selon les usages. La fonction de « stockage » peut utiliser plusieurs techniques: SGBD classique, ou nouvelles solutions de la famille « NoSql ».

3.2.1.5 Les fonctions de « synchronisation, qualité de données »

La consolidation de différents flux et échanges fait apparaître divers problèmes de qualité des données: doublons, divergences, incohérence d’identification par rapport aux référentiels, incohérences temporelles, non qualité des identifiants, adresses, … les fonctions doivent encapsuler le diagnostic et les fonctions de corrections. Ces fonctions sont clés pour la gouvernance et la qualité des données d’un référentiel. Elles sont en général apportées par des solutions de type Master Data Management (MDM).

3.2.1.6 Fonction de « services de données »

Les services de données ont pour objectif d’exposer et de diffuser les données. Des approches fonctionnelles doivent permettre de les exposer selon des regroupements, des lots, des latences attendues par les structures internes ou externes, et par les applications qui souhaitent les utiliser (en respectant les consignes indiquées par les dépositaires des données). Cette fonction est à développer et adapter au domaine.

3.2.1.7 Le « pilotage »

Ce niveau pilote et supervise la répartition des flux et l’orchestration des services.



3.2.2 Modélisation générique des « puits de données »

Les puits ont d’abord pour vocation des substituer à N + P interactions aux N X P interactions qui se créent naturellement, selon le schéma suivant :

Devient :


N X P fluxN X P conversions de format

Référentiel

Source GRC

Source Infinite

Source externe

Vision 360 Décisionnel Erp

PuitsPuits Conversions de format


Pour une présentation du principe voir : http://www.value-architecture.com/2014/03/a-la-decouverte-des-puits-de-donnees.html

La clé de la conception est dans l’identification du « grain » générique, qui permet de tracer toutes les évolutions des objets dont les données de référence sont placées dans le puits. Le travail de définition des événements et des différentes datations est primordial, pour garantir la stabilité du modèle.(voir aussi : http://fr.slideshare.net/RenMANDEL/principe-du-puits ).

Par principe les Puits ne doivent pas être intrusifs, ni nécessiter de refonte des processus. En effet il est hors de question de déposséder les applications de leurs processus, en général très imbriqués. Par contre les Puits assurent la traçabilité, en particulier pour le suivi de la mise en qualité des données (cf. le modèle « tridaté »).

Le modèle « tridaté » d’un puits

Il existe un moyen simple pour repérer les puits potentiels : objectiver les cycles présents dans l’écosystème (voir : http://www.value-architecture.com/2013/02/les-azimuts-des-chaines-de-valeur.html), car chaque cycle est à l’origine d’événements, motivant un puits qui lui est dédié. Un puits, clé de la cohérence, est destiné au traçage d’un tel cycle.

3.2.3 Cas des « référentiels de données »

A noter que les référentiels de données, qui structurent le SI, sont plutôt « à cheval » entre plusieurs cycles, et garantissent une cohérence inter-cycles.

L’offre du marché de solutions de MDM permet de disposer de solutions flexibles et opérationnelles.


http://www.value-architecture.com/2013/02/les-azimuts-des-chaines-de-valeur.html

http://www.value-architecture.com/2013/02/les-azimuts-des-chaines-de-valeur.html

http://fr.slideshare.net/RenMANDEL/principe-du-puits

http://www.value-architecture.com/2014/03/a-la-decouverte-des-puits-de-donnees.html

http://www.value-architecture.com/2014/03/a-la-decouverte-des-puits-de-donnees.html


L’utilisation de la bibliothèque d’intégration permettra aussi une insertion non-intrusive, et évolutive, contrairement à certains projets de MDM très centrés sur la gouvernance.Le principe est alors d’organiser un « point focal » pour diffuser, en l’état, les données qui jouent actuellement le rôle de référentiel.

Ceci n’exclut pas une évolution progressivement contrôlée, en particulier pour assurer la qualité des données, et la synchronisation des sources. L’impact sur les processus d’alimentation est alors à examiner, et implique une réingénierie.

Les fonctions de services de données et de pilotage peuvent être communes entre Puits et Référentiels.

3.2.4 Gérer la subsidiarité

On pourrait croire qu’il existe une seule configuration dans l’architecture des références de données. En réalité, les périmètres de ces systèmes peuvent être variables, et les solutions actuelles peuvent anticiper cette flexibilité.

Comme évoqué ci-dessus, on doit à cette occasion modéliser la subsidiarité et propager le modèle entre les différents référentiels et puits. Un modèle unique et intégré a peu de chances de convenir pour permettre un équilibre entre :

• La cohérence sur les objets, les concepts communs,

• L’autonomie indispensable.

La subsidiarité est une question sensible, les « curseurs » ne sont toujours évidents. Il est dès lors utile de prévoir ce paramétrage pour créer une flexibilité et résister à d’éventuels « séismes organisationnels ».

3.3 PROFESSIONALISER LES ACTEURS DU SI

Autour de cet enjeu de simplification du SI, avec l’émergence des opportunités présentées ci-dessus, il faudrait que les acteurs du SI sortent de l’artisanat actuel.

La question, de façon globale, est de reporter une partie de l’énergie placée dans les investissements opportunistes, ou dans les grandes manœuvres méthodologiques, vers :


PuitsVision

360

Point focal Bibliothèque de conversions de format: batch, message, accès API, …


• L’investissement, à moindre coût, dans des composants « Janussiens », en évitant l’écueil des approches MDM classiques trop gourmandes en gouvernance et en « big bang »,

• La « commercialisation » interne, avec une offre de services de données de haut niveau,

• La prise en compte des besoins des projets, au niveau déconcentré.



4. VERS UNE ALTERNATIVE À LA « GOUVERNANCE »

4.1 RÉSISTANCES À LA GOUVERNANCE PYRAMIDALE ET AUX MÉTHODES LOURDES

Nous avons vu que la réponse aux incohérences, aux dérives, et autres confusions apparaissant naturellement a été d’introduire toujours plus de gouvernance des données et, plus particulièrement, des données de référence.

Cette gouvernance répond effectivement à un enjeu de maîtrise majeur.

Cependant elle se heurte à plusieurs résistances :

• C’est une organisation à mettre en place, souvent avec des ressources dédiées,

• Bien souvent il existe des oppositions internes, du fait des différents objectifs et des différents métiers, et un développement pyramidal dans l’organisation,

• Les régimes transitoires pour mettre en place le système (MDM ou autre), dans une approche rationnelle et exclusive, sont longs et semés d’embuches.

• Les bases conceptuelles de ces systèmes sont fragiles, ne réglant pas les problèmes de subsidiarité, de datation, d’historisation, de traçabilité, …

Par ailleurs les méthodologies historiques d’Architecture d’Entreprise sont lourdes (volumétrie documentaire impressionnante, cursus, …) et coûteuses (personnels spécialisés et « certifiés », procédures à respecter) à mettre en œuvre, et trouvent leur justification dans de grands projets, qui cumulent coûts et risques.

4.2 LES DÉCISIONS DES PROJETS NATURELLEMENT DANS LE BON SENS

Nous avons vu que la disponibilité sur le marché de routines d'"intégration de données" permet de créer, autour de ces puits et référentiels, une ceinture de conversion pour des accès dans toutes les temporalités et latences, et selon tous types de protocoles...

Ces composants, organisés en "services de données", font leur affaire de la complexité des "dialectes" locaux et variabilités opportunistes.

L’enjeu est de rendre ces services transparents, facilement accessibles, opérationnels, démontrables par des Proof Of Concept, pour que les acteurs des projets prennent les bonnes décisions sans autre forme de procès.



L’opportunité offerte par l’offre technologique est de pouvoir proposer cette offre pour un coût modique en regard des énormes enjeux mentionnés ici.

La motivation doit venir des acteurs projets, en répondant à leurs souhaits :

• De maîtrise des coûts,

• De disponibilité à court terme,

• D’agilité à moyen terme,

• De garantie de fiabilité.

Les décisions des projets iront alors « naturellement » dans le bon sens, celui de la simplicité. Et ces mêmes forces, qui agissent dans le contexte imparfait que l’on connait en l’absence de composant « Janussien », simplifient progressivement le SI.

4.3 SYNCHRONISER LES DONNÉES SUR LA SIMPLICITÉ

Dans cette recherche de la simplicité, les données de référence sont clé. On constate d’ailleurs qu’elles existent universellement, dans tous les contextes.

Elles sont les piliers de tous les SI, dans l’existant comme pour la cible. Elles retracent les cycles des objets au travers de tous les âges des organisations, et des transformations réalisées :

• Personnes, structures, produits, concepts, services, entités, …

En somme les SI sont devenus complexes par cumul des particularités, ils doivent retrouver modularité et simplicité en se synchronisant sur ces piliers.

Ceci nécessite de « gérer les particularités » dans toutes leurs dimensions : subsidiarités, dates, latences, protocoles, …

Ceci guidera la capitalisation pour les nouvelles avancées de la numérisation extensive :Les ruptures techniques (Cloud, Big data, Hadoop) et culturelles exigent une vision rénovée, détachée des approches en silos, des cartographies de SI et processus. Une vision alignée sur les fondamentaux des chaînes de valeur, et dont les invariants des modèles des données de référence sont les incarnations.

4.4 CHANGER DE PARADIGME

Le paradigme de l’EA se fonde sur une approche rationnelle, sensée contrôler le SI par une vision globale.

Certes l’approche de l’urbanisme des SI « à la française » se démarque de la volonté de contrôle gouverné prônée par l’EA, et ses Framework. Elle se fonde sur la progressivité, et une mise en œuvre au fil des projets par un alignement sur la cible, au moindre coût.



Cependant, la domination internationale va dans le sens de standards « rassurants », dont le sérieux semble à la mesure de l’épaisseur de la documentation, et du nombre d’experts mobilisés. Cette tendance est relayée par les formations, certifications, qui propagent et pérennisent le modèle.

Certes, le besoin de grandes orientations demeure, et il ne faut pas rejeter l’utilité des réflexions sur la cible.

Mais le paradigme est clairement à remettre en cause, à revisiter, pour inverser la charge de la preuve, et explorer des solutions plus adaptées au contexte « agile », « tout technologique », « tout connecté » actuel.


fatalité entropie-v1

Data & Analytics