Publié par

Il y a 11 années -

Temps de lecture 4 minutes

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.

 

Publié par

Commentaire

6 réponses pour " Les 10 pièges de la SOA : 10 – Le syndrome « Not Invented Here » "

  1. Publié par , Il y a 11 années

    Bonjour,

    C’est bien de présenter les problèmes, mais il serait également intéressant de présenter les solutions envisagées, ainsi que leurs résultats dans le cas où elles ont été appliquées.

  2. Publié par , Il y a 11 années

    Bonjour,

    L’objet de cette série de billet n’est pas de présenter en profondeur les solutions permettant de sortir des pièges évoqués (Nous nous « contenterons » ici d’évoquer des pistes). Cette série a pour but d’identifier des pièges (ou des travers) qu’il faut avoir en tête afin d’éviter d’y tomber.

  3. Publié par , Il y a 11 années

    La liste est maintenant complète :

    Les pièges liés à l’implémentation :
         – N° 10 – Le syndrome « Not Invented Here »
         – N° 09 – Le Versioning
         – N° 08 – La sécurité

    Les pièges liés à l’architecture et au design :
         – N° 07 – Mauvaise granularité des services
         – N° 06 – La SOA ne résout pas automatiquement la complexité
         – N° 05 – Big Design Up Front (BDUF)
         – N° 04 – Mauvaise utilisation des Modèles de Données Canoniques (pivots)
         – N° 03 – Le manque de compétences

    Les pièges liés à l’organisation :
         – N° 02 – Propriété des composants et Financement au projet
         – N° 01 – Ignorer les impacts culturels

  4. Publié par , Il y a 5 années

    Heya! I understand this is kind of off-topic however I needed to ask. Does managing a well-established blog like yours take a lot of work? I’m brand new to writing a blog but I do write in my diary everyday. I’d like to start a blog so I will be able to share my own experience and thoughts online. Please let me know if you have any suggestions or tips for brand new aspiring bloggers. Appreciate it!
    2014thenorthfaceoutletstore http://www.2014thenorthfaceoutletstore.com

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.