Published by

Il y a 12 ans -

Temps de lecture 8 minutes

Les 10 pièges de la SOA : 03 – Le manque de compétences

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 huitième de ces pièges porte sur le manque de compétences nécessaires à la mise en œuvre d’architectures orientées service (SOA).

L’adoption de tout nouveau paradigme nécessite un ensemble de nouvelles connaissances et de l’expérience. Cette assertion est particulièrement vraie dans le cadre de la mise en œuvre d’architectures orientées service (SOA). La mise en place d’une SOA implique en effet une mutation profonde des façons de penser et de travailler. Comme pour l’agilité, il ne suffit pas d’appliquer la culture SOA lors de la définition des architectures IT ou de la réalisation d’une application, mais il faut savoir l’étendre à l’ensemble des composantes d’une entreprise.

Les gens ont l’habitude de travailler dans des environnements cloisonnés, que ce soit au niveau organisationnel ou technique. Ils sont ainsi protégés des influences et dépendances (non désirées) avec le monde extérieur. De cette façon, ils maîtrisent, dans leur zone d’influence, tous les éléments permettant d’obtenir des résultats à court terme. De leur point de vue, l’introduction des paradigmes SOA ne fait que complexifier un monde où les choses sont déjà suffisamment complexes.
C’est pourquoi, lors de la mise en œuvre d’architectures orientées service (SOA), il faut commencer à sensibiliser les acteurs le plus tôt possible afin que la mutation aboutisse et se face en douceur.

Au sein d’une entreprise, l’introduction des architectures orientées services peut passer par différents chemins :

  • Un consultant / architecte externe conseille à l’entreprise de suivre ce paradigme.
    Si ce consultant est bien avisé, il va en premier lieu concentrer ces efforts sur les cas d’utilisation métier de la SOA et analyser leur rentabilisation. Il fera comprendre par ce biais pourquoi ce style d’architecture est bénéfique pour l’entreprise. Démontrer les capacités de ROI (retour sur investissement) d’une SOA au travers de cas d’utilisation métier n’est pas une tâche aisée, mais l’effort en vaut la chandelle. Cela permet de démontrer qu’une architecture orientée services n’apporte pas de valeur en elle-même (ce que beaucoup d’entreprise ont tendance à croire). Les SOA ne sont qu’un style d’architecture. L’analyse de rentabilisation des cas d’utilisation métier d’une SOA revient à monter l’adéquation entre la réelle valeur ajoutée métier de l’entreprise et ce style architectural.
  • Un éditeur introduit un ESB (Enterprise Service Bus) qui semble fournir les fonctionnalités qui font défaut au SI et qui semble répondre à de réels besoin métier.
    Les équipes IT commencent rapidement à « s’amuser avec ce nouveau jouet ». Au fil du temps, le développement des connaissances étant principalement induit par l’outil, « jouer » devient de plus en plus difficile. Dans le même temps, les équipes hors IT se sentent exclues et finissent par voir la mise en œuvre d’une SOA comme quelque chose de purement technique. Assez curieusement, dans de nombreux cas, les équipes IT semblent contentes de leur joli gros jouet, même si elles n’arrivent pas toujours à saisir comment il leur permet de résoudre leurs problèmes.
  • Un groupe de personnes au sein de l’entreprise s’intéresse au sujet.
    Ils se documentent, lisent des livres, assistent à des cours et des conférences et finissent par être convaincu que la mise en œuvre d’une SOA va résoudre bon nombre de leurs problèmes. Ils se réunissent alors et commencent à brainstormer pour se rendre compte rapidement que cette chose que l’on nome SOA est énorme et couvre de nombreux domaines que personne n’a encore exploré. Selon eux, si vous voulez bien faire les choses, vous devez passer beaucoup de temps à penser et à définir la mise en œuvre d’une SOA. Ils agissent alors comme des chercheurs, mais sans réel plan de développement couvrant les grandes lignes de leur recherche, ses principes, les résultats attendus et les critères permettant d’admettre que la recherche est terminée.

Il n’existe pas de recette miracle pour la mise en œuvre d’une architecture orientée services (SOA). Il existe de nombreuses façons de le faire. Comme souvent, la réponse adéquate dépend, pour beaucoup, du contexte de l’entreprise : ses besoins, ses moyens, ses ambitions, son existant (organisationnel et méthodologique), …
Mais quelque soit l’approche choisie, on constate un manque de connaisses et de compétences dans plusieurs domaines :

  • L’architecture métier
    Le terme lui-même, bien qu’étant de plus en plus présent dans le monde SOA, est tout à fait nouveau pour de nombreuses entreprises. La création d’une architecture métier au sein d’une SOA signifie : dépasser les frontières des départements, intégrer la modélisation des processus métiers, concevoir un modèle de données canonique, définir les services métiers (avec le bon niveau de granularité), arbitrer sur les niveaux de sécurité à mettre en œuvre, recueillir et prendre en compte les exigences et préoccupations métiers des différentes parties et enfin penser suivant les patterns SOA.
  • L’ingénierie des exigences logicielles
    La boîte à outils du concepteur applicatif se limite souvent aux cas d’utilisations. Or, cette méthodologie n’est pas très appropriée aux environnements SOA car elle ne couvre qu’une zone très limitée. La définition des exigences qualités devient en effet de plus en plus importante du fait que la complexité des architectures SOA a un impact fort sur les performances, la disponibilité et la gestion des applications.
  • La gestion de projet
    Du point de vue d’un chef / directeur de projet, les deux composantes d’un projet sont son scope et son budget. Or, ces deux notions deviennent floues quand les commanditaires commencent à demander la construction de services génériques et la prise en compte des préoccupations d’autres projets. Les titulaires du budget sont facilement réticents à payer un supplément pour ce genre de chose.
    Un chef / directeur de projet devrait viser deux objectifs : Délivrer dans les temps et les budgets impartis les produits métier tout en garantissant que ces produits sont « prêts pour la SOA ». Ces objectifs peuvent être en conflit et un chef / directeur du projet devrait être en mesure de gérer ces conflits. Malheureusement, dans la pratique les chefs /directeurs de projet ignorent tout simplement l’aspect SOA quand les conflits se produisent.
  • L’architecture et développement logiciel
    Les architectes et développeurs logiciels ont besoins de connaissances dans de nombreux domaines techniques : patterns d’intégration, patterns SOA, ESB, BPM, stack WS-*, … Il est particulièrement difficile de trouver des spécialistes avec une expérience solide sur ces sujets.
  • Les tests
    Les équipes de test ont également besoin de comprendre la SOA et la portée exacte de celle-ci sur les tests. Le test des services indépendamment les uns des autres est relativement facile. Mais les choses se compliquent rapidement quand on en arrive aux tests de bout en bout des processus métiers, à la manipulation de transactions sur plusieurs services, au messaging asynchrone, etc. …
  • La Direction Informatique
    Un DSI qui n’a pas réellement compris ce qu’est une SOA et ce que représente sa mise en œuvre là voit un énorme et coûteux composant d’infrastructure qui va résoudre, comme par magie, les problèmes d’intégration applicative.
    Dans les grandes entreprises, il existe plusieurs responsables informatiques (un par département). La mise en place d’un middleware commun s’avère alors presque impossible, de par les problèmes de partage des responsabilités et de la propriété des composants. Dans ce cadre une solution est la création d’une cellule transverse dédiée en charge des éléments communs à tous les départements et de la coordination des efforts de ceux-ci.
  • Une attitude collaborative
    Bien que tout le monde dans l’entreprise s’accorde à dire que la collaboration est une bonne chose, chacun va d’abord protéger les intérêts de son département avant d’adresser les intérêts globaux de l’entreprise. La cause principale de cette attitude est le manque de clarté sur les avantages de la collaboration. Les gens ont tendance à n’en voir que les inconvénients, par exemple les dépendances supplémentaires.

Si une société manque de compétences (connaissances) ne serai-ce que dans un de ces domaines, l’ensemble de la mise en œuvre d’une architecture orientée service (SOA) est en danger.
Les symptômes sont de longues discussions (parfois pendant des années) dont les seuls résultats sont des documents volumineux et / ou une infrastructure middleware inutilisée. Ces discussions portant la plupart du temps, sur qui doit faire quoi et comment les responsabilités sont partagées.
Le problème fondamental est que les personnes impliquées, bien qu’elles aient de nombreuses années d’expérience, ne se rendent pas compte de leurs lacunes dans certains domaines de compétences nécessaires pour la mise en œuvre de SOA.
Embaucher des consultants expérimentés sur ces domaines pour y pallier ne résout le problème que si tout le monde participe activement au processus d’apprentissage et que ces consultants ont un rôle de coaching.
D’autre part, le manque de compétences peut être partiellement compensé en mettant l’accent sur des résultats à court terme et l’apprentissage de ses erreurs, ce qui fait partie d’un mode de pensée Agile.

 


Traduction libre du billet « Top 10 SOA Pitfalls: #3 – Missing skills » publié par Viktor Grgic.

 

Published by

Commentaire

3 réponses pour " Les 10 pièges de la SOA : 03 – Le manque de compétences "

  1. Published by , Il y a 12 ans

    Le titre est incorrect … Il manque un « de »

  2. Published by , Il y a 12 ans

    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

Laisser un commentaire

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

Nous recrutons

Être un Sapient, 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.