L'EA orpheline d'idées
Avec la déferlante de la Transformation numérique, la discipline d'Architecture d'Entreprise, l'EA, est secouée sur ses bases. Une remise en cause est plus que nécessaire (voir le futur de l'EA).
Les grands cabinets, grands porteurs de recette miracle, en sont réduits à des préconisations simplistes (bimodal IT) attaquées par force gourous concurrents (voir le débat), sans réelle proposition sur le fond.
Confrontée d'une part à un patrimoine IT immense, et d'autre part à cette déferlante multiforme, l'Entreprise, le DSI, ne sait par quel bout prendre le problème. On prétend voir des clivages partout : entre les IT en bimodal, entre le SQL et le NoSQL, entre le SI interne et l'externe, ... Mais, clairement, ces dichotomies ne fonctionnent pas, car les chaînes de valeur ne se divisent pas ainsi.
Prenons le parti d'une vision "Urbanistique", d'une vision globale de tout le patrimoine des composants, et de leurs cycles de vie... par delà les silos, les technologies, les frontières de l'entreprise. Certes l'Urbanisme des SI est démodé... mais voir l’infiniment grand des composants du SI comme une immense cité, où l'action locale est vaine, est une métaphore qui demeure puissante.
Explorons les actions "urbanistiques" sous forme de principes invariants, de règles au long cours.
Les imperfections de la démographie des composants
Si nous supposons que, par unité de temps, il se crée un
nombre fini de composants, et un autre nombre non moins fini de composants disparaît, nous
avons une population dont le volume total varie. Ce volume est résultat cumulatif de ces naissances et décès de composants.
De fait, sauf à faire un effort de rationalisation, à faire
le ménage, donc à provoquer des décès de composants devenus peu utiles ou obsolètes, les composants, même inutiles, ne disparaissent
pas naturellement au fil du temps : leur durée de vie est artificiellement allongée.
La population globale tend à augmenter plus que nécessaire,
c’est le phénomène de « récif de corail » : de nouveaux
composants sont adossés à d’anciens composants, parfois totalement inutiles.
Par ailleurs, les liaisons entre composants sont, pour
partie, erratiques, redondantes, contingentes. C'est l'effet spaghetti. J’ai appelé tout cela l’imperfection de l’algèbre de composition (voir le document disponible sur
Slideshare).
En résumé, on peut expliquer les dysfonctionnements par les « assemblages imparfaits » entre composants.
Ces imperfections sont de plusieurs ordres. En les objectivant apparaissent facilement quelques règles d'urbanisme susceptibles de corriger les travers bien connus.
Voici les 7 principes d’urbanisme proposés pour corriger dans l’œuf les défauts qui apparaissent, au fil du temps, dans tout système.
7 Principes d'urbanisme
Voici les 7 principes d’urbanisme proposés pour corriger dans l’œuf les défauts qui apparaissent, au fil du temps, dans tout système.
1.
Correction des imperfections de temporalité
Supposons un échange, une interaction, non ambiguë : le
même fait, dans la même vision, le même cycle de mise en qualité, les mêmes
informations échangées. Il est « parfait ». Mais en fait cela peut donner lieu à échange dans des modalités :
- à latence (mode batch),
- en désynchronisation (mode message),
- en synchronisme (mode service ou API).
Donc l’échange est imparfait, variant en apparence, dépendant de circonstances
fortuites. Il faut corriger cette imperfection, par exemple en
utilisant un stockage (cf. le concept de "puits" de données, pour accepter ou restituer les différentes
temporalités.
On évitera ainsi la création de clones du même composant. On évitera de pérenniser les imperfections de latences longues, par propagation au cours d’échanges successifs.
2. Imperfections d’identité
Supposons un échange que l’on croit parfait, mais en fait qu'il
y ait erreur sur l’identité, ou un défaut de synchronisme, …
Par exemple l’objet a changé d’état, alors que ce changement n’est pas connu par les partenaires de l’échange. Une vérification est à faire avant de valider l’échange, pour éviter la propagation virale d’erreurs.
Par exemple l’objet a changé d’état, alors que ce changement n’est pas connu par les partenaires de l’échange. Une vérification est à faire avant de valider l’échange, pour éviter la propagation virale d’erreurs.
3. Imperfection de généricité
Supposons un échange qui semblerait parfait, du point de vue
du fournisseur, ce fournisseur étant polarisé sur un cas, un métier, une vision en silo, etc…
En réalité, dans une vision plus globale, on peut estimer que ce n’est qu’un
cas particulier, et que, dans cette vision, ce cas doit être inclus dans un
ensemble plus vaste.
On ne peut alors laisser émetteur et récepteur échanger en toute
quiétude : du point de vue global, leur échange « privé » serait
imparfait, particulier, troublant la simplicité d'une vision plus distanciée.
Cet échange est à placer dans un cas plus général. La collectivité peut ainsi disposer d’une perspective transverse, de bon niveau. La généricité simplifie le SI, et facilite sa transformation.
Cet échange est à placer dans un cas plus général. La collectivité peut ainsi disposer d’une perspective transverse, de bon niveau. La généricité simplifie le SI, et facilite sa transformation.
4. Imperfection de granularité
Entre 2 niveaux d’échange, l’un se situant à un niveau
« macro » et l’autre au niveau le plus fin, le niveau du grain d'information, le second
est amplement préférable. C’est une règle d’Urbanisme fondamentale.
En effet les échanges d'agrégats sont remis en cause par les changements dans la logique d'agrégation. Il est plus simple et stable de calculer les agrégats à la demande, au moment du besoin.
En effet les échanges d'agrégats sont remis en cause par les changements dans la logique d'agrégation. Il est plus simple et stable de calculer les agrégats à la demande, au moment du besoin.
5. Imperfection de publicité
Supposons un échange, parfait sur tout critère, mais qui,
totalement ou partiellement, peut intéresser un espace "public", au sens de l'Urbanisme du SI. Il n’a pas à
rester totalement privé, ou sous statut privé s'attribuant de redondantes fonctions de publication.
La publicité des informations peut être organisée, en regard d’un contrat de
dépôt, et gérée, en vertu de contrats d’abonnement.
La mutualisation de cette fonction réalise une économie
d’échelle, dés-imbrique les fournisseurs et les clients, et donne la connaissance transverse du patrimoine.
6. Imperfection de stabilité
Supposons un échange parfait à un moment donné. Cependant,
après des évolutions fonctionnelles, des modifications sont introduites, rendant
les échanges impossibles en l’état, et impliquant une gestion de version, coté fournisseur et coté client.
Ceci crée une complexité. On peut compenser ce trouble en masquant l’instabilité, les versions successives étant converties en variantes d’une seule et même version.
Ceci crée une complexité. On peut compenser ce trouble en masquant l’instabilité, les versions successives étant converties en variantes d’une seule et même version.
7. Imperfection de subsidiarité
En l’absence de gestion de la subsidiarité, deux situations
extrêmes sont possibles et déséquilibrées :
- Tout gérer au niveau central, en étouffant toute gestion ou initiative décentralisée,
- Ne rien mettre en cohérence, entre des espaces autonomes qui ne respectent aucune contrainte.
Bien souvent, des échanges soit totalement centralisés, soit totalement
décentralisés, sont imparfaits : ils provoquent des associations entre
composants mal positionnées, avec des effets pervers à terme. Par exemple à la centralisation extrême s'associe une combinatoire des composants tout azimut. Avec l'autonomie débridée, les incohérences sont la règle.
La subsidiarité se décline sur plusieurs axes (organisationnel, commercial, produits, ...), nécessitant une vision globale de tous les points d'équilibre.
La subsidiarité se décline sur plusieurs axes (organisationnel, commercial, produits, ...), nécessitant une vision globale de tous les points d'équilibre.
La gestion de la subsidiarité permet de fixer les points
d’équilibre (pour les données et pour les meta-données) et de créer les paramètres pour les faire
évoluer.
Il faut mettre sous contrôle les interactions entre les atomes du SI. Il faut une "médiation" entre composants, appliquant ces 7 principes. Et tuer ainsi dans l’œuf complexités et rigidités congénitales.
Un clivage éternel
La cité des composants, à urbaniser, est clivée entre :
- composants partagés, candidats à la référence publique : retraçant structures, identités, cycles, parcours,
- composants subsidiaires, fruits de l'autonomie privée.
Ce clivage, calqué sur les chaînes de valeur, est peu variant. Il transcende les soi-disant IT bimodal, les chapelles du structuré et du non structuré, les frontières de l'Entreprise en dilution, les Internet de toutes choses...
Reconnaître les 7 principes d'urbanisme permet, au travers de solutions organisationnelles ou techniques, de simplifier le SI, de le rendre plus économique, transformable par hybridation, et flexible.
La vision urbanistique s'impose comme la métaphore réaliste, permettant, dans une vision long terme, de transformer progressivement le patrimoine, sans Big Bang, sans lourde méthodologie.
L'effort principal n'est plus à porter sur la méthode miracle, ou sur le clivage technologique.
Il faut agir, car, dans les interfonctionnements par milliers, ces échanges intimes au SI, le "laisser-faire" aboutit inexorablement au trouble, au risque, et à l'embolie.
