Après avoir pas mal traîné mes guêtres dans le monde de l'IT et de l'intergiciel (ou "middleware"), j'ai presque tout entendu sur les mérites réels ou supposés de telle ou telle architecture innovante (de Corba au "cloud computing" en passant par les serveurs d'application, la SOA, etc... et j'en passe !). Au final et à de rares exceptions près, la déception est généralement à la mesure de la grandeur que l'on prête au concept... le succès étant souvent le fait d'outsiders inattendus (TCP/IP et les protocoles de l'internet, REST, les mashups...), ayant pour trait commun une relative absence de finalité et d'organisation, qui est la marque des systèmes dont l'existence précède les usages.

Je vais donc m'essayer à jeter en vrac quelques principes et/ou "patterns" de nature à caractériser les conditions de succès ou d'échec en matière d'architecture logicielle :

1) Diviser pour régner, ou le bon usage du "micro-pattern"
Toute fonction d'un logiciel qui peut être isolée comme principe général (un parser, un système de log, un moniteur transactionnel, un framework MVC, un widget, un conteneur de composants...) doit être externalisée sous forme de composant indépendant.
Dans l'idéal, cette brique de base doit être proposée sous une licence permettant le "fork" (que ses utilisateurs cibles puissent la réutiliser et la modifier s'il le faut pour l'adapter à leurs besoins) - si l'open-source est envisagé, une licence style BSD paraît de bon aloi (la GPL peut également convenir sous certaines conditions, notamment pour bloquer ou contrôler la privatisation éventuelle du code).
Cette approche est particulièrement compatible avec les systèmes de gestion de version modernes, et notamment GIT (où le fork de projet est un concept central).
Et elle permet d'assembler des logiciels incroyablement efficaces en un minimum de temps !

2) Etre aussi neutre que possible
Ce point rejoint en partie le précédent : à savoir, un système bien conçu se contente de faire ce à quoi il sert, et n'introduit pas d'autre contrainte (la fameuse "neutralité du net", qui ne fait que transporter des paquets sans discernement, en est une bonne illustration).
Ce point est un facteur clé d'ouverture à l'innovation future (plus vous introduisez de contraintes, plus les futurs innovateurs seront empêtrés dedans). "La loi ne peut interdire que ce qui nuit à autrui", dit la Déclaration des Droits de l'Homme (que l'architecte logiciel ferait bien de lire).

3) S'appuyer sur ce qui est éprouvé
Ce point rejoint une définition désormais fameuse de la stabilité d'un composant (est stable ce qui est utilisé fréquemment), et vient l'élargir (à d'autres domaines comme la montée en charge, la performance, la sécurité, etc...)
Pour un architecte logiciel, çà peut être très pragmatique : les "file system", bases de données, serveurs d'application, machines virtuelles... les plus utilisés ont tellement été optimisés à travers les âges qu'il devient quasiment impossible de les battre sur leur terrain.
Autrement dit, l'utilisation basique de ces systèmes a toute chance d'être préférable à la plus intelligente des constructions architecturales. Tant pis pour le côté glamour ou l'orgueil de l'architecte !

4) Détruire presque autant de code qu'on en produit
Autrement dit, moins j'ai de code, mieux je me porte : refactoring permanent (tant pis si vous jetez 3 semaines de boulot parce que vous avez inventé plus simple, au contraire !), et tout faire pour ne pas accumuler de "dette technique" (coder "avec les pieds" en se disant qu'on améliorera çà plus tard est une très mauvaise idée, largement pire que ne pas coder du tout).

5) Aller vite par cycles courts + feedback
Développez quelque chose, mettez-le à disposition, et réparez ce qui ne marche pas (ou laissez les autres le réparer s'ils vont plus vite). C'est vieux comme le monde, même si les méthodes "agiles" (scrum et autres XP) se la jouent moderne. Et çà a toujours fonctionné !

6) L'intéropérabilité n'existe pas, mais l'intelligence ambiante, si !
Ou "de la supériorité du mashup sur tout autre mode d'intégration" (n'allez jamais croire en la moindre technologie d' "interopérabilité" : on la promet depuis qu'on a inventé l'ordinateur à lampes).
Imaginez que quelqu'un veuille réutiliser un composant ou un service que vous fournissez : il devra au préalable comprendre votre métier (sinon il le réutilisera de travers). Ensuite, il saura bien s'adapter aux interfaces, APIs et autres documentations que vous lui fournirez, afin d'intégrer son système au votre. Inutile, donc, de vouloir imposer tel ou tel standard : fournissez une interface proche du métier, documentez-là, et faites confiance à l'intelligence de ceux qui en feront usage (ou des systèmes qu'ils développent).
Au pire, fournissez simplement les données, et que les usagers fassent avec !
C'est la force des APIs de "mashup" fournies par les Facebook, Google Maps, etc..., voire de l'"open-data" : on se débrouille bien mieux avec çà qu'avec tout système auto-descriptif prétendument "standard".

7) Faire confiance à l'humain
Coder, c'est créer. Les langages de programmation ou les protocoles d'intégration sont des grammaires et des syntaxes, comme les langues ou les systèmes formels mathématiques.
Ici aussi, il est question de style et d'élégance : comme pour un écrivain ou un mathématicien. Donc, inutile d'édicter des règles de pseudo-"qualité logicielle" contrôlées par force métriques et outils de validation (forcer Proust à écrire en alexandrins eût certainement été désastreux). Ca marche toujours moins bien qu'une gestion intelligente et attentive du bordel ambiant !

8) Coder !
Dans le futur monde connecté, celui qui ne saura pas coder ne saura ni lire, ni écrire. Vous n'avez sûrement pas besoin du dernier générateur de code à la mode avec des wizards partout, lequel a toutes chances de produire un galimatias incontrôlable. Ou si vous en avez vraiment besoin, demandez-vous 7 fois pourquoi, avant de l'utiliser !
Par contre, vous avez besoin d'une puissance d'expression qui soit la moins limitée possible : a minima, celle que fournit un langage de programmation dit "turing complet" (sinon celle que la langue fournit à la littérature). Apprenez donc à programmer, sinon vous ne saurez pas vous exprimer.

Bref, rien de neuf qui dépasse le bon sens paysan !