SOA ou FOA ?

Les communications sur les architectures orientées services mêlent deux types d’approches qu'il est recommandés de dissocier : le SOA de surface et le SOA de profondeur.

Quand on nous parle de quelques dizaines de services, souvent Web Services, développés pour un système, on a affaire à du SOA de surface. Dans ces cas, le système, les applications, ne changent pas. La qualité du système n'évolue pas. Le système (ou des portions du système) est juste enrobé d'une couche de services qui en facilite l'accès. Le plus souvent, il s'agit de la technologie des Web services.

Cette approche n'est pas inutile ; elle contribue à améliorer le couplage entre des systèmes. Mais peut-on, dans ces cas, parler d'une réelle pensée architecturale ? Dans cette SOA de surface, y a-t-il seulement une visée d'architecture ? N'est-ce pas plutôt une fausse orientation d'architecture, une FOA ? D'ailleurs, cette approche est essentiellement technique et fait peu de place à la conception logique.

En tout cas, cette SOA de surface n'est sans doute pas un moyen d'améliorer la qualité globale des systèmes, de réduire la redondance interne et d'augmenter la réutilisation. Ces objectifs, si nous voulons les traiter sérieusement, exigent un effort de conception. L'art de l'architecture logique intervient ici. Les bonnes pratiques formalisées dans les procédés de conception logique de Praxeme conduisent à changer radicalement la physionomie du système, en profondeur. C'est une nécessité pour simplifier nos systèmes informatiques et les améliorer de façon significative.

Nous devons renoncer à une structuration exclusivement fonctionnaliste du système, c'est-à-dire une structuration dans laquelle le seul critère de décomposition est le domaine fonctionnel. Matériellement, la nouvelle approche :
1. stratifie le système (en isolant les ajustements organisationnels et les fondamentaux du métier) ;
2. structure le coeur du système selon le critère des domaines d'objets ;
3. radicalise le principe d'encapsulation pour concevoir des constituants autonomes, masquant leurs ressources.

Dans cet esprit, l'urbanisation de SI, l'architecture logique et la conception logique concourent à la stabilité du système. Cette stabilité s'accorde bien avec la simplicité obtenue.

C'est seulement après cette première étape que l'on peut garantir l'agilité. Des dispositifs précis assurent cette agilité:

• framework technique (ou mieux : machine virtuelle) ;
• moteur de règles ;
• solutions de MDM (gestion des méta-données ).

L'agilité n'est possible que pour un système d'abord robuste. Elle désigne la capacité du système à absorber, à moindre coût et sans violence, les variations et sollicitations diverses (changement organisationnel, ajustement des pratiques, évolution du métier, modifications géographiques, logistiques ou techniques, etc.).

Le SOA de profondeur commence, donc, par une reconception logique du système en profondeur. Le résultat immédiat de cet effort d'architecture est la stabilité du système. Les moyens de l'agilité amplifient ce résultat et assurent réellement l'agilité. Alors, on arrive à une architecture qui satisfait les attentes de l'entreprise (réactivité, ouverture, gouvernance du SI...).

Nous qualifions ce stade de "SOA étendue" (selon le mot de Pierre Bonnet).

C'est au DSI de décider quelle approche convient à ses ambitions :
1. SOA de surface pour obtenir rapidement des bénéfices d'ouverture mais sans changer la physionomie du système ni l'économie de la DSI,
2. SOA de profondeur pour améliorer radicalement la qualité du système et lui assurer la stabilité, avec des gains financiers sur le moyen terme ;
2. SOA étendue, permettant d'offrir à l'entreprise un système agile qui soutiendra spontanément ses adaptations et transformations.