Publié par

Il y a 11 ans -

Temps de lecture 8 minutes

Les 10 pièges de la SOA : 02 – Propriété des composants et Financement au projet

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 neuvième de ces pièges porte sur le manque de clarté dans la définition de la propriété des composants et le mode de financement au projet.

Dans le monde des applications standalones, le sponsoring et la propriété des applications sont généralement clairement définis. D’autre part, chaque application est sous la responsabilité d’un directeur (chef) de projet unique. Peu importe l’échelle du système, la configuration reste la même. Dans ce cadre, le financement (la budgétisation) des projets est « simple » et facilement défendable : Il est basé sur les cas d’utilisations implémentés par l’application.
Dans le monde des SOA (Architectures Orientées Service), les choses ne sont pas aussi simples. Chaque projet ayant ces propres objectifs, les équipes sont réticentes à travailler sur des services génériques ou des composants d’entreprise (partagés). Si la propriété et le financement de ces composants ne sont pas clairement définis, il y a alors de grandes chances que rien ne soit fait à l’échelle de l’entreprise (composants communs et services réutilisables), ou que les choses soient faites de façon hétérogène (sans coordination) hors du cadre des règles d’architecture d’entreprise. En définitive, personne n’endosse la responsabilité de ces composants d’entreprise (ex. : sécurité).
La coexistence de plusieurs projets en collaboration est bien sûr tout à fait concevable, néanmoins dans le cadre de la mise en œuvre d’architectures orientées service, il convient également de mettre en place un comité de pilotage SOA ainsi qu’un centre de compétence SOA. Ces deux nouvelles entités devant être bien financées et soutenues par la direction.

Les pièges inhérents

Le manque de clarté sur la propriété des composants et le financement au projet peuvent amener aux cas de figure suivants :

  • Une myriade de projets aux intérêts distincts
    On croise dans de nombreux projets de mise œuvre d’une SOA (ou à leur périphérie) un urbaniste ou quelqu’un d’autre, qui attend que des projets distincts fournissent des services réutilisables et construit selon les préceptes d’architecture de l’entreprise. Les projets sont axés sur le métier, mais souvent, ils ne ciblent qu’un seul aspect (ou un nombre réduit d’aspects) de la stratégie métier de l’entreprise.
    Or, exposer les services d’un projet aux autres et les rendre réutilisables (plutôt que de limiter l’utilisation des fonctionnalités des services au projet lui-même) peut être conflictuel avec les intérêts métiers directs du projet (les intérêts à court terme en tout cas) : Cela exige, des équipes projet qu’elles fournissent des efforts supplémentaires.
    Les projets menés en mode cascade sont particulièrement touchés par ce problème car il est très difficile (voire impossible) de planifier les aspects réutilisabilité à l’avance.
  • Un seul grand projet SOA
    D’autres entreprises font le choix de définir un seul grand projet SOA dont l’objectif est de « fournir la SOA » plus ou moins comme un produit en tant que tel. Cette approche est plus qu’étrange, puisque la SOA est un style d’architecture et non un produit (même si certains éditeurs la vendent comme tel, clés en main).
    La définition des cas d’utilisations pour une SOA n’est pas une tâche aisée. La conséquence habituelle d’une mauvaise définition des cas d’utilisation d’une SOA est que l’architecture orientée service devient elle-même le but. Or le véritable objectif de la mise en œuvre d’une architecture orientée service est la réalisation des exigences métiers comme la réduction du time-to-market ou une meilleure réutilisabilité de l’information et de l’infrastructure IT.
  • Le tout générique
    Dans des sociétés où plusieurs projets fournissent des produits métiers en mode SOA, tout le monde parle de services génériques et nombreux sont les projets qui prétendent les construire.
    Dans la pratique, les projets construisent ces services pour eux-mêmes et ne se soucient pas vraiment de recueillir les besoins / exigences des autres projets ou des autres départements. Encore une fois, pourquoi le devraient-ils ? Cela leur demanderait des efforts significatifs, leur coûterait plus cher et induirait des risques projet supplémentaires.
  • La centralisation des services à tout prix
    La centralisation des services qui ne sont pas directement liés à un domaine particulier est une bonne pratique. Ces services sont souvent techniques (sécurité, routage de message, données de référence, …). Mais, qu’en est-il, par exemple, des services de transformation spécifiques à un domaine métier ?
    Dans les projets de mise en œuvre de SOA, il y a une tendance à la sur-centralisation. Or, la centralisation peut causer plus de problèmes qu’elle n’en résout. Elle peut mener à des problèmes qu’il devient très difficile de résoudre. Par exemple, comment les responsabilités des composants sont-elles partagées dans un modèle ultra centralisé ? Dans la plupart des cas, une responsabilité partagée finit en pas de responsabilité. La principale question est qui paye pour le développement et la maintenance.

Perspectives

La cause profonde des problèmes présentés réside dans le manque de clarté sur la propriété des composants et le mode financement au projet. Les choses peuvent vite devenir très désordonnées si tout cela n’est pas bien organisé. Voici quelques pistes pour éviter de tomber dans ces travers :

  • Créer un centre de compétence SOA
    Toute initiative SOA devrait s’accompagner de la mise en place d’un centre de compétences SOA ou d’une entité qui s’en rapproche. Eric Roch explique comment organiser ce genre de centre de compétences.
    Il s’agit d’une équipe de personnes provenant de différents domaines (spécialistes de l’intégration, développeurs, architectes, consultants) qui ont pour objectif de résoudre pro-activement les problèmes mentionnés. Cette équipe doit avoir un financement indépendant et fournir des résultats à court terme (dans le cadre d’itérations courtes). Elle ne doit pas se contenter de fournir l’infrastructure sous-jacente et un middleware. Elle est également responsable de fournir un catalogue de services génériques, réutilisables et indépendants des domaines métiers. Les services métiers (spécifiques à un domaine) seront encore livrés par les projets.
    De plus, ce centre de compétences SOA peut / doit également soutenir les projets sur plusieurs autres axes : rendre les services réutilisables, intégration au middleware, …
  • Créer un marché à l’intérieur de l’entreprise
    Les projets doivent investir sur les aspects « Entreprises ». Ces investissements peuvent être couverts par d’autres départements ou d’autres projets qui ont eux aussi besoin des services d’entreprise impliqués. Ce paiement sera généralement unique et couvrira la collecte des besoins et exigences ainsi que l’effort de développement.
  • Créer un comité de pilotage représentatif
    Les participants au comité de pilotage SOA sont des représentants de l’ensemble des départements impliqués. Ils discutent et prennent les décisions sur des sujets « d’Entreprise ». Le budget est déterminé par la direction de l’entreprise. Le comité de pilotage est également le sponsor et le titulaire du budget pour les services fournis par le centre de compétences SOA.
  • Le mode guérilla (pour les architectes)
    En dernier recours, et si les projets (départements) sont réticents à coopérer, il vous reste toujours les « tactiques de guérilla » :
         – Montez un gang d’architectes issus de l’ensemble des projets pour faire le sale boulot. Les chefs de projets ne sont souvent pas très au fait de se que font leurs architectes, cela doit donc pouvoir passer inaperçu. De cette façon, les aspects « Entreprise » sont financés par les projets sans qu’ils le sachent.
  •      – Menacez les projets avec des histoires de législation, de sécurité ou tout ce que vous pourrez imaginer pour les forcer à coopérer.

         – Accaparez-vous les composants communs (entités et services de base, logging, sécurité, …) et gardez-les en otage. De cette façon, les projets seront obligés de coopérer (sur leur propre budget) pour faire avancer ces sujets.

Pour conclure

Avoir un financement et une propriété clairement définis pour les composants de niveau « Entreprise » (sécurité, logging, messaging, transformation, services génériques, ESB, …) est crucial. Et cela ne résout pas uniquement les problèmes lors des phases de réalisation, mais surtout une fois que l’architecture orientée service est en production, c’est-à-dire quand les aspects opérationnels sont vraiment importants.

 


Traduction libre du billet « Top 10 SOA Pitfalls: #2 – Unclear ownership / Project based funding » publié par Viktor Grgic.

 

Publié par

Commentaire

1 réponses pour " Les 10 pièges de la SOA : 02 – Propriété des composants et Financement au projet "

  1. Publié par , Il y a 11 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 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.