SOA Governance: Governing Shared Services On-Premise and in the Cloud
Thomas Erl, Stephen G. Bennett, Benjamin Carlyle, Clive Gee, Robert Laird, Anne Thomas Manes, Robert Moores, Robert Schneider, Leo Shuster, Andre Tost, Chris Venable, Filippos Santas
Un livre qui sonne creux. Avec SOA Governance, je pense qu'on l'on touché le fond. Je me suis accroché jusque là pour lire les différents livres de la série. Trois ans après sa sortie, SOA Governance n'a toujours pas le moindre commentaire sur Amazon.com. Du jamais vu pour ma part sur mes lectures A croire que les autres lecteurs ont eu l'intelligence de s'arrêter avant moi...
Review
SOA Governance ou l’Art de parler pendant 500 pages pour ne rien dire… Sixième livre parmi les principaux dans la série Thomas Erl, SOA Governance s’attaque à un sujet important pour la réalisation d’une transition vers une approche SOA La mise en place de règles et de process garantissant la cohérence de l’architecture SOA.
Malheureusement, le livre n’apporte rien. Une fois n’est pas coutume dans la série, on s’ennuie et on décroche constamment. Le livre est hyper répétitif. Antoine de Saint-Exupéry disait “La perfection est atteinte, non pas lorsqu’il n’y plus rien à ajouter, mais lorsqu’il n’y plus rien à retirer”. SOA Governance est à l’opposé de la perfection…
Je m’explique. Après avoir passé en revue les quelques 11 étapes de création d’un service impliquant 15 rôles différents (et pas un de plus :), les auteurs décrivent étape par étape, les règles nécessaires, les process concernés et les rôles impliqués. La présentation est hyper découpée comme toujours (Ex il a choix possibles - le premier implique étapes première étape …, deuxième …, troisième … le second choix implique étapes première étape, …). Cette présentation n’aura réussi qu’à SOA Design Patterns.
Dans SOA Governance, les auteurs commencent par les règles. chaque règle, on discute des process et des rôles liés. Vient ensuite les process. Pour chacun d’eux, on rediscute les règles et rôles associés. On termine par les rôles où on discute à nouveau des règles et process. J’avoue que cela offre des points de vue différents mais est-ce nécessaire D’autant plus, qu’à chaque fois un schéma est inclus (ex “Le Service Architect intervient dans la rédaction du document Service Normalization” conduit à un schéma avec l’architecte et le document relié par une flèche… Pourquoi ?). Seul avantage aux schémas nombreux, le livre se lit très rapidement et quand on tombe sur un tel livre, croyez moi, c’est une vraie bouffée d’air !
Ajoutons que la description des règles et des process restent bien trop vagues. Comme toujours, les auteurs avancent que chaque entreprise est différente et qu’il faut adapter le contenu. Je veux bien l’entendre. Mais pourquoi ne pas donner un exemple tout de même car là, il n’y simplement aucun contenu à adapter !