Vers une informatique organique
Préambule :
Un jour à l'université, un de nos professeurs de physique arriva dans l'amphithéâtre avec un sourire malin et après avoir attendu le silence complet il déclara : « Jeunes gens, aujourd'hui nous allons prouver que Dieu n'existe pas. Et avec une certaine malice, il écrivit au tableau le second principe de la thermodynamique. En résumé, pour ceux qui seraient en loin de leurs chères études, ce principe indique que le « désordre dans un système fermé ne peut qu'augmenter avec le temps ». Ceci étant posé et démontré, il continua sa réflexion en disant : Comment peut-on imaginer un créateur tout puissant dont la créature ne ferait que se désorganiser ? En effet, ce créateur tout puissant aurait dû créer un système qui s'organise et pas l'inverse, donc ce type de créateur ne peut être envisagé pour notre monde CQFD ».
C'est alors que des étudiants lui firent remarquer qu'au contraire de ce qu'il disait, tout dans notre univers tendait vers une organisation. Les particules élémentaires forment des atomes, les atomes des molécules, les molécules des cellules, les cellules des êtres vivants et les êtres vivants eux aussi s'organisent socialement. Bien embêté le professeur dût reconnaître la justesse de cette contre-argumentation.
Vers une informatique organique :
Mais quel est donc le rapport avec l'architecture informatique, me demanderez vous ? Il est intéressant de voir comment un domaine comme développement d'application informatique ou plus généralement les technologies de l'information se rapprochent de la vie réelle et suivent grosso modo la même évolution.
Constat N°1 : Comme un système physique, une application informatique tend vers le désordre. Nous avons tous constaté qu'avec le temps une application informatique devenait de plus en plus compliquée à maintenir et à modifier. Avec le temps, la complexité de l'application augmente, sa capacité d'intégration diminue et ce, malgré tous les efforts des chefs de projets, architectes et développeurs. Cela ressemble beaucoup à l'entropie que l'on trouve dans la nature. Comme les systèmes physiques fermés, les systèmes informatiques se désorganisent. On ne peut rien y faire c'est une loi naturelle à laquelle tous les développeurs, d'hier d'aujourd'hui et de demain ont été ou seront confrontés.
Constat N°2 : Mais là aussi, comme dans la nature, les choses s'organisent malgré les principes fondamentaux.
Pour appuyer ce que je dis ici, je donne 2-3 étapes qui ont marqué l'histoire de la programmation et en forçant un peu le trait je montre une analogie entre la programmation et notre monde organique.
La première étape de l'évolution organique des applications informatiques fut l'introduction de l'encapsulation dans la programmation objet. C'était la première fois que l'on créait une séparation entre un bout de code et le reste de l'application. Je compare ceci aux premières cellules qui purent grâce à une membrane externe s'isoler de l'extérieur.
Puis les composants sont apparus, plus complexes et autonomes que les objets, ils ressemblent aux organismes multicellulaires complexes.
Jusqu'à peu, ces composants communiquaient l'un avec l'autre de façon anarchique. Mais au cours de ces dernières années, il a fallu organiser les architectures de composants, trouver des moyens standards de communication entre composants, ainsi que des règles « de bonne société ». C'est ce que l'on commence à observer avec l'apparition et standardisation des protocoles de communication. Bien que cette dernière étape soit plus sociétale que biologique, l'évolution vers une organisation copiée sur le monde réel est incontestable.
Ce phénomène est parfaitement normal me répondrez-vous, « Les chiens font des chiens et les chats des chats ». Il n'y a donc rien d'étonnant qu'une création humaine copie et s'inspire de l'organisation humaine et je pourrais qu'être entièrement d'accord avec vous. Cela vaut-il la peine d'écrire un article sur ce sujet. Oui car lorsque les choses sont dites et écrites, elles sont souvent plus claires.
Maintenant que nous sommes convaincus d'une évolution vers une organisation organique, essayons d'être un peu plus précis et donnons des exemples plus concrets en architecture montrant des similitudes entre programmation et vie de tous les jours. Voyons grâce à deux exemples, comment ce principe s'applique dans le travail d'un architecte.
Ex N°1 : Les protocoles asynchrones : Lorsque le choix d'un protocole entre deux applications est posé et qu'il est possible de choisir entre un protocole synchrone ou asynchrone nous choisissons ce dernier parce que dans une large majorité des cas, il est plus efficace, plus souple et moins consommateur en ressources. De même dans « la vie de tous les jours », les échanges asynchrones représentent 99,9 % de notre communication parce qu'ils sont beaucoup plus efficaces.
Prenons un autre exemple un peu plus pointu.
Ex N°2 : Communication push ou pull : Dans un système informatique bancaire, une première application A génère des jobs à exécuter pour d'autres applications B1 B2... Bn qui les exécuteront. La communication entre le générateur et les exécuteurs de jobs peut être de deux types soit de type « pull » (les exécuteurs demandent en permanence du travail au générateur), soit de type « push » (le générateur envoie le travail aux exécuteurs).
Comment dans « la vie de tous les jours » cela se passe-t-il ? Généralement dans une entreprise, c'est le patron qui distribue le travail et pas les ouvriers qui le viennent chercher. La règle naturelle est une communication entre patron et ouvrier de type " push ". Et bien de même, dans les systèmes informatiques, c'est aussi la solution la plus efficace. Nous sommes souvent amenés à effectuer des audits d'architecture chez nos clients pour y résoudre des problèmes de performance. Régulièrement, nous rencontrons dans ces architectures à problèmes, des architectures de type «pull » (où c'est l'employé qui va chercher son travail). Elles sont utilisées parce qu'elles sont plus simple à mettre en place et fonctionnent bien pour de faible charge. Hélas, elles sont peu efficaces et créent des points de contention en production dès que la charge de traitement croît. En migrant vers une architecture de type " push " (où c'est le patron qui distribue le travail) nous supprimons ces points de contention (bottleneck) et obtenons des gains importants en performance et scalabilité. Encore une fois (Attention ce n'est pas systématique) la «vie de tous les jours » peut nous informer sur la démarche à suivre.
De ces constatations, nous voyons que l'évolution de nos systèmes d'information vers une organisation de type organique a commencé et s'accélérera dans les années futures. Les architectures futures mettront en relation des entités de plus en plus organisées, complexes et autonomes. Et les architectes devront s'inspirer de « la vie de tous les jours », des relations entre personnes, bref de l'organisation humaine pour définir et concevoir les architectures de demain.
Pas encore d'organisation organique !
Si cette évolution des systèmes d'information semble évidente, nous regrettons que l'organisation des équipes Business et IT ne suit pas cette évolution. Elles sont encore organisées comme elles l'étaient dans les années 70-80. Les équipes sont créées autour d'un projet, elles vivent et meurent avec lui. Elles en sont responsables et s'en occupent comme à l'époque où les applications étaient indépendantes, où l'intégration et la communication avec l'extérieur étaient un travail négligeable à la charge du projet. Evidemment ce n'est plus le cas aujourd'hui.
Il y un décalage évident entre l'organisation technique et business. Ce décalage entre l'évolution des techniques et l'organisation des services informations fait courir un risque important aux entreprises. Les équipes informatiques ne sont plus capable de gérer correctement un périmètre de compétence défini sur des critères désuets. Les périmètres des différentes équipes se chevauchent et certains domaines transversaux ne sont pas correctement prise en charge.
La réorganisation des équipes informatiques vers une organisation plus organique faciliterait la mise en place des architectures de services. Le domaine de chaque équipe pourrait être corrélé avec soit un (ou plusieurs) domaine technique, soit un (ou plusieurs) domaine fonctionnel représenté par un (ou des) service.
Malheureusement, il est très difficile de faire comprendre aux exécutives le besoin de réorganisation des équipes informatiques. Le point critique de ce blocage et l'attribution des budgets aux services informatiques. Chaque service comme partout dans le monde désire avoir le budget le plus important possible. Si on limitait les attribution des équipes à un domaine technique (transversale par exemple) ou à la fourniture d'un certain nombre de services, cela réduirait considérablement leurs attributions et leur budget. Les équipes les plus importantes, les plus nombreuses en personnel, donc les plus influentes s'opposent souvent à ce type de réorganisation. Elles ont à leur tête des managers influents qui font souvent leur possible pour contrôler le maximum de domaines clefs. En conservant une attribution verticale des budgets telle qu'elle existe depuis des dizaines d'années, ils conservent voire augmentent leurs compétences et attributions, mais empêchent toute évolution vers une organisation organique des équipes informatiques. C'est donc à la direction informatique (voir la direction générale) de prendre conscience de ce problème est d'imposer cette réorganisation. Pour être honnête, peu de nos clients sont prêts à faire le pas.
Heureusement, certaines compagnies prennent des initiatives. Un de nos clients, une grande société de gestion aéroportuaire a défini récemment une nouvelle organisation avec différents types d'équipes pour répondre aux besoins d'une organisation plus complexe. Un premier type s'occupe de l'infrastructure (Bus ESB pour cas présent). Un deuxième gère l'intégration (applications legacy, partenaires internes et externes). Un troisième implémente les services métiers. Enfin un quatrième plus proche du business, s'occupe de l'orchestration de ces services. Que vaut cette organisation ? Elle ne vaut que ce que valent les hommes qui la composent, bien sûr. Mais quel que soit le résultat, il y a eu de la part de la DSI une intention réelle de faire évoluer les choses et de prendre en compte l'évolution de leur informatique vers une organisation plus complexe, ou au moins différentes de ceux qui y avaient depuis plusieurs dizaines d'années. C'est une démarche intéressante qui devra être suivie.
Conclusions.
En comparant l'évolution des applications informatiques avec l'évolution du vivant, nous avons essayé dans ce papier de montrer que notre informatique évolue vers ce que nous appelons une informatique organique où chaque entité comme les êtres du monde vivant, devient en évoluant, de plus en plus de complexe, communicant et autonome. Par conséquent, les règles d'architecture doivent suivre aussi cette évolution et s'inspirer des règles de l'organisation du vivant.
Malheureusement, cette évolution rencontrée au niveau technique, ne se retrouve que très rarement dans l'organisation des équipes business ou celles des équipes IT. L'organisation verticale définit autour des projets est encore la règle dans de très nombreuses entreprises. Comme nous l'avons dit, ceci crée une mauvaise corrélation entre les domaines de compétence attribués aux équipes informatiques et les domaines techniques ou fonctionnels qu'elles utilisent.
Une réflexion et une réorganisation importante se préparent pour les entreprises désirant rester compétitive et tête de leur secteur d'activité. Cette réflexion doit être menée d'abord par le management le business puis les services IT. Cette réorganisation doit aboutir à la prise en compte par tous ceux qui participent à l'élaboration des processus métier dans l'entreprise, que l'informatique organique est déjà présente dans nos systèmes d'information et y sera surement pour plusieurs décennies.