samedi 30 avril 2016

Sept principes d'urbanisme des systèmes

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.


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.

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.

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.

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.

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 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.

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.

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.

jeudi 21 avril 2016

De l'Architecture d'Entreprise à l'Architecture d'Ecosystème


Le concept d'Architecture d'Entreprise structure la pensée des Urbanistes SI ou des Architectes d'Entreprise depuis des décennies. Cette approche historique est menacée par la 3 ème révolution industrielle, et par le séisme technologique en cours. La faire évoluer ? Lui substituer une nouvelle approche ?

La nécessité d'une vision globale


Au delà des évolutions en cours, la nécessité d'une vision de moyen terme demeure. Elle doit être globale, et l'Entreprise ne peut s'en remettre à la seule dynamique des projets. L'ensemble du patrimoine des applications, et des nouveaux composants, issus de tous ces projets, résulte de visions locales, partielles, opportunistes. Cet ensemble, au fil du temps, deviendrait de plus en plus complexe, redondant, incohérent. Malgré les progrès technologiques, les mêmes causes produiraient les mêmes effets, qui ont justifié l'Architecture d'Entreprise et l'Urbanisme des SI.

Certes le développement agile, les microservices, les Big Data, nouvelles plateformes effacent de vieilles contraintes. Mais la maîtrise d'une complexité globale reste le sujet majeur, qui dépasse le SI : ce système d'information est calqué sur l'organisation de l'Entreprise, sur les Métiers. Il en reproduit fidèlement cloisonnements et complexité.

Sur quel périmètre architecturer l'Entreprise ?


L'Architecture d'Entreprise s'est développée avec une approche centrée sur l'Entreprise. Elle a lutté contre le cloisonnement, les fameux silos, et le manque de vision à terme, avec cible ou "To Be".

La révision de la méthode et des processus de l'EA est indispensable (voir à ce sujet "le futur de l'Architecture d'Entreprise"). Mais sur quel périmètre appliquer notre projet "urbanistique" ? Faut-il encore cartographier l'Entreprise ? Le bureau d'étude d'urbanisme doit-il se limiter à la Cité ? Et d'ailleurs, quelle est la Cité du SI de l'Entreprise numérique ?

Les frontières de l'Entreprise se dissolvent dans l'Ecosystème


Les fonctionnements entre l'Entreprise et ses partenaires, entre l'Entreprise et ses clients, se dématérialisent, et surtout s'automatisent. Les coûts d'interfonctionnement en sont réduits, et les processus deviennent transverses aux Entreprises et organisations.

L'Entreprise et ses partenaires forme un conglomérat qui fonctionne, progressivement, comme une seule et même Entreprise... Un conglomérat d'entreprises interconnectées et fournissant les services sans latence, directement sans le détour de processus, et autres chicanes héritées des traitements papier, des guichets, des saisies...

Ce conglomérat n'est pas simple addition, juxtaposition : il se constitue en intelligence, chaque partenaire y jouant le rôle pour lequel il est le mieux doté, avec les meilleures capacités.

Le terme d'Ecosystème désigne ce conglomérat multi-acteurs.
Un écosystème, ses acteurs, ses échanges, ses cycles de vie


Vers les SI d'Ecosystème


L'analogie, du point de vue de l'Architecture du SI, entre l'Entreprise et l'Ecosystème est flagrante :

  • Dans l'entreprise on se plaignait des silos, avec leurs visions orientées "métier", on s'efforçait de partager les grands référentiels transverses par une approche de type MDM,
  • Dans l'entreprise on créait des entrepôts transverses, reprenant les données issus de divers flux, pour alimenter le décisionnel... on mettait en place des MDM, du pilotage, des "visions 360",
  • Dans l'entreprise on orientait le SI vers le client, pour le fidéliser, l'engager, diversifier l'offre.

Avec l'Ecosystème, se posent les mêmes problématiques avec acuité. Elles transcendent celles de l'Entreprise, "piégée" par l'Ecosystème comme canard dans sa mare. Simplement, les questions d'affrontements internes, les zizanies, ... deviennent des confrontations concurrentielles, d'influence, de lobbying réglementaire.

Le SI de l'Ecosystème, comme du temps de l'Entreprise, est enjeux de pouvoir. Ce levier est crucial puisque les luttes ne sont plus intestines, mais de survie, dans le monde implacable des rendements d'échelle de l'Iconomie.

Et le client, doté de la meilleure "application", devient l'arbitre du duel économique.

L'Architecture d'Entreprise connectée à l'Architecture d'Ecosystème


Le barycentre du SI passe ainsi de l'Entreprise à l'Ecosystème. L'Architecture d'Entreprise n'a plus guère de sens, si elle n'est alignée, et subsidiaire de l'Architecture de l'Ecosystème.

Par exemple, tel référentiel, qui identifie les acteurs, tel autres des clients, ou encore tel référant les cycles de vie,... : ces données maîtres ont un tronc commun à toutes les parties prenantes de l'Ecosystème. Logiquement, des offres globales, spécialisées par type de référentiel, émergent, comme par exemple pour la gestion des référentiels produits.

On réutilisera le savoir-faire acquis pour "architecturer" l'Entreprise, en adaptant la méthode :  L'Ecosystème est, par construction, multi-acteur. Il est, dans le contexte, très évolutif. Son Architecture ne peut être conçue comme la bonne vieille Architecture d'Entreprise, avec ses processus normés, sa Gouvernance, et son lent déploiement.

De l'infiniment grand ...


Jusqu'où peut nous amener le saut conceptuel de l'Entreprise à l'Ecosystème ? Quelles sont les nouvelles frontières ? Vers de super écosystèmes où toutes les Entreprises se diluent ?

L'avenir est incertain. Pourtant des frontières "virtuelles" existent, celles marquées par les événements pertinents pour l'écosystème. Par exemple :

  • Si l'Ecosystème a trait aux soins, il s'agit des parcours de santé, et des cycles de soin. Après tout, les phénomènes, même si leurs modalités changent, sont éternels : vieillissement, maladie, thérapies, hygiène de vie, etc...
  • Si on s'intéresse à la mobilité, une organisation en Ecosystème est tout aussi complexe, rythmée par les jalons du parcours physique. Avec des modalités changeantes (transports automatiques, covoiturage, uberisation) dans un cadre éternel (aller d'un point A à un point B, et à cette occasion voir, communiquer,...).

Et pourquoi ne pas intégrer de tels ensembles dans une "Smart City", ville intelligente et connectée ?

à l'infiniment petit


De l'infiniment grand à l'infiniment petit. A l'opposé de cet infiniment grand, l'infiniment petit de l'atome d'information : le grain le plus fin, porteur de sens pour tous les participants à l'écosystème.

Ce grain d'information est le plus petit commun dénominateur de l'Ecosystème, toutes les parties prenantes le comprennent, et le reconnaissent comme trace de leurs actions communes.Il n'est pas toute l'information, mais il est centre de la marguerite d'informations, à la quelle chaque contributeur apporte son pétale. Il identifie l'objet et l'événement : l'individu, la maladie, le soin, dans notre exemple.

Quelles que soient les recompositions de l'Ecosystème, le modèle du grain (voir ce concept), des gains typiques, demeure. Pour le recueillir, le tracer, la figure de style du Puits de données s'impose.


L'Architecture de l'Ecosystème existe


L'Architecture d'un Ecosystème existe. Comment organiser les systèmes autour de ces grains, pivots de cohérence et de synergie ? Par quel miracle l'Ecosystème pourrait-il fonctionner autrement ? Car il lui faut une épine dorsale de SI pour véhiculer les influx nerveux.


Est-ce de la philosophie ? De l'Iconomie ? C'est l'application d'une méthode rigoureuse adaptée à cet enjeux : l'Architecture Flexible. L'Architecture de conquête de l'Ecosystème.

dimanche 17 avril 2016

Une architecture canonique

En rappel d'anciens souvenirs d'adoration des mathématiques l'idée est ici atteindre, dans la conception d'une Architecture, une "forme canonique", la forme unique et durable...

En effet les définitions de l'Architecture Flexible, récentes, sont faites pour que le concept dure.

Cependant, le doute est là. Ces concepts résisteront-ils aux modes et aux avancées technologiques ? D'autres solutions architecturales émergeront-elles ? Les 5 flexibilités apportées suffiront-elles pour traverser tous les aléas ?

La "solidité" de l'Architecture Flexible se trouve dans sa logique de conception, et la recherche d'une forme canonique, pierre philosophale de l'Architecture d'Entreprise.

Des axiomes universels


Un axiome est une vérité première, facilement vérifiable, mais non démontrée. Sur cette base, une théorie peut être développée, dans un enchaînement déductif.

Les axiomes de l'Architecture Flexible sont :
  • l’Architecture se développe dans l'Ecosystème
  • des données de référence partagées existent dans tous les cas de SYSTEMES (domaine, Entreprise, Ecosystème), dans le SI et au delà
  • les modèles « pivot » des données de référence sont simples et stables
  • Ces modèles pivot s'étendent en fractales et par jeu de subsidiarité
Ce jeu d'Axiomes vient en complément de ceux basant la Trame Business :
  • les transformations se font toujours par étapes
  • les événements sont organisés en cycles et parcours
  • les événements sont à l’origine des transformations
  • un SYSTÈME est toujours agité par plusieurs cycles
Ces 8 vérités objectives sont la base logique de tout édifice d'Architecture d'Entreprise. Une base, intemporelle, liée, ni à une technologie, ni à une activité.

Une déclinaison logique


Photo de Doisneau (extrait)
Sans entrer dans le détail, pour chaque cas d'usage, on adaptera l'architecture aux chaînes de valeur, aux objets concernés, aux biorythmes des transformations. On réglera et paramétrera les modèles (MDM, Puits) aux jeux de configuration (désintermédiation, intégration, modèle d'organisation, de collaboration).

Cette déclinaison, ce jeu de construction, est un travail passionnant de conception :

  • où l'on assemble les pièces standards (figures de style) dans un Lego d'Architecture constituant l'épine dorsale architecturale.
  • puis on connecte les composants et applicatifs sur cette épine dorsale, dans un Lego systèmique d'ensemble

Une démarche rigoureuse, logique, créative, car distançant l'existant et ignorant les poncifs et prérequis méthodologiques.

Combler un "vide" conceptuel


A une époque où les anciens dogmes sont brisés, les stéréotypes de haut-niveau, comme les framework d'architecture, ne sont plus opérationnels. Le taylorisme qu'ils préconisaient n'est plus de mise.

L'omni-présence technologique, et l'état de grâce induit, pourrait laisser croire qu'il suffit de développer en méthode agile, d'appliquer les circuits courts de DevOps, d'assembler des microservices.

Même si chaque acteur du SI était infiniment agile, et que tous ces composants s'assemblaient de façon parfaite, que dire du résultat final ? Il serait image, certes d'une infinie qualité dans la perfection du détail, mais restituant une trame, une conception d'ensemble sous-jacente. Cette perfection ne garantirait pas l'adéquation au problème posé. Car cette adéquation ne se joue pas dans le détail et l'anecdote.

Plus que jamais, l'effort de conception est primordial : il conditionne toutes les merveilles technologiques, les projets et leurs habiles servants, la conduite du changement, l'image propagée auprès des utilisateurs et clients, et les services rendus... Avec le nouveau paradigme qui se met en place, se creuse un vide conceptuel.

L'Architecture Flexible, en proposant un schéma d'ensemble, et la façon d'approcher progressivement une cible, comble ce vide conceptuel.

En synergie avec la technologie


Les avancées technologiques ne s’arrêteront pas.

Prenons l'exemple de la Blockchain, présentée comme l'innovation majeure de l'après Internet. Ne nous bloquons pas à la question des cyber-monnaies, qui cache la forêt des usages potentiels. Finalement cette technologie permet de créer des "registres" fiables, infalsifiables. L'équivalent des dispositifs d'enregistrement des actes auprès des services de publicité foncière (où tout un chacun peut déposer un acte pour preuve de son d'authenticité).

N'est ce pas la technologie rêvée pour instancier un puits de données dans le cadre d'un écosystème réunissant plusieurs partenaires ? Elle historise, authentifie, et coupe court à toute contestation.
Les obstacles de performance actuels seront probablement levés, dans les cas pratiques au l'ouverture est restreinte. D'ailleurs c'est la technologie qui est intéressante, et non son cas d'usage pour les cyber-monnaies, où le diable du super profit est à l'oeuvre.

En synergie avec le futur de l'Iconomie


Sur le plan économique, "Iconomique", on n'est pas non plus à la fin du film. Prenons l'exemple des objets connectés.

Dans de nombreux cas, il faudra synchroniser, orchestrer ce déluge d'événements, avec les grandes orgues des applications existantes. Il faudra se fonder sur des référentiels. Bref, émerge un monde hyper-structuré, car les objets n'inventent rien, et leurs messages utilisent un vocabulaire déterministe.

Et l'on verra apparaître des référentiels et "puits" configurés comme pivots de ces données déferlantes. Le V de variété des Big Data ne doit pas cacher la cohérence implacable des automates, au centre de ce cyclone de données.

Une Forme Canonique


L'Architecture Flexible est-elle unique ? Ne serait-elle pas la forme canonique attendue ?

D'une façon ou une autre, dans un monde d'une infinie complexité, on devra reconnaître les concentrations focales qui fédèrent sa sémantique, structurent sa syntaxe, figent ses meta-données.

Par delà les péripéties technologiques, le développement de cette complexité s'organisera autour de pivots de flexibilité, véritables "éléments neutres" de l'algèbre des cyberespaces.


L'Architecture Flexible préfigure cette forme canonique incontournable.