L’anti-pattern SOA : SAA pour Service Averse Architecture

Elizabeth Book, rédactrice en chef chez ebizQ a proposé un nouvel acronyme : SAA pour Service Averse Architecture que l’on pourrait traduire par Architecture Anti Service.

Elle définit une SAA comme :

• Une architecture élaborée sans avoir consulté les personnes amenées à l’utiliser.
• Une architecture incertaine qui ne tient pas ses promesses.
• Une architecture tellement complexe qu’elle dissuade les gens de l’utiliser
• Une architecture tellement peu sécurisée que les données qu’elle manipule sont compromises, corrompues, perdues ou volées.

En bref une architecture qui s’oppose aux services qu’elle doit rendre. L’anti-pattern SOA par excellence.

Ce nouvel acronyme a rapidement fait le tour des blogs anglophones traitant de SOA et a suscité de nombreuses réactions. Au-delà de l’acronyme qui ne devrait pas perdurer, ce micro-buzz a l’intérêt de soulever plusieurs points importants à l’heure où de plus en plus d’entreprises construisent des architectures orientées services :

• La mise en place d’une SOA est un effort qui doit être mené de façon transverse. Elle ne peut pas être traitée projet par projet. Pour réussir la mise en place d’une SOA, il faut sortir de la « culture projet ».
• La mise en place d’une SOA doit être pensée en termes de besoin métiers et pas en terme de besoins techniques : La construction d’une architecture IT devrait se baser sur la problématique métier qu’elle tend à résoudre (ou sur le(s) service(s) métier(s) qu’elle essaie de rendre).
• La mise en place d’une SOA implique une mutation profonde des façons de penser et de travailler. Comme pour l’agilité, la SOA est une culture qu’il ne suffit pas d’appliquer lors de la définition des architectures IT ou de la réalisation d’une application, mais qu’il faut savoir étendre à l’ensemble des composantes d’une organisation.

Ces points sont essentiels si l’on veut rendre un SI agile et flexible (la finalité annoncée de la SOA). L’enjeu sous-jacent est de taille : un département IT est-il, pour une entreprise, un différenciateur qui aide à faire prospérer le métier et dans lequel il faut investir ou simplement un centre de coût nécessaire qu’il faut maintenir au plus bas ?

Références (en anglais) :
[1] Service-Averse Architecture par Elizabeth Book.
[2] The current status quo: ‘service averse architectures’ par Joe McKendrick.
[3] Service Averse Architecture par Todd Biske.