L'évolution darwinienne des Systèmes d'information

Dans un monde qui semble imprévisible, avec des bouleversements économiques, sociaux, technologiques, les certitudes et rationalités passées sont remises en cause.
De quoi le monde de demain sera-t-il fait ? Un monde hyper-connecté, mais avec quelle redistribution du travail et des richesses ? Quels "business models" à succès, au delà des ubérisations de facilité ?

On prédit que d'autres grandes entreprises globales suivront le sort de Kodak, vont disparaître, qu'une multitude d'emplois traditionnels seront exclus de l'économie, que des légions de start-up vont tailler des croupières aux groupes les plus puissants...

Dans l'économie des systèmes d'information, qu'elle soit interne à l'entreprise, ou plus globale, le "bouillon de culture" d'une évolution darwinienne est aussi à l'oeuvre, dans une remise en cause généralisée des architectures, méthodes et outils traditionnels.

Cette métaphore de l'évolution nous ouvre une double perspective : celle de l'effet déterminant des aléas, et celle des répercutions "systémiques" aux conséquences souvent violentes.

Cette vision s'applique particulièrement bien aux systèmes d'information.

L’Écosystème et ses cycles de vie

Infographie d'un écosystème

Le terme d'écosystème caractérise un ensemble dont les composants sont :

• variés : par exemple des entreprises et organisations multiples, ou, dans le SI : des composants (micro-services, composants d'intégration, APIs, ...), ou en biologie des cellules, des bactéries, ...
• vivants en symbiose forte, avec des interactions synergiques : tissus de PME, systèmes complexes, biotopes, ...
• en mutation continuelle : démographie des entreprises, création de composants logiciel, mutations génétiques,... 

On peut analyser le fonctionnement d'un écosystème, quel qu'il soit, à plusieurs niveaux :

• celui des opérations individuelles, cycles qui font vivre les organes, individus, entreprises, avec leurs diversités et leurs symbioses...
• celui de l'ensemble constitué par l'écosystème, dans une vie globale, en abstraction des vies détaillées, comme on observe la vie d'un corps humain en abstraction de ses vies cellulaires, des vies bactériennes qui l'habitent.

Cette analyse, qu'elle soit individuelle ou globale, est faite "à système constant". En quelque sorte comme si les règles de fonctionnement étaient figées. Mais il y a aussi, dans l'échelle temporelle d'un écosystème, d'autres évolutions, fondamentalement distinctes des précédentes, de ces transformations opérationnelles que nous venons d'illustrer, ce sont :

• celles des mutations qui modifient les caractéristiques "génétiques" (gènes, business model, logiciel...) des individus, 
• les changements d'équilibre de l'écosystème, soit par l'effet des mutations, créant de nouvelles compétitions entre les espèces et une sélection naturelle, ou par l'impact de changements exogènes.

Dans le langage courant on utilise les termes de transformation (transformation numérique) de changement (conduite du changement), d'évolution (théorie de l'évolution), de mutation (mutation génétique). Il faut les relier dans une perspective systémique.

La théorie darwinienne  fournit une explication de ces transformations et évolutions des écosystèmes, dans une telle perspective.

L'Architecture d'Entreprise et la vision darwinienne des "système d'information"

La complexité des systèmes d'information n 'a cessé de croître depuis l'apparition de l'informatique. L'extension de ces systèmes, la dynamique de leur évolution, leur interaction de plus en plus intime avec le monde vivant, rend les modélisations, la maîtrise, le contrôle, la prospective de plus en plus difficiles. Pourtant les enjeux sont majeurs et dépassent la technologie.

L'Architecture d'Entreprise, sensée procurer les leviers de compréhension et de maîtrise des SI, est face à un défi. Une vision darwinienne des systèmes d'information, de leurs populations de composants, de leurs mutations continuelles, peut s'appliquer. Certes l'Architecte n'est pas un biologiste, mais il doit appréhender l'infiniment petit des micro-services, l'infiniment multiple des technologies et des solutions, dans un marais logiciel qui repousse toutes les limites.

Le courant de pensée de l'Architecture d'Entreprise est celui d'une pensée rationnelle, qui voit le SI comme un tout cohérent, décrit selon différentes vues par des cartes fidèles de son état (cartographie des fonctions, des processus, architecture technique, ...). Cette pensée rationnelle peine maintenant à saisir tout le SI et toutes ses évolutions. Elle peine à décrire la complexité des interactions systémiques, car elle utilise des prismes d'analyse classiques, figés, devenus doctrinaires.

Pourtant une vision globale des systèmes d'information, comme l'Architecture d'Entreprise a l'ambition de restituer, doit être systémique, car par delà l'apparente complexité, les interactions suivent des lignes invariantes, comme nous l'avons maintes fois expliqué sur ce site.

Par ailleurs, la culture de l'ingénierie des SI, n'admet pas les aléas, qui sont pourtant la règle constatée en pratique.

Au centre de la théorie Darwinienne de l'évolution, se trouve l'hypothèse de mutations aléatoires des espèces. Cette idée, appliquée au SI et à ses populations de logiciels mutantes, amène à penser que, dans le SI comme ailleurs, d'impondérables aléas jouent un rôle déterminant. Nous allons en donner l'explication.

L'effet Bolos "tombeur" des projets SI complexes

Le bolos est un lasso terminé par des brins de longueur différente et affublés de boules de diverses masses. Ce lasso, manié correctement, est très efficace pour capturer un animal, car les boules bloquent par exemple les pattes de la victime. L'explication est simple: lors du jet du lasso, parmi l'infinité de parcours des boules possible, et des enroulement provoqués, il y a une probabilité voisine de 1 qu'un des enroulements soit bloquant autour du membre de l'animal visé...

Dans le souffle en partie erratique d'un projet SI complexe, les opportunités que se crée, suite à divers aléas, dont l'origine est imprévisible, mais l'émergence une certitude, des situations malencontreuse, sont légion : communication catastrophique, déploiement de solution de rupture, choix d'infrastructure IT malheureux et inadapté, conception amont s'avérant trop tard erronée, volte-face d'un éditeur, Big Bang imprudent, ... autant d'états imprévus et souvent difficilement réversibles.

Transposons le lancer de lasso au cas de la migration induite par un projet SI complexe. La "capture de la cible" réussira-t-elle ? Supposons qu'un être supérieur, pleinement rationnel, par exemple un Architecte d'Entreprise (!) ait pu objectiver la migration de ce système complexe, et ait formalisé tous les chemins en un labyrinthe (voir par exemple l'articulation proposée ici) : selon ce plan, beaucoup de chemins de migration n'aboutissent pas, et seul un petit nombre amène au résultat.

En réalité, bien que la rationalité soit un axiome de base de la culture IT, on ne dispose pas d'un tel plan, ... en pratique, assommés par les prérequis de tout décrie et cartographier, faute de temps,de clairvoyance, face à une complexité incommensurable, les acteurs projet partent "à la découverte" de la cible, sans fil d'Ariane. C'est un péché d’optimisme, voire une croyance aveugle en l' "agilité" capable de parer à tout... Dans une cette précipitation optimiste, le parcours de migration prend la forme d'une succession de tirages aléatoires, à chaque embranchement imprévu du labyrinthe. Il faudra énergie et retards pour, par tâtonnements, trouver les bons passages. Le projet subit une inflation des coûts et délais. Qui a vécu des projets complexes pourra relater les multiples anecdotes, voltes-faces et stériles détours qui émaillent l'histoire erratique du projet. Pire, la probabilité d'être confronté, en cours de route, à une situation irréversible, un effet bolos, est forte.

Tous ces parcours de projet erratiques expliquent les statistiques d'échecs de projets, dont on connait l'accablante reproduction depuis que les projets SI existent (cf. rapport Chaos) ! Alors que seulement 2 % des grands projets aboutissent, ce phénomène perdure (voir le projet Louvois). La sélection naturelle darwinienne s'applique aux projets SI !

Le coupable est l'Architecture

Au sein du mouvement brownien des composants logiciel, avec leurs empilements coralliens, et leurs mutations constantes, que l'agilité logiciel permet de créer à tout propos, il y a 2 types de composants :

• ceux dont les évolutions ont des effets qui se limitent à un petit nombre d'autres composants,
• ceux dont les évolutions ont un impact général sur une vaste population de composants.

De fait, tout patrimoine SI peut être discriminé selon ce filtre. Tout patrimoine SI a une épine dorsale, qu'elle soit voulue ou subie, qui en est l'Architecture, avec un grand A. Les composants d'Architecture font partie de la classe des composants à fort impact.

Un système logiciel complexe est donc bien plus sensible aux aléas pervers affectant les composants d'Architecture, qu'aux mêmes effets s'appliquant aux composants ordinaires. Un échec, une étreinte fatale, un effet bolos, concernant des composants ordinaires ne se propage pas au sein du patrimoine, et son impact reste local. Il en va bien sûr autrement pour les composants d'Architecture.

La sinistralité des projets trouve ainsi son origine dans des erreurs d'Architecture : absence de vision systémique, ambition d'une exhaustivité illusoire, croyance en une rationalité pourtant impossible.

Pour l'Architecture, la tradition rassurante est de vouloir tout décrire, laissant ainsi agir une combinatoire infernale : on préfère une description extensive irréaliste et molle, à la rigueur se focalisant sur le noyau structurant. Dès lors les aléas se propagent de façon incontrôlée, et systémique.

En conclusion, la métaphore de l'urbanisme a déjà utilement fécondé les approches d'Architecture d'Entreprise en France. Celle de l'écosystème darwinien ouvre une perspective pour :

• en terme d'Architecture, bannir la rigidité, la complexité, et le laisser faire : avec un minimum d'effort de conception ciblée, l'offre technologique permet une flexibilité jusqu'alors inconnue (cf. ici l'Architecture Flexible)
• en terme de développement de composants : l'agilité permet d'accélérer le processus et d'en améliorer l'adéquation à des "besoins" locaux.

La flexibilité d'Architecture (pour aller plus loin: voir le site dédié) est indispensable à la pérennité de l'écosystème du SI.

Du monde des formulaires au monde ultra connecté

Les interfaces avec le vivant, mobiles, tablettes, objets personnels connectés, ... se multiplient.
Se créent ainsi des espaces d'activité, de vie, de santé, connectés, qui étaient inimaginables avant cette rupture technologique. Ce monde du connecté donne l'exemple d'un fonctionnement plus direct, immédiat.
L'organisation traditionnelle, avec ses agences physiques, ses guichets, réels ou virtuels, ses formulaires, matérialisés ou dématérialisés, ses processus, doit se remettre en cause, se donner une perspective, avec ces exemples qui se multiplient dans tous les espaces de vie.

Une organisation héritée des contraintes matérielles

Avant l’ubiquité de l'internet, avant l'intimité et l'immédiateté du connecté, les contraintes matérielles étaient multiples :

• espace physique, imposant aux clients, aux administrés, de se déplacer, aux grandes entreprise et administrations de créer des agences locales
• supports de communication pauvres, souvent réduits au papier pour la formalisation des transactions (achats, traces d'activité, d'événements de santé, d'état civil, ...)
• délais de traitement importants et nécessité de concentrer en masse pour industrialiser la production matérielle, et et les services dans les premiers temps de la mécanisation (mécanographie, informatique de production,...).

Bref un monde où règnent les sacro-saints formulaires. Un monde atteint d'une lourde pathologie de division de l'économie en grandes structures spécialisées, centralisées, elles mêmes organisées en silos pour maîtriser la compétence et jouer les rendements d'échelle.

Bien sûr, la civilisation, qui est en train de s'achever à petits pas, a mis des siècles à évoluer, à se perfectionner, au gré des conflits, et des accidents de parcours. Elle à créé des systèmes d'information gigantesques, une organisation sociale, et de multiples protections.

Bien sûr, elle perdure dans des métiers, même si certains sont ubérisés ou pourront l'être, elle perdure dans une réglementation pléthorique et souvent ubuesque, dans les structures mentales, les enseignements, et bien d'autres stéréotypes.

Elle perdure aussi dans les démocraties actuelles qui ont peu prise sur ce monde connecté émergeant, trans-national, parfois immoral et déréglementé : leur réponse est souvent d'arrière garde, au mieux marginale, et parfois dérisoire face aux enjeux géopolitiques.

Les fondements du monde ultra connecté

La révolution en cours nous amène à des organisations de la société radicalement différentes, dont il est difficile de prévoir toutes les configurations.

Cependant, en faisant abstraction de l'histoire et de ses pesanteurs, on fait apparaître un fonctionnement "nominal" d'une telle civilisation :

La "vie" des personnes, des acteurs économiques, des institutions, des objets, des écosystèmes, est rythmée par des événements, c'est une loi universelle. Dans un monde connecté :

• la préhension de l'événement se fait au plus près, sans détour, capté par une intelligence connectée
• cette préhension est immédiate
• elle déclenche une chaîne de valeur automatique, qui, grâce aux API et aux multiples recompositions des acteurs économiques, collaboratifs, administratifs, et des systèmes techniques,... se propage pour le meilleur et, peut-être, pour le pire.

Ce modèle est celui de la "Trame Business" (que j'ai pu définir il y a une décennie). Il est fondé sur les événements, les cycles, les parcours, et leurs invariants. Il fournit la vision la plus stable possible, résistant aux évolutions de SI, aux ruptures business, aux changements de modèle, traversant les révolutions technologiques, les refontes de processus, et les reconfigurations économiques (désintermédiation, globalisation, ...).

Bien sûr, le rêve d'un monde ultra connecté, simple et efficace, peut paraître lointain, Mais les pièces du puzzle se mettent en place, on en voit des exemples tous les jours. La pression d'une économie globalisée, l'accélération de la créativité, le darwinisme qui en découle, la super puissance des GAFA, l'extension du monde du logiciel libre : la dynamique est en route, le cycle historique est engagé.

L'hybridation des 2 mondes

Un tel bouleversement ne se fera en un jour. Il atteint d'abord certains secteurs économiques, certaines chaînes de valeur facilement uberisées par les circuits courts de la communication connectée.

En quelque sorte une révolution à ciel ouvert, exploitant les nouveaux gisements de valeur révélés par la banalisation technologique, avec des investissements faibles, et des coûts récurrents dérisoires. Car l'infrastructure est devenue une sorte de "service public" globalisé, financé par ailleurs.

Les différentes vagues de révolution technologique exposent ainsi de nouveaux gisements à ciel ouvert. Par exemple ceux qui apparaîtront avec la blockchain, pour créer de multiples formes de notariat.

Mais à coté de ces nouveaux territoires, les répartitions entre acteurs économiques vont bouger, prolongeant des mouvements déjà engagés, par exemple dans la mobilité, ou encore dans le monde de la santé. Les grands secteurs économiques entrent alors dans la dance, et les plus solides tremblent sur leurs bases... craignant de subir le sort de Kodak.

Quel est l'intérêt "supérieur" des Etats, des collectivités, par delà ces secousses telluriques ? Les emplois fondent au soleil de la "numérisation" ? Couver des start-up, former des ingénieurs, qui partiront ailleurs ? Certains pensent que le salut vient de l'agilité... comme si l'agilité en développement de logiciel créait l'agilité en affaires.

Il n'y a pas bien sûr de recette miracle pour négocier un tel bouleversement. Plutôt que d'agilité, incantatoire quand on mesure les multiples pesanteurs de notre contexte, c'est de flexibilité dont on a besoin : l'existant, avec son inertie, ses masses, ses règles, impose aussi son tempo. Le choc frontal que certains appellent de leurs souhaits, peut être encore plus destructeur. Cette flexibilité serait salutaire. Elle se décline sur tous les plans :

• flexibilité du SI,
• flexibilité de l'organisation,
• flexibilité des règles internes,
• et, au final, flexibilité de la réglementation elle-même, ce qui n'est pas une mince affaire.

En ce qui concerne le SI, on trouve sur ce site les concepts de l'Architecture Flexible, qui permettent d'évoluer au travers de tous ces changements, sans rejeter ni les nouveautés, ni le "vieux" patrimoine encore indispensable... Donc de trouver l'optimum entre "je casse tout" et "je garde mes vieux systèmes".

Au delà du SI, à une époque où les "Direction Digitale" poussent comme champignon, cet exemple est emblématique. Saura-t-on trouver de telles voies ?

Un défi de complexité

Le monde actuel est extrêmement complexe. Mais le transformer est d'une complexité d'un autre ordre de magnitude, car c'est s'engager dans une combinatoire infernale.

Certains ont pensé qu'on pouvait décrire a priori une telle aventure. On a vu naître des méthodes d'Architecture d'Entreprise, prétendant transformer non seulement le SI, mais aussi toute l'entreprise dans une vision englobante. Ces outils sont maintenant mal-adaptés, et nuisibles à l'image de la profession des Architectes d'Entreprise, du fait de leur lourdeur et l'anachronisme de leurs bases technologiques. Le pragmatisme, les échanges d'expérience entre pairs, s'avèrent bien plus efficaces que les prérequis et prescriptions méthodologiques (le Club Urba-EA le démontre dans la durée).

Dans le cas de la complexité du SI, elle peut se réduire progressivement par une Architecture Flexible, qui concentre les quelques charnières stratégiques dont l'entreprise a besoin pour traverser les ruptures technologiques et les "disruptions" de business : inutile de cartographier le labyrinthe, si l'architecture permet de s'adapter rapidement aux imprévus.

Pour le reste, pour ce contexte qui semble souvent anarchique, ubuesque, accablant de formules et exigences superfétatoires, que faire ? Il faut s'atteler à sa migration. La complexité actuelle est en grande partie due aux contraintes historiques subies depuis des siècles. Maintenant, dans un monde connecté, tout peut être plus simple, validé en direct, et apporte sa valeur dans l'immédiat.

L'exemple de l'outil socio-technique de notre "modèle social" est particulièrement illustratif : assiettes de calcul décalées de plusieurs exercices, nécessitant acomptes, régularisations, provisions, règles de calculs abscons, multiplication de plafonds... au travers de "régimes" différents, divisant les citoyens.

Le décalage d'informations, la massification des déclarations, la multiplication des cas particuliers sont autant de facteurs de complexification. Pour avoir travaillé sur les premiers "guichets uniques" j'ai touché un peu cette complexité, approché les récifs réglementaires. Et que dire des premières "liasses" tentant de regrouper les multiples cas particuliers sur un document unique, dans le cas des CFE (centre de formalité des entreprises) ? Un casse tête... Et des scandales comme celui que connaissent les indépendants avec les affres du RSI, et le gouffre de ses rapports avec l'URSSAF... Un notariat des rémunérations reste à inventer !

Utiliser le levier du SI

On a l'habitude de parler, avec le vieillissement du patrimoine SI, de "dette technique"... Saura-t-on évaluer la "dette technique" de notre système d'assurance sociale ? Plus généralement, notre société n'est elle pas pénalisée par une immense "dette réglementaire", qui pèse sur son efficacité, et désavantage fatalement son économie et ses emplois ?

Seuls des systèmes "informatiques" peuvent aider à relever un tel défi de maîtrise d'une immense complexité : d'abord parce qu'il faut faire migrer la "couche" SI, mais surtout parce que la migration de tout le système ne peut se faire sans la mise en place d'un SI flexible, un levier qui la soutient, et évite les malheureux "big bang" dévastateurs.

PS Un sujet connexe à ces propos sera abordé lors de la conférence organisée par la CNAV ("Urbanisation du SI, gestion et validation de flux massifs de données : pratiques innovantes", table ronde avec René Mandel, le DSI de la CNAV et la DG du GIP-MDS) Inscription gratuite.

Les API vont-ils dissoudre le monde économique ?

Les API, interfaces standardisés, publiés, gérés, ... se développent dans l'économie de façon extensive.
La douce époque des "échanges informatisés", à base de normes interprofessionnelles, et de standards gouvernés, l'époque des EDI, de flux batch massifs, est surannée.

Les API s’immiscent à tout propos, dans les relations internes à l'entreprise, ou dans ses interactions avec ses clients, ses partenaires, voire avec des start-up friantes de conquêtes de segment de la chaîne de valeur.  Cette invasion ne va pas simplement bouleverser les SI, mais surtout rebattre les cartes des affaires.

Les transactions entre acteurs économiques

Chacun sait que la "valeur" résulte des transactions entre les acteurs économiques, car ces transactions matérialisent un échange. Echanges de biens, de services, de prestations, qu'elles soient marchandes ou non.
L'API devient la cheville ouvrière de ces transactions. Elle en change radicalement les modalités, le contexte socio-technique, la performance et le coût.

• Les modalités sont différentes : là où, bien souvent, il fallait solliciter un acteur humain, plus ou moins indisponible, téléphoner à un service saturé, remplir un formulaire complexe et inadapté, ou faire la queue à un guichet... la transaction est directe, colle à l'événement, et, dans l'idéal, aboutit sans détour au résultat attendu.
• Le contexte socio-technique est dès lors différent, ne mobilisant l'acteur humain qu'à bon escient, en toute connaissance de cause, le plaçant directement sur la globalité du sujet, sans perte et fragmentation dans de sombres processus.
• La transaction ainsi instrumentée est plus performante, agréable aux parties, et différenciante dans un contexte concurrentiel.
• Enfin, le coût de transaction, à forte composante technologique, chute de façon drastique, pour les transactions courantes, internes et externes, des entreprises et organisations.

Comme souvent, sous couvert d'une transformation numérique, une modification plus fondamentale est engagée.

La dissolution des frontières internes et externes

En effet, l'opportunité de changer de façon radicale les relations, internes comme externes, aura forcément des conséquences majeures :

• pour les organisations internes, qui structurent le fonctionnement des entreprises et institutions,
• pour les périmètres des entreprises.

Par exemple, en interne, la généralisation des API favorisera une organisation différente, moins structurée par les silos métier, plus fonctionnelle et modulaire, avec une hiérarchie réduite. Plus de fonctions seront ainsi facilement mutualisées et transversales.
En effet, les APIs et leurs contrats formaliseront le cœur des opérations, sans les inconvénients et les limites des relations humaines.
L'organisation  traditionnelle s'appuie sur une fragmentation des équipes, leur localisation en proximité, la cascade hiérarchique pour gérer les effectifs, les compétences métiers, les multiples transversalités.
En somme, après avoir été pendant des décennies structuré par l'organisation en "métier", et sa rigidité, à son tour, le SI structurera toute l'entreprise. C'est déjà ce qui apparaît avec la mise en place, dans de grands comptes, d'une Direction "Digitale", intégrant nouveau business et SI agile, et armée d'APIs.
Le mouvement provient de la technologie... Certes, mais l'effacement des barrières matérielles gomme ces artifices historiques, et aligne progressivement les organisations aux chaînes de valeur, par delà les frontières des métiers traditionnels.

Ce même mouvement remet rapidement en cause les frontières des entreprises. Déjà elles fonctionnent de plus en plus en écosystème le long des chaînes de valeur. Elles s'ouvrent à des partenariats, explorent les segments amont de la valeur. Dans ces interfonctionnements, la composante SI devient primordiale, et les jeux de configurations en sont facilités. En symbiose par APIs, les SI des partenaires deviennent reconfigurables.

Ainsi, à terme, avec les APIs, les entreprises deviennent elles-mêmes reconfigurables, pour leur bonheur ou leur malheur. Les lignes de fracture vont bouger, sur l'échiquier de la Trame Business.

APIfier mais autour de quelle architecture ?

Comment être à la hauteur des enjeux ? Il ne s'agit pas d'aller à l'encontre d'une dynamique vertueuse, qui pousse à ouvrir le SI, à le rendre accessible par tous moyens numériques. Mais où ces aménagements de surface conduisent-ils l'entreprise ?

On pourrait croire au miracle d'une mise en cohérence progressive, une simplification naturelle inconsciente, une sorte de "main invisible" qui mettrait tous les SI dans une situation optimale.

Pourtant l'expérience enseigne que seul le désordre se développe naturellement !

Au fond, par delà les API de surface, de quelle "architecture" l'entreprise se dote-t-elle ?

L'évolution de l'architecture est une transformation d'un autre ordre. Elle se réduit pas à l'API management. Elle dépasse le court terme, et pose des problèmes structuraux difficiles : maintien de l'existant, tolérance technologique, cohérence des référentiels, ...

On retrouve les grands classiques de l'Architecture d'Entreprise, d'une EA repositionnée, et revisitée, suite à l'invasion de l'informatique "agile". Car au centre de cette transformation, se trouve l'architecture du SI. L'évolution de cette architecture ne peut se faire en un instant, même si les métiers de l'IT deviennent miraculeusement agiles. Par construction, l'architecture du SI est un levier aux infinies conséquences, bien au delà du SI, des processus, jusque dans les opérations vitales de l'entreprise, sur les façades client, fournisseur, définition des produits, gestion des ressources, etc... Dans toutes les dimensions du Business Model.

Il s'agit alors d'investir sur le durable, en complément de l'APIsation, pour donner une nouvelle force à l'architecture sous-jacente.

Voilà une raison de plus de s'engager résolument dans l'Architecture Flexible, pour que l'avenir ne reproduise pas les errements du passé.

Les invariants sous-jacents révélés

Les APIs effacent les contraintes matérielles, mais ne vont pas recréer le monde. Les cycles de vie demeurent, pour les individus, les familles, les sociétés. Le monde ne s'arrêtera pas, les mêmes événements se produisent, simplement ils sont directement appréhendables par des moyens numériques.

Ayant prêché pendant des années pour la reconnaissance de cette invariance (voir à ce sujet la "Trame Business"), l'émergence des API renforce ces vérités premières. Les multiples APIs brillent de milles facettes. Mais, quand les viscosités, héritées des contraintes passées, seront dissoutes, elles refléteront les cycles et parcours qui structurent le monde vivant.

L'erreur serait de ne s'en tenir qu'à une vision superficielle, à une euphorie technologique, sans analyser ces cycles de vie, ces transformations, qui sont le fondement.

Architecture de Systèmes ou Système d'Architectures

Un château de cartes méthodologique

Visions ensemblistes, systémiques, démarches de modélisation se sont formalisées au cours des décennies de la courte histoire de l'informatique.

Elles sont à présent matures, et largement enseignées au niveau académique : modélisation des données, des processus, multiples langages formels dans la famille UML, métiers de l'analyse de systèmes, de l'amélioration des processus, ...

De sorte que plusieurs disciplines sont progressivement apparues. Chacune se réfère à ses propres standards, ses propres prescriptions, ses cursus, ses certifications.

Cependant, avec la révolution numérique qui est en cours, avec le séisme technologique amorcé, tous ces édifices de savoir et de certitudes sont ébranlés. Au sommet du "château de cartes" méthodologique, se trouve l'Architecture d'Entreprise, et nous avons ici argumenté pour sa refondation. Le doute atteint maintenant jusqu'à un expert de l'Open Group, organisme promoteur du Togaf, dont le corpus méthodologique est colossal.

Dans ce contexte, face à un projet de système, comment procéder ? Doit-on imaginer une cible ? La concevoir comme un tout cohérent, application d'un système de modèles ? Ou juxtaposer différents modèles ?

Parmi toutes ces approches, la plus tendancielle est celle qui juxtapose autant de modèles qu'il y a de disciplines. On peut la qualifier "Système d'Architectures" : elle combine Architecture des SI, Architecture métier, Architecture fonctionnelle, Architecture Technique...et tous ces termes coexistent.

"Système d'Architectures" : complexité, risques et sur-coûts

Toutes ces disciplines consacrent autant de visions partielles du "système". Elles s'écartent de la réalité de la vraie vie qui mixe processus, savoir-faire humains, logiciels, données, "apps", ...

La juxtaposition de ces différentes architectures crée de la complexité, car la symbiose entre les architectures est traitée a posteriori. Sans vision ensembliste, chacun des métiers d'architecture voit midi à sa porte. Doit-on concevoir d'abord les processus, les automatiser, et leur asservir les fonctions ? Ou, à l'opposé, faire table rase des processus, dans un enchaînement automatique de fonctions ? Ou encore, figer l'organisation pour y couler les exigences en système d'information ? Une combinatoire de détails de cohérence, aux multiples paramètres, conciliés au cas par cas.

La démarche "système d'Architectures" est risquée, car elle ne met pas le système d'ensemble à l'abri des surprises, dans le détail des interactions entre architectures. Au final, les multiples aléas, même improbables, en se combinant, génèrent retards et sur-coûts.

Pourtant, cette approche semble cumuler les précautions, les savoirs, la sécurité des certifications, et autres préconisations émises par toutes les fées disciplinaires (ISACA, Open Group, OMG, ISO,...). Mais c'est un faux semblant. Ce capharnaüm méthodologique ne garantit pas le succès, au contraire les projets sont pour une bonne part en échec, comme nous l'avons déjà remarqué ici.

La promesse de l'Architecture de Systèmes

L'idéal serait de concevoir une Architecture d'ensemble, une Architecture de Systèmes, qui puisse prendre en compte tout le système, dans sa complexité, et toutes ses facettes au delà de la seule vision "informatique".

C'est un défi de conception, un idéal, au quel veulent répondre, dans notre pays, au moins deux "Centres d'Excellence" en Architecture et systèmes complexes : CESAMES, et CEISAR. L' ambition de l'Architecture de Systèmes complexes est en effet immense. La promesse a une portée universelle.

Cependant cette excellence se traduit, dans chaque cas, par un "modèle" du "système" pris dans sa globalité. L'approche est logique, rigoureuse, sans doute "excellente", car présentée comme issue d'une certitude scientifique.

L'objet n'est pas ici de critiquer ces méthodes et leurs modèles. Elles sont cohérentes et remarquables. Simplement, leur axiome de base est qu'une telle maîtrise globale, dans un modèle homogène, est possible. Cet axiome est malheureusement totalement déconnecté de la réalité des actuels projets de systèmes d'information, dans un contexte secoué par une tempête d'incertitudes..

En effet, en pratique, dans l'exercice de l'Architecture d'Entreprise, le cas de la conception d'un nouveau système à partir de zéro ne se pose jamais :

• il y a la plupart du temps un existant, incontournable pour assurer la continuité du service, existant qui ne peut respecter les canons du modèle,
• même si le système est entièrement neuf, il est irréaliste d'ignorer les multiples composants logiciel, ou ERP, ou services, utilisables,
• enfin, le problème ne se réduit pas à la création du futur système, il faut aussi en assurer la montée en puissance, et la conduite du changement, phases transitoires cruciales qui ne rentrent pas non plus dans le modèle.

Ces contraintes pratiques, ignorées par l'axiomatique de l'Architecture de Systèmes, annulent la portée d'une vision conceptuelle pourtant remarquable.

L'illusion des modèles

Tous les grands cabinets, gourous et grands prophètes de notre époque, nous abreuvent de constats et de prévisions sur les ruptures historiques. L'époque change. mais ces mêmes prophètes nous prescrivent les outils du passé.

Le dénominateur commun des recettes miracle, mentionnées ci-dessus, passe par des modèles, des plans d'ingénierie représentant ce monde futur. Une illusion de maîtrise d'une réalité infiniment complexe.

Le modèle est, en soi, utile, praticable dans un cas simple : celui d'un ensemble d'information cerné, stable, non ambiguë, de processus invariants, d'interactions habituelles, d'une industrie opérationnelle, de procédures réglementées, ... Mais dans un système plus vaste, et en transformation, la dynamique imprévisible multiplie les aléas, et rend tout plan obsolète le lendemain de sa création.

Car on applique la recette miracle du modèle à un champ infini, insaisissable, où le recours à cet artifice est totalement illusoire.

Doit-on pour autant se passer de tout effort de conception, de tout modèle, de toute exigence de qualité, par exemple en absorbant toute donnée disponible et la déposant sans détour dans un Data Lake ? Ceci serait une autre illusion, sacrifiant à la mode du Big Data, passant d'un excès à l'autre.

Une modélisation minimaliste du cœur de l'Architecture

Arrêtons ces illusions, levons le malentendu : l'enjeux est simplement d'appliquer l'effort de conception, et une modélisation minimaliste, sur la clé de voûte de l'Architecture, sans se perdre dans la mouvance de tout le système et ses infinies variantes.

Voilà bien le changement de paradigme de l'Architecture Flexible, une Architecture "tolérante" avec toutes les solutions, tous les existants. mais une Architecture exigeante pour le périmètre très restreint de sa clé de voûte, de sa pierre angulaire, le cœur de l'Architecture d'ensemble. Ce cœur est constitué par un système d'intégration taillé sur mesure. Un système conçu pour intégrer et donner toutes les flexibilités, comme cela a été précédemment exposé sur ce blog. Un système basé sur un modèle réduit et stable, reprenant les invariants de chaînes de valeur.

Ainsi cette Architecture minimaliste devient-elle pragmatique, réaliste, et opérante, parce que son périmètre est réduit à l'essentiel, et ignore le subsidiaire.

La rigidité est la norme, la flexibilité l'exception

Sur ce site, nous avons à plusieurs reprises vanté les avantages de l'Architecture Flexible.
Plus récemment, dès lors que l'émergence d'une architecture du SI réellement flexible est acquise, ce qui commence à être admis, nous avons proposé de conduire les projets SI de façon flexible, ...C'est le concept de "Projet Flexible".

En somme, une approche pour affronter les défis de complexité des projets, un fil pour dévider la pelote de laine.

Le fil pour dénouer la complexité

Cela découle d'une réflexion simple :

• la flexibilité de l'Architecture est précieuse : elle rend celle-ci plus durable, en permettant les adaptations aux évolutions qui s'imposeront, sur tous les plans, du Business, aux processus, aux fonctions du SI, et à l'architecture technologique,
• mais cette flexibilité est aussi un atout pour le Projet, en permettant une approche progressive, sans Big Bang, ménageant des phases d'appropriation avec leur propre rythme. Un projet où chaque étape est validation concrète, grâce à la création de l'Architecture dès le début du projet.

La durée de vie du système sera accrue, et sa gestation mieux contrôlée car progressive et adaptative.

On pourrait croire que cet usage récurrent du mot "flexible" sacrifie à la mode de l'agilité... et que cela n'est que paroles !

La rigidité est naturelle

De fait, il ne suffit pas de dire "flexibilité". Au contraire, la flexibilité doit être voulue : la rigidité est la norme, elle se crée naturellement sans effort.

Rigidité de l'architecture

Prenons le cas de l'Architecture du SI. Le plus souvent on dressera un magnifique schéma rationnel qui sous-tend le futur système... On créera une vision cible, un partage du territoire fonctionnel, des quartiers, des zones, bref un classement sensé être immuable : n'est-ce pas déjà rigidité ?

On adossera cette architecture dite "fonctionnelle" sur une architecture des données. Par exemple, du temps de la période de la modélisation à tout propos, symbolisée par le langage universel de modélisation (UML), le modèle dominant pour les données est le modèle relationnel. Dès lors que ce modèle, adapté aux besoins des systèmes opérationnels, ne permet pas de multiplier les axes d'analyse pour les besoins décisionnels, on invente de nouveaux modèles, et on organise les norias de données entre les SI opérationnels et les SI de la Business Intelligence.

Le résultat de cette histoire prend la forme de silos de données opérationnelles, plus ou moins cloisonnés, partageant les données de référence avec plus ou moins de bonheur par rapport aux canons de beauté de la gestion des référentiels de donnée (Master Data Management). Et la Business Intelligence, un peu plus transversale, n'en est pas moins balkanisée en ODS, Datamart ...

Bien sûr, ces territoires de systèmes perdurent encore, et sont progressivement institutionnalisés par la Gouvernance. Celle-ci, partant de bons principes, génère aussi sa propre rigidité : compromis créés à force de frictions internes, inertie structurelle, modes d'organisation surannés, empilements hiérarchiques, se cristallisent en tables de lois, frontières inamovibles.

L'histoire de ces rigidités héritées ne s'arrête pas à la porte de notre époque, nous y contribuons encore :

• de nouvelles exigences de transversalité apparaissent, par exemple avec la réglementation sur les données personnelles, et sur l'Open Data : il faut à nouveau dédier une "architecture" spécifique, maillée avec celle du "Legacy".
• la possibilité d'exploiter des masses considérables de données accumulées en interne (les "logs") ou externe (réseaux sociaux...) crée de nouveaux territoires de "Big Data", nouvelle province, en ajout à l'existant, et faiblement intégrée à cet ancien monde.

Bien sûr, à chaque étape, ses progrès : en puissance d'analyse sur un monde infini de données, en agilité de développement, en chute vertigineuse des coûts matériels, en flexibilité des solutions, au recours extensif à l'Open Source, à l'économie collaborative.

Des ruptures tonitruantes, mais aussi des révolutions silencieuses. Par exemple, réaliser, sans entrer dans les affres du Big Data et de l'explosion de ses multiples déclinaisons, sans détour, sans data scientist, et en "libre service" : des visions de données simples, pour des tableaux de bord, des indicateurs,  des tableaux croisés dynamiques, sur tout type de jeu de données.

Sur ce chemin s'écrira immanquablement une histoire de déconvenues, de choix malheureux de tel ou tel plateforme reléguée par une vente au plus offrant, par les aléas de toutes sortes, ... Ces scories seront durables. Qui se souvient du système "Pick" qui avait tout pour plaire, avec sa base flexible et son langage d'interrogation "naturel" ? Et combien de conversions vers Unix, quand le produit fut passé de mode ? Pourtant, dans l'univers de la fondation Apache resurgissent des principes proches, et le présent bouillon de culture aura aussi ses laissés pour compte.

L'Architecture résulte toujours d'une histoire, en partie subie, et ses contraintes globales, ses rigidités fondamentales, s'imposent naturellement.

Rigidité des projets

Certes, à notre époque, on sait mener des développements en mode agile. certes on sait travailler en mode collaboratif, mener des "hackathon" pour mettre des équipes créatives en compétition.

Mais soyons réalistes :

• peut-on mener toutes les transformations selon ces recettes ?
• et, en pratique, la culture d'entreprise, les pratiques, les méthodologies, le management, la gouvernance vont-ils dans ce sens de l'agilité ?

Prenons simplement un axe d'analyse, parmi tant d'autres relevant de la sociologie des organisations : les prescriptions méthodologiques. C'est un thème mainte fois développé ici au sujet de l'Architecture d'Entreprise, et un sujet d'étonnement : comment peut-on raisonnablement croire que la "certification" d'architectes d'entreprise apporte une quelconque sécurité de conception des SI à notre époque !

Qu'en est-il de la méthodologie de projet ? D'abord le volet "gouvernance" avec l'institution de la dichotomie "maître d'ouvrage" et "maître d'oeuvre". Certes dans un projet complexe, il y a une dimension métier et une dimension SI. Mais doit-on être aussi rigide dans cette dialectique ?

Puis il en va bien sûr de la une gestion de projet, basée sur une méthode. En soit, la méthode n'est pas mauvaise, elle procède de bonnes intentions de gestion, de prévision, d'optimisation. Mais, la méthode, qui sécurise les acteurs, renforce la tradition : les exemples d'application de la méthode sont ceux de projets classiques, menés en mode "rigide", avec une prévision rationnelle, un ordonnancement cohérent... mais on en connait les extraordinaires contre-performances, comme nous l'avons pointé dans le message précédent.

Pire, dans un contexte naturellement conservateur, tout promoteur de changement a la charge de la preuve, et ne sera pas reconnu en cas de succès. Mais celui qui ne prend aucun risque, en respectant la tradition, n'aura pas la responsabilité de l'échec : l'échec est collectif (cf. la gouvernance par consensus et compromis), et, bien souvent, le projet a été porté par le "drapeau" d'un grand cabinet. Ainsi la rigidité du concept, le paradigme projet perdure.

Bref, la rigidité est la norme, et la flexibilité l'exception.

"Penser" la flexibilité 

Revenons au propos initial : la flexibilité n'est pas un sujet trivial, on aurait tors de rester au niveau du discours.

La flexibilité doit être voulue, pensée, méritée :

• flexibilité de l'Architecture, dont nous avons exploré les différentes dimensions, et pour les quelles les données sont des leviers,
• flexibilité du Projet, pour en réduire les risques, et maximiser l'apport de valeur au plus tôt.

Une flexibilité globale, qui n'est pas de l'ordre du détail, mais concerne les grands composants, les chantiers majeurs.

L'ingénierie de la flexibilité est émergente.

Nous devons la décliner sur 2 plans distincts, celui de l'Architecture, avec ses figures de style, et celui des projets avec leurs scénarios de maîtrise des aléas.

Trouver l'équilibre au plus haut

Le "Projet Flexible" : la fin des grands projets SI risqués

On sait depuis longtemps que les risques d'échec des projets informatiques sont importants. On sait que ces risques s'accroissent en fonction de la taille du projet.
Voir à ce sujet l'excellent article de Frédéric Charles sur Pulse.

Dessin de FIX expert en projets

Et pourtant on continue de mener des projets complexes.
Certes les entreprises et organisations évitent les grands projets. Elles privilégient des développements agiles, et incrémentaux. Cela suffit-il pour créer, au fil du temps, un patrimoine SI harmonieux ? L'obsolescence existera toujours, et, combinée aux exigences des nouveaux espaces qui attirent le business, des projets d'envergure demeurent incontournables.

Une approche traditionnelle rationnelle mais risquée

Il est temps d'envisager de mener ces projets complexes selon une approche différente. La complexité ne se réduira pas d'elle même, Dans un récent article paru dans la revue Génie Logiciel (N° 117 juin 2016), j'ai proposé une explication de cette complexification "naturelle".

On pourrait penser que les développements agiles, que l'abandon du cycle en cascade, que DevOps, sont le remède pour maîtriser les aléas des projets, et réduire la sinistralité. Certes, mais les erreurs, les surprises, ne se situent pas seulement dans le codage, qui est de l'ordre du détail, mais dans l'Architecture du SI. Elles impactent l'assemblage de grands ensembles de codes et de données, avec des effets imprévus perturbants, parfois catastrophiques.

L'approche traditionnelle définit cette architecture qui fonde les développements à engager. Le projet SI en découle, avec ses contraintes de dépendance et ses phases d'intégration, ses tests.

C'est l'ambition de prévoir la décomposition en sous-ensembles fonctionnels, les fameux "building blocks", optimale, calquée sur un puzzle fonctionnel qui sert de maître à penser.

La gestion de projet répartit, ordonnance les travaux et ressources ... en se basant sur cette conception immuable. Une parfaite ingénierie, fondée sur un jeu d'hypothèses objectives : évolution du Business, contraintes réglementaires, bases technologiques, organisation du travail, processus, engagement client, ...

Comment, avec une telle ambition de tout prévoir et ordonnancer, ne pas se tromper ? Il est naturel qu'il y ait des changements, et les aléas sont inévitables. En somme, s'engager dans un projet, c'est entrer dans un labyrinthe dont on croit avoir le plan. Mais, en chemin, les faits se vengent, bousculent le plan, les impasses se révèlent.

Ces changements sont d'autant plus perturbants que le projet est complexe. La combinatoire entre les multiples imprévues est infinie. Tout au plus pourrait-on mettre en équation les probabilités composées qui expliquent les risques pris dans l'architecture traditionnelle de grand projet.

Le projet flexible : refonder l'approche des projets complexes

Les risques projet majeurs sont imputables aux risques portés par l'architecture et par les intégrations induites. Ils ne sont pas localisés en un seul composant, mais dans la propagation systémique, allant jusqu'aux fatals effets domino.

L'architecture traditionnelle repose sur les intégrations donnant assez peu de degrés de liberté. Certes l'intégration par API est plus souple. Elle ne réduit pas la complexité, qui se cache encore sous cet habit de modernité. Le syndrome du "plat de spaghetti", version API, menace.

L'architecture flexible fait éclater ce modèle, et systématise la flexibilité des intégrations. Elle constitue une épine dorsale fondée sur les invariants des chaînes de valeur, naturellement "anti-sismique". Les combinaisons peuvent être testées dès que le cas se présente, à temps pour prévenir les incidents, et avant toute décision sans retour dans un cycle de développement, fût-il agile, dans une conduite du changement, dans un plan de communication.

Ceci a 3 conséquences :

• réduire les aléas, car les "joints de dilatation" mis en place encaissent de nombreuses surprises, l'architecture n'en est pas remise en cause, et il n'y a pas de propagation systémique
• simplifier les dépendances entre travaux de développement de logiciel, ceux-ci pouvant être parallélisés ou différés en fonction des urgences ou opportunités,
• prolonger la durée de vie des applications actuelles, qui peuvent être connectées aux nouveaux composants, sans intrusion, rapidement et à peu de frais. Réduisant d'autant la taille du projet.

C'est une approche en rupture avec la tradition. Nous l'appellerons l'approche "projet flexible". Profitant de l'architecture flexible, le projet pourra différer des choix, éviter de les figer a priori, de spécifier, s'adaptant ainsi, au fil de l'eau, aux évolutions apparues, ou incidents constatés.

Engageant en amont les POC de démonstration et de validation, le projet flexible crée la plateforme de base, le "Data Hub", avant les travaux lourds de développement, de conduite du changement. Le projet flexible complète ainsi les nouvelles approches, agiles, ou DevOps, qui ne portent pas sur le plan de l'Architecture. Agnostique par rapport aux choix technologiques, le projet s'adaptera à tous les contextes techniques.

Changement de paradigme projet

Belle promesse diront les sceptiques. Oui, mais sous condition ! En effet, tout l'avantage découle du "Data Hub" qui est au cœur de l'architecture flexible.

La conception du Data Hub est l'équivalent de la conception de l'architecture dont il était question ci-dessus. La nuance est que cette architecture devient concrète, préexistante, testée, démontrée, au point qu'elle valide ses bases architecturales, sur toutes les "couches" habituelles, du Business, au métier, aux processus, aux SI.

C'est un changement de paradigme projet :

• l'intégration devient le premier travail, avant les développements,
• l'ordonnancement projet est moins piloté par les pré-requis SI, et les dépendances entre composants SI, et prend en compte d'autres rigidités,
• les choix de solutions alternatives, au niveau SI, sont ouverts.

Un projet global calé sur les facteurs sociaux et humains

Les contraintes dues au SI étant diminuées, le projet est plus fluide, avec la possibilité de produire des résultats plus facilement, plus rapidement, de façon diversifiée et plus fiable. En somme, l'inertie de la composante SI du projet est réduite.

Cependant le projet comprend en général d'autres composantes : processus, métier, façade client, industrie, logistique. Le changement de chaque composante  a ses caractéristiques propres, son inertie, son temps de cycle.

L’allègement de l'inertie SI permet de repenser le projet global, en le calant sur les facteurs sociaux et humains, sur les contraintes industrielles. La flexibilité permet aussi d'éclater le projet global en autant de sous-projets qu'il y a de segments clients, ou de zones géographiques, ou toute autre classification pertinente pour constituer des variantes adaptées au contexte.

La flexibilité de l'Architecture ouvre une perspective enthousiasmante de flexibilité du projet, pour minimiser les risques techniques et sociaux, et maximiser l'acceptation et le retour sur investissement au plus tôt.

Le projet flexible : la fin des projets tunnel, des mega-projets d'intégration, des grands projets voués à l'échec et dont on n'ose parler.

Les trésors des "Puits d'événements"

Le monde est devenu "Data Centric", c'est un fait. La civilisation découvre, par delà l'automatisation qu'elle a connue, l'omni présence des données crées à cette occasion, et surtout des avalanches d'informations disponibles qui retracent les comportements des prospects, des clients, les "chat" sur les réseaux sociaux, les "logs", les moindres frémissements des objets connectés.

De nouvelles promesses apparaissent autour des Big Data, du marketing prédictif et autres machines learning. Un nouveau monde avec de nouveaux modèles d'affaire et une émergence technologique foisonnante.

Pour autant, l'ancien monde, celui du patrimoine d'applications existantes, reste au centre du SI opérationnel dans la majorité des cas. Surtout, il rythme les processus, se colle à la réglementation, à l'organisation qui structure encore la masse des emplois.

Le grand écart

Les entreprises et organisations voudraient tirer le meilleur de ces deux mondes, avec la nouvelle intelligence que procurent les "Data Lab", et en préservant l'acquis du SI existant.

On peut voir entre ces deux mondes une rupture de méthode, d'outils de développement, voire une rupture dans les modèles même de représentation des données, avec l'alternative SQL-NoSQL.

On peut voir aussi d'une part le fameux cycle en cascade qui a présidé aux développements selon l'ancienne école du Génie Logiciel, et d'autre part les démarches agiles, incrémentales.

Il y a bien, sur tous ces aspects, deux mondes de l'IT, avec un écart qui ne cesse de se creuser.

Le cas de l'architecture du SI

Le clivage se retrouve aussi au niveau plus global de l'Architecture du SI.

L'ancienne école avait l'ambition de déployer des niveaux de modélisation depuis le Business, jusqu'aux couches techniques. Cette approche demeure majoritaire dans les grandes structures, car opérationnelle pour le SI existant, et surtout maintenant intégrée à la culture d'Entreprise et aux cursus professionnels. Une représentation simple et efficace s'est imposée pour la "couche fonctionnelle", fortement pratiquée en France, est celle du POS (plan d'occupation des sols, selon l'ancienne terminologie des l'urbanisme du droit des sols français), qui est une référence incontournable comme "Carte d'Etat Major" des grandes manœuvres du SI.

Dans le nouveau monde des Big Data, de l'agile, et de toute la mouvance Open Source, il ne se dégage pas encore de "Big Picture" de référence. On trouve même des débats sur les critères de classement des composants, qui divisent les experts.

Pourtant, réduire l'écart entre les deux mondes passe au premier chef par l'architecture du SI. Permettre la dynamique, la synergie entre ces mondes, est typiquement une question d'Architecture.

Le cas des données

Les données seraient l'or de notre nouvelle civilisation. Elles sont au centre d'enjeux entre les individus, les entreprises, la collectivité. Le cadre réglementaire se durcit, en même temps que les océans de données et autres Data Lake deviennent immenses, incommensurables.

La complexité galope plus vite que toutes les bonnes intentions de gouvernance et de maîtrise... vouloir faire un POS de données, une cartographie exhaustive, vouloir tout sécuriser, contrôler sera-t-il possible ?

Une telle "pensée totale" a-t-elle des chances de succès ? Est-elle praticable face au foisonnement actuel, sans en tuer l'énergie débridée ?

Le chemin innovant des "Puits d'événements"

L'approche par les Puits d'événements est en rupture avec les stratégies méthodologiques habituelles. En effet, comme dit ci-dessus, celles-ci se sont développées par niveau, et dans un classement systématique des zones ou quartiers. Elles privilégiaient la vision statique : les cartes de fonctions, de référentiels de données.

Les Puits d'événements, a contrario, sont centrés sur :

• le noyau de d'informations partagées, noyau réduit et non extensif, simple à maîtriser,
• les fondamentaux des événements du monde réel : une vision de la réalité dynamique, qui est, dans sont modèle, d'une surprenante stabilité,
• une implémentation unique depuis la vision business jusqu'aux couches techniques, ce qui évite les tentatives bureaucratiques d'architectes de tous bords, et fédère les acteurs du SI sur une même plateforme commune des noyaux du SI.

Toutes ces qualités des Puits d'événements, posent ce concept comme réponse centrale, et probablement unique, aux défis de convergence exposés ci-dessus.

Les outils de gestion des données

Le concept de "Puits d'événements" ne fait pas partie des standards du Consulting. On constate facilement dans l'avalanche de messages sur l'Architecture d'Entreprise, structurés par les diverses écoles de pensée d'Architecture certifiantes. De même au sein des sirènes du Big Data, voire des prescriptions de l'Open Data.

Cependant les approches se "modernisent", de nouveaux instruments de management, d'audit des données, avec des représentation graphiques macroscopiques, voient le jour. Ils sont mobilisables pour les fusions-acquisitions (voir par exemple).

Un nouveau champ d'expérience et d'exploration est ouvert.

Les "Puits d'événements" sont de petits repères sur ce chemin innovant, repères praticables, simples, mobilisables rapidement. Point n'est besoin d'outil sophistiqué, car, à ce niveau réduit, ils s'agit d'évidences démontrables par un POC (Proof of Concept) rapide et peu coûteux. Ce sont là les trésors des Puits de Données, pivots de l'Architecture Flexible.

Seven Principles of Enterprise Architecture

Enterprise Architecture is short of ideas

(french version)
With the break of digital Transformation, discipline of Enterprise Architecture, EA, is shaken on its bases. A questioning is more than necessity. Large consulting firms, carriers of miracle solution, are reduced to simplistic recommendations (bimodal IT) attacked by competitor gurus (see the debate), without real proposal on the bottom.
Confronted on the one hand with an immense IT heritage, and on the other hand with this multiform disruption, Enterprise, CIO, do not know by which end take the problem. One claims to see cleavages everywhere: between the IT into bimodal, between the SQL and NoSQL, between intern and external Information Systems… But, clearly, these dichotomies does not function, because the value chain do not divide thus.

Let us opt for an “Urbanistic” vision, a comprehensive view of the large heritage of IT components, and of their life cycles… all across the silos, technologies, beyond the borders of the company. And see the infinitely complex system of these components like an immense city, where the local action is vain : the city metaphor remains powerful.
Let us explore the “urbanistic” actions in the form of invariable principles , of rules to the long course.

Imperfections of the demography of the components

If we suppose that, by unit of time, a number of components is created, and an other number of components disappears, we have a population whose total volume varies. This volume is the cumulative result of these births and death of components.

In fact, components, even useless, do not disappear naturally in the course of time: their lifetime is artificially lengthened. The global population tends to increase more than necessary, it is the phenomenon of “coral reef”: new components are embedded with old components, sometimes completely useless.
In addition, the connections between components are, to some extent, erratic, redundant, contingent. It is the spaghetti effect. I called these deviations "imperfection of the algebra of composition" (see the document available on Slideshare).

In short, one can explain the dysfunctions by the “imperfect linkage” between components.

These imperfections are of several orders. By objectifying them appear easily some EA rules susceptible to correct these well known faults.

7 Principles of Enterprise Architecture

7 principles of Enterprise Architecture are suggested to correct in egg the defects which appear, in the course of time, in any system.

1.    Correction of the imperfections of temporality

Let us suppose an exchange, an interaction, unambiguous: the same fact, in the same vision, the same cycle of setting in quality, same exchanged information. It is “perfect”. But in fact this can result in exchange in terms of:

• latency (batch mode),
• desynchronization (message mode),
• synchronism (mode service or API).

Thus the exchange is imperfect, variable in its methods, dependent on fortuitous circumstances. This imperfection should be corrected, for example by using a storage to accept or restore various temporalities.
The creation of clones of the same component will be thus avoided. One will avoid perennializing the imperfections of long latencies by propagation, during successive exchanges.

2.    Imperfections of identity

Let us suppose an exchange which one believes perfect, but makes some error on identity, or a defect of synchronism,…
For example the object has changed of state, whereas this change is not known by the partners of the exchange. A checking is to be made before validating the exchange, to avoid the propagation of errors.

3.    Imperfection of genericity

Let us suppose an exchange which would seem perfect, from the point of view of the supplier, this supplier being polarized on a case, a vision silo, etc… Actually, in a more complete view, one can estimate that it is only one typical case, which, in this vision, must be included in a set of vaster cases.
One cannot let transmitting and receiving exchange in all quietude: from the global point of view, their “private” exchange would be imperfect.
This exchange is to be placed in a more general case. The community can thus have a transverse vision, at the adequate level. The generics simplifies Information System, and facilitates its transformation.

4.    Imperfection of granularity

Between 2 levels of exchange, one being located at a “macro” level and the other at the finest level, the level of the grain, the second is amply preferable. It is a fundamental rule of Enterprise Architecture.
Indeed the exchanges of aggregates are disrupted as soon as the logic of aggregation chnages. It is simpler and stable to calculate the aggregates by request, at the need time.

5.    Imperfection of publicity

Let us suppose an exchange, perfect on any criterion, but which, completely or partially, can concern a “public” IS space. It does not have to remain completely private, or under private statute using redundant publishing functions.
Publicity can be organized, with deposit contracts, and managed, under the terms of contracts of subscription.
The mutualisation of this function makes economies of scale, unimbricates the suppliers and the customers, and gives transverse knowledge.

6.    Imperfection of stability

Let us suppose a perfect exchange at a given time. However, after functional evolutions, modifications are introduced, making the exchanges impossible in the state, and implying a management of version, on the supplier and customer sides.
This creates a complexity, which one can compensate for by masking instability, the successive versions being converted into alternatives of the same one version.

7.    Imperfection of subsidiarity

In the absence of management of subsidiarity, two extreme situations possible and are unbalanced:

• To manage all the central level, by choking any management or decentralized initiative,
• Nothing to put in coherence, between autonomous spaces which do not respect any constraint.

Very often, exchanges, either completely centralized, or completely decentralized, are imperfect: they cause associations between components badly positioned, with perverse effects in the long term. For example centralization combines components of any azimuth. With unslung autonomy the inconsistencies are the rule.

Subsidiarity is declined on several axes (organisational, commercial, produced,…), requiring a comprehensive IS view of all the points of balance.

Management of subsidiarity makes it possible to fix the points of balance (for the data and the meta-data) and to create the parameters to make them evolve.

An eternal cleavage

The "city" of the components, to urbanize, is cleaved between:

• shared components, candidates with the public reference: recalling structures, identities, cycles, course,
• subsidiary components, fruits of private autonomy.

This division, copied on the value chains, is permanent. It transcends the so-called bimodal IT, the chapels of structured and of not structured model, the borders of the Company in dilution, the Internet of all things…

These 7 EA principles allows, through organisational or technical solutions, to simplify IS, to make it more economic, transformable by hybridization, and flexible device.

The urbanistic vision is essential, a realistic metaphor, allowing, in long term, to transform the IT heritage gradually, without Big Bang, or heavy methodology.

The principal effort is not any more to relate on the method miracle, or technological cleavage.

It is necessary to act, because, with interfunctionings per thousands, and exchanges intimate to IS, “laissez-faire” leads unrelentingly to the embolism.

It is necessary to put under control the interactions between the atoms of IS. One needs a “mediation” between components, applying these 7 principles. And to nip in the bud congenital complexity and rigidity.

Sept principes d'urbanisme des systèmes

L'EA orpheline d'idées

(english version)

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.

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.