BrunoLegros.net

Ian Rogers, directeur général de Yahoo Music dit en parlant des DRM :

« Combien d’opportunités avons-nous perdues en huit ans ? [...] Je suis venu ici pour vous dire que je ne tomberai plus dans le piège. Je ne laisserai pas Yahoo dépenser encore de l’argent dans des pratiques désagréables pour l’utilisateur. »

Ca fait plaisir mais ça s’est fait un peu tout seul… Je ne suis pas sûr que manifester contre les DRM ait servi à quelque chose. Les maisons de disque ont foncé dans le mur et ont entraîné leurs partenaires crédules avec eux. le réveil est brutal mais les anti-DRM ne pourront que dire “On vous avait prévenu… mais notre action a été inutile”.

Comme vous le savez peut être, en France, un projet informatique est organisé en strates :

• Le client : Le roi, c’est lui qui a le besoin, c’est lui qui paye, c’est lui qui gueule.
• La maîtrise d’ouvrage ou MOA : Souvent confondue avec le client (à tord), c’est elle qui assure le lien entre client et MOE. Elle formalise les besoins des clients et s’assure que la solution fournie par la MOE réponde bien à ce besoin.
• La maîtrise d’oeuvre ou MOE : C’est l’entité qui réalise la solution spécifiée par la MOA qui répond au besoin du client.
• L’exploitation : En charge de l’installation et de l’exploitation de la solution en production.

En plus de ces 3 couches “classiques”, on trouve régulièrement dans les grandes entreprises françaises les couches intermédiaires :

• L’assistance à maîtrise d’ouvrage ou AMOA (parfois appelée MOA déléguée) qui se situe entre MOA et MOE
• L’assistance à maîtrise d’oeuvre ou AMOE (parfois appelée MOE déléguée) qui se situe entre MOE et Exploitation

Je n’entrerais pas ici dans le débat stérile et polémique de l’utilité de ses couches. L’important est de constater que la MOA doit au moins faire confiance à 2 voir 4 couches pour la bonne réalisation de sa solution. Ajoutez à celà que la plupart des projets français suivent un bête cycle en V non itératif et que la MOA ne peut donc “voir” le résultat de la solution qu’à la fin du cycle complet. Elle doit donc faire confiance à toutes les strates sous-jacentes pendant toute la durée du projet (souvent plusieurs mois !).

Comment alors ne pas stresser lorsqu’on fait partie de ces couches supérieures ? Lorsqu’on a finalement aucun point de contrôle intermédiaire et donc aucune maîtrise du résultat final ? Les couches supérieures sont bien dépendantes des couches inférieures et pas l’inverse.

Ceci me rappelle une petite fable sans auteur (Si vous trouvez l’auteur, faites moi signe :-)) :

Lire la suite »

Comme je le disais dans ce post, J’ai participé à un forum traitant du SOI au Palais des Congrès de Paris le 24 octobre 2006. J’ai fait un retour sur le module “Services Management” du forum à ma boîte ainsi qu’un résumé de chaque présentation. Je livre ici simplement le retour : Lire la suite »

On vend souvent la SOA en mettant en avant sa capacité à produire des services réutilisables. La réutilisation des composants est une espèce de GRAAL de l’informatique déjà promis par la programmation orientée objet. On voit bien aujourd’hui que la OOP n’a pas tenu cette promesse. Mais qui remettrait en cause les bienfaits de la OOP ? De la même manière, je pense que c’est une erreur de parler autant de réutilisabilité avec SOA pour plusieurs raisons :

• La réutilisabilité ne s’obtient qu’au bout d’un certain temps qui se mesure certainement en nombre d’années concernant SOA. En effet, pour qu’il y ait réutilisabilité il faut qu’il y ait plusieurs applications utilisant les mêmes services et celà prend du temps. Un client qui ne constate pas la réutilisabilité promise dans l’immédiat peut être frustré.
• La réutilisabilité mesurée aujourd’hui est très faible. Gartner parle de 20% de réutilisation potentielle de services, ce qui paraît déjà beaucoup.
• SOA a tellement d’autres atouts (meilleure vision des services métiers, orchestration, couplage lâche, agilité …) que parler de réutilisabilité, qui n’est qu’une infime conséquence de la mise en place d’une SOA, paraît purement marketing voire destructeur du concept.

–

Ajout du 11/11/2006

Petit clin d’oeil de Miko Matsumura sur la réutilisabilité: 100% des services sont réutilisés puisque ce ne sont que des expositions de fonctions existantes, donc déjà utilisées :p

J’ai récemment assisté à un forum sur le thème des “Infrastructures Orientées Services” ou SOI. En fait je me suis à moitié “fait avoir” parce que je pensais qu’on allait parler de SOA. Or ce n’était pas du tout le cas puisque ITIL a été seul au coeur des exposés. J’avais certes déjà entendu parler d’ITIL mais pas en ces termes.
En sortant de ce forum je me suis donc posé la question du lien entre SOA et ITIL et plus spécifiquement entre services ITIL et services SOA. Et il se trouve en effet que certains exposants ont évoqués SOA mais sans jamais s’y attarder bien longtemps. Peut être par simple effet de mode…

J’ai donc demandé autour de moi la différence et les liens éventuels entre services SOA et ITIL. Est-ce que les services SOA s’appuie sur les services ITIL ou inversement ? Est-ce que l’un est une sous-partie de l’autre ? Est-ce que ça n’a absoluement rien à voir ? Voici à peu près les questions que je me suis posé.

Ma première impression est donc que ça n’a à priori rien à voir puisque les définitions que j’ai pu tirer des deux types de service sont très différentes:

• Un service SOA est un service métier exposé à au moins 2 consommateurs (le côté réutilisabilité est mis en avant).
• Un service ITIL est un service IT mis à disposition du business (le côté qualité de service est mis en avant).

Je pense donc qu’un lien entre service ITIL et service SOA est purement marketing.