Les 10 pièges de la SOA : 10 – Le syndrome « Not Invented Here »

De par leur implication dans des projets SOA (Service Oriented Architecture), les consultants de Xebia vivent de belles réussites. Mais ils rencontrent aussi un certain nombre de projets qui peinent ou qui sont en échec.
Afin de partager ces expériences, nos collègues hollandais, Gero Vermaas, Viktor Grgic, Rik de Groot et Vincent Partington déroulent une série de billets présentant les 10 pièges de la mise en œuvre d’une architecture orientée services (SOA). Comme toujours dans ce genre de « classement », cette liste n’est ni exhaustive ni définitive.

Le premier de ces pièges est le syndrome « Not Invented Here » (NIH). Ce syndrome se rencontre dans bien des domaines de l’IT. Dans le cadre de la mise en œuvre d’une architecture orientée services (SOA), il se manifeste tout particulièrement à deux niveaux :

• La réutilisation de services.
• La mise en place d’un tiers d’intermédiation.

La réutilisation de services

Un des objectifs sous-tendus par la mise en œuvre d’une SOA est la réutilisation de services.
Si le département A construit un service get_personal_details (qui retourne, entre autres, l’adresse complète), il y a peu d’arguments qui plaident en faveur de la construction par le département B d’un service get_address. Il existe pourtant plusieurs raisons qui peuvent amener le département B à construire ce service :

1. Les équipes du département B n’ont pas connaissance du service get_personal_details. Cela dénote généralement l’absence d’un annuaire / registre de services (ou sa mauvaise gestion). Nous discuterons ce point dans un autre billet de cette série.
2. La façon dont le département B conçoit son application ne la pousse pas à penser réutilisation. C’est en général ce qui arrive quand on applique un « Big Design Up Front » (une démarche de conception complètement Top down). Ce point sera également discuté en détail dans un autre billet de la série.
3. Les équipes du département B ont connaissance du service get_personal_details, mais elles décident de ne pas l’utiliser. Soit parce qu’elles ne savent pas précisément ce qu’il fait (on retombe alors dans le premier cas), soit parce qu’elles ne font pas confiance au département A quant à ses capacités à réaliser ce service correctement, soit, encore, parce qu’elles préfèrent avoir un contrôle total de l’implémentation de ce service.

La troisième raison est un cas typique du syndrome NIH. Il est alors urgent de réunir les deux départements autour d’une table afin qu’ils discutent de la responsabilité de ce service et qu’ils trouvent un terrain d’entente sur lequel chacun se trouve en confiance.
Ce genre de comportement est malheureusement assez courant. Mais, c’est quelque chose qui peut, en général être réglé au cas par cas une fois que le dialogue et la confiance ont été rétablis.

La mise en place d’un tiers d’intermédiation

Le deuxième cas de figure dans lequel on rencontre le syndrome NIH lors de la mise en œuvre d’une SOA est bien plus difficile à résoudre. C’est celui qui amène une direction informatique à construire son propre bus de service (ESB). Cela peut arriver principalement de deux manières :

1. Au début des années 2000, l’intégration applicative basée sur les messages a fait émerger le besoin d’un socle de services techniques réutilisables (transport, routage, transformation, …). Ce besoin a conduit, dans de nombreuses entreprises, à la construction de frameworks de messaging maisons, le plus souvent au dessus d’un backbone de messages comme MQ Series. Ces frameworks ont rendu de fiers services par le passé, mais de par leur nature, ils sont aujourd’hui très fortement couplés aux applications qu’ils supportent (ou l’inverse), entravant ainsi l’introduction des standards ESB dans l’infrastructure du SI.
2. Au-delà de ce phénomène, aujourd’hui encore, certains écrivent leur propre ESB. En effet, bon nombre d’architectes ont l’impression que les ESB sont un produit marketing fortement poussé par les éditeurs et les voient comme quelque chose d’inutile. Cette vision des choses est un peu exagérée, et il faut avoir de très bonnes raisons (et les épaules solides) pour écrire ces propres services de transport / routing / transformation. Ce qui revient à implémenter son propre ESB !

Dans les deux cas, sortir de cette situation implique beaucoup de travail. Ces systèmes propriétaires sont au cœur des systèmes, leur suppression demandera donc beaucoup de temps.
L’acquisition d’un ESB (commercial ou open source) implique la mise en œuvre d’un plan de migration dans lequel les services devront être migrés un à un pour utiliser cet ESB plutôt que l’ancien système. Un pont devra être donc maintenu entre l’ancien système et l’ESB pour la durée de la migration. De ce fait, il est probable que le débranchement de l’ancien système ne soit pas effectif avant longtemps …

Perspectives

Avant de commencer à écrire ses propres services ou son propre bus de message, il est donc souhaitable d’étudier ce dont on dispose. Il y a de grandes chances qu’un service ou une plateforme « temporaire » reste en activité très longtemps …

Traduction libre du billet « Top 10 SOA Pitfalls: #10 – Not Invented Here syndrome » publié par Vincent Partington.