PRATIQUES COURANTES

Nous avons tendance à oublier que les mêmes principes s’appliquent aux logiciels d’entreprise.
Les programmeurs doivent comprendre qu’ils ne produisent pas de programmes, les concepteurs de logiciels doivent comprendre qu’ils ne produisent pas de conceptions, les analystes doivent comprendre que le but de leur travail n’est pas d’analyser ; ils doivent savoir qu’ils effectuent toutes ces tâches afin d’apporter une contribution appropriée à un réseau d’applications intégrées.
Les contributions individuelles ne soutiennent pas les processus d’entreprise, mais un réseau d’applications intégré construit sur la base d’une collaboration efficace entre les applications le fait.
La communication, l’harmonisation, la coordination et l’administration de ces applications sont donc les aspects les plus importants du développement logiciel.
La qualité des applications individuelles, ainsi que la technologie et les techniques utilisées, n’ont aucune importance si le réseau d’applications dans son ensemble n’est pas satisfaisant.

Si nous voulons créer une pièce pour l’intégrer dans un puzzle, nous devons définir comment la pièce va s’intégrer dans le puzzle avant de pouvoir commencer à la créer.
Étonnamment, nous oublions trop souvent ce principe dans l’informatique d’entreprise.
Nous construisons ou achetons d’abord des solutions, puis nous demandons aux personnes chargées de l’intégration d’intégrer cette pièce dans le puzzle des solutions existantes.
Il est évident que ce n’est pas ainsi que l’on obtient un réseau d’applications de qualité.
Comme le célèbre architecte finlandais Eliel Saarinen nous l’a enseigné il y a plus d’un siècle, le secret d’une conception réussie est le suivant : “Concevez toujours une chose en la considérant dans son prochain contexte plus large – une chaise dans une pièce, une pièce dans une maison, une maison dans un environnement, un environnement dans un plan d’urbanisme“. La science de la complexité était inconnue à l’époque de Saarinen, mais la nature fractale de sa remarque est l’une des clés de la complexité.

Toute notre éducation et notre formation ont été axées sur une approche analytique : à partir d’un niveau élevé, plongez dans les détails en divisant un problème compliqué en éléments moins compliqués, en divisant ces derniers en sous-composants encore plus simples, et ainsi de suite jusqu’à ce que vos sous-problèmes deviennent triviaux à résoudre.
Nous avons inventé de jolis mots pour désigner cette approche, comme “componentization”, “implementation-hiding” et “black-box architecture”.
Nous cachons les problèmes difficiles derrière des façades simples.
C’est une approche qui, au fil du temps, a très bien fonctionné pour les systèmes mécanistes et prévisibles, et qui fonctionne encore, mais elle ne suffit plus.
Ce qui manque, c’est la manière dont nous allons faire en sorte que les sous-composants fonctionnent ensemble comme un tout : l’approche synthétique.