Le Monde Informatique a publié mardi un article sur les 10 causes d’échec des projets SOA, ces causes sont listées par CIO.com.

D’après CIO.com, les gens échouent :

1. Parce qu’ils n’arrivent pas à expliquer la valeur métier des SOA
2. Parce qu’ils sous-estiment l’impact des changements organisationnels
3. Parce qu’ils n’obtiennent pas de soutien haut placé
4. Parce qu’ils essaient de faire de la SOA à l’économie
5. Parce qu’ils manquent des compétences nécessaires
6. Parce qu’ils gèrent mal leur projet
7. Parce qu’ils voient la SOA comme un projet plutôt que comme une architecture
8. Parce qu’ils sous-estiment la complexité des SOA
9. Parce qu’ils ne parviennent pas à mettre en place une gouvernance SOA
10. Parce qu’ils laissent les éditeurs guider l’architecture

Ces causes d’échec peuvent être corrélés à l’analyse effectuée par le standish groupe (cf Echecs projets - Standish Group 1995), avec comme facteurs d’échec des projets :

1. Exigences et spécifications incomplètes : quelles sont les attentes d’un projet SOA (à corréler aux points 1, 7 et 10 du CIO)
2. Manque d’implication de l’utilisateur : quels impacts sur les utilisateurs et l’organisation (cf point 2 du CIO)
3. Manque de ressources (cf points 4 et 5 du CIO)
4. Attente irréalistes (non pertinent à priori sur les projets SOA)
5. Manque de soutien de la direction (cf point 3 du CIO)
6. Changements aux exigences et spécifications : à mettre en rapport sur la définition des attentes d’un projet SOA (à corréler avec les point 1, 2 et 9 du CIO)
7. Manque de planification (à corréler au point 6 du CIO)
8. Besoin périmé (non pertinent à priori sur les projets SOA)
9. Manque de management IT (à corréler aux points 7, 9 et 10 du CIO)6.2%
10. Incompétence technologique (à corréler au point 5 du CIO)

Article original ci dessous sous http://www.lemondeinformatique.fr - de Olivier Raval publié en juillet 2008

Pour quelles raisons certaines initiatives SOA conduisent-elles à des projets ratés ? La mauvaise compréhension des gens impliqués, répond Mike Kavis, journaliste de CIO.com, dans un éditorial (*CIO.com est édité par IDG, actionnaire d’IT News Info, éditeur de LeMondeInformatique.fr). Suite à une discussion par blogs interposés entre plusieurs experts du sujet, dont les analystes de Zapthink Ron Schmelzer et de Burton Group Anne Thomas Manes, Mike Kavis a listé ce qui constitue selon lui les 10 principales causes d’échec des projets d’architectures orientées services.

D’après CIO.com, les gens échouent :

1) Parce qu’ils n’arrivent pas à expliquer la valeur métier des SOA

Les projets consacrent énormément de temps, de ressources humaines et d’argent à mettre au point la meilleure architecture possible - ce qui est une bonne chose, souligne Mike Kavis. Toutefois, là où le bât blesse, c’est que généralement, cela se fait au détriment de toute discussion avec le métier. Du coup, lorsque l’architecture est prête, personne n’en veut car personne n’en comprend l’intérêt. Il faut donc, dit-il, commencer un projet en gardant en tête le besoin de répondre à des problématiques métier. Le mieux étant de présenter une « killer app », l’application qui résoudra tant de problèmes métier que les fonctionnels en redemanderont. Pour lui, le BPM (Business process management, gestion des processus métier) est sans conteste LA ’killer app’ pour les SOA.

2) Parce qu’ils sous-estiment l’impact des changements organisationnels

Les SOA impliquent souvent de vastes changements dans l’organisation des entreprises, « surtout si ces dernières n’ont pas d’architecture d’entreprise bien établie », écrit Mike Kavis. Cela génère bien sûr des incertitudes, une peur de l’inconnu, et donc une résistance au changement. A chaque niveau de l’entreprise, chacun a ses inquiétudes, et cela doit être pris en compte, au besoin en embauchant un expert de la gestion du changement.

3) Parce qu’ils n’obtiennent pas de soutien haut placé

Il est très improbable qu’une initiative SOA réussisse si elle n’est pas sponsorisée par quelqu’un de haut placé dans la hiérarchie (CEO, CIO, CTO, etc.). De fait, même les SOA peuvent se traduire en une multitude de projets. Il n’existe pas de petit projet SOA. Une initiative SOA concerne par définition plusieurs - sinon tous - départements de l’entreprise, puisqu’il s’agit de casser les silos. Il faut donc pouvoir compter sur le soutien de quelqu’un qui sera capable de contourner ou de briser les obstacles. Le mieux, écrit Mike Kavis, est de confier ce rôle à un dirigeant métier lorsque le bénéfice métier de l’initiative SOA a été clairement défini.

4) Parce qu’ils essaient de faire de la SOA à l’économie

Les projets SOA coûtent cher, il faut en être conscient. En plus des investissement technologiques dans le middleware, indique Mike Kavis, il faut prévoir les outils de gouvernance, la formation, l’aide de consultants, etc. Certaines entreprises essaient de tout faire elles-mêmes pour limiter les coûts, écrit-il, mais « à moins que vous ne soyez bardés de gens très expérimentés en SOA, se passer d’une aide extérieure afin d’économiser de l’argent vous conduira droit au désastre ».

L’éditorialiste donne, avec un certain angélisme, deux conseils dans ce cas : d’une part, présenter un projet qui, s’il est suffisamment bien argumenté, suffira à décider le financement de l’initiative, et d’autre part, recourir éventuellement à des projets Open Source pour diminuer le coût d’implémentation.

5) Parce qu’ils manquent des compétences nécessaires

Ce point est un corollaire du précédent - et reflète la culture américaine sur la mobilité dans l’emploi : souvent, par souci d’économie, l’entreprise tente de conduire des projets SOA avec des gens qui manquent d’expérience en la matière. Alors qu’elle a besoin au contraire d’experts, qu’il s’agisse d’architectes, de gens capables d’administrer les outils ou de modéliser les processus métier. Faute de pouvoir embaucher, Mike Kavis recommande de demander beaucoup d’argent dès le départ - pour ne pas donner l’impression ensuite que l’initiative SOA est un puits sans fond - à investir dans la formation des informaticiens et des responsables métier auxquels les outils de BPM sont destinés.

6) Parce qu’ils gèrent mal leur projet

Le meilleur projet SOA n’arrivera pas au bout si la gestion du projet est défaillante. Comme pour tout projet, il faut gérer les risques, faire en sorte que chacun adhère au planning, etc. Sauf que cela se fait à une échelle extrêmement grande. D’où le conseil de Mike Kavis : « Mettez votre meilleure ressource en gestion de projet sur ce projet. » Et comme on le lit dans les annonces de recrutement, ce serait un plus si « cette personne était suffisamment technique pour comprendre les SOA au niveau conceptuel ».

7) Parce qu’ils voient la SOA comme un projet plutôt que comme une architecture

Mike Kavis dénonce « la naïveté de nombreuses entreprises » qui croient que les SOA sont juste un projet comme un autre. Or, elles impliquent la collaboration de nombreux acteurs, spécialistes des ESB (Enterprise Service Bus), des interfaces utilisateurs, de la modélisation de processus, du réseau, de l’architecture des données, etc. Plutôt que de perdre du temps dans de multiples réunions, l’auteur préconise de rassembler toutes ces personnes sur un plateau ’open space’ avec moult tableaux blancs pour favoriser le travail collaboratif.

8) Parce qu’ils sous-estiment la complexité des SOA

D’un point de vue utilisateur, SOA et BPM sont d’une grande simplicité : ils font apparaître comme des applications intégrées des centaines de logiciels et services applicatifs. Vu de l’intérieur, cela représente en revanche un exercice redoutable, même pour des développeurs aguerris. Il faut donc s’attendre à ce que de nombreux obstacles se dressent sur la route, que cela vienne des produits des éditeurs qui manqueraient de maturité ou bien de l’intégration avec le système d’information existant. Dans tous les cas, prévient Mike Kavis, il faut fixer des objectifs réalistes, ne jamais oublier l’infrastructure de sécurité pour chaque sous-projet, et procéder par itérations afin de délivrer souvent de la valeur au métier.

9) Parce qu’ils ne parviennent pas à mettre en place une gouvernance SOA

Qu’on l’appelle management ou gouvernance - le terme qui effraiera le moins les équipes, ou rencontrera la meilleure adhésion - il faut mettre en place une politique de gestion globale. Tant au moment de la conception (pour faire en sorte que les développements respectent les principes architecturaux, notamment) qu’après le déploiement, pour comptabiliser les services consommés, superviser les performances, etc. Mike Kavis recommande d’investir dans une équipe dédiée, avec des outils spécifiques, qui gagnera en maturité en même temps que le reste des équipes et des projets.

10) Parce qu’ils laissent les éditeurs guider l’architecture

Mike Kavis met en garde contre ce que Ron Schmelzer qualifie de VDA (Vendor driven architecture, ou architecture guidée par le fournisseur) : « Le but du fournisseur est de vous vendre autant de choses que possible. Votre but est d’implémenter avec succès la SOA, et de procurer à votre entreprise le maximum de bénéfices avec le minimum de dépenses. Voyez-vous le conflit d’intérêts ? » Bien sûr, les fournisseurs arguent que leur acheter leur plateforme complète réduira les coûts d’intégration - ce que l’auteur conteste, puisque ces plateformes sont justement constituées de multiples produits rachetés et agrégés. Il s’agit donc ici d’une étape cruciale, qui consiste à prendre le maximum de renseignements auprès des experts et des pairs, à bien définir son besoin avant de consulter les fournisseurs, et à demander à ces derniers des preuves technologiques de ce qu’ils avancent. Il est bien évidemment tentant de s’en remettre à l’expertise d’un éditeur, mais sachant combien les projets SOA sont coûteux, et prévus pour durer des années, cette décision est l’une des plus difficiles à prendre.

PS : L’article original de Mike Kavis sur CIO.com

Plus d’informations sur les SOA : Wikipedia