Par David Heinemeier Hansson, le créateur de Ruby On Rails, qui ne manque pas d’humour 😉
via ongoing
J2EE vs .net
Sujet délicat, mais Dotnetguru n’a pas eu peur de nous offrir 40 slides powepoint sur le sujet (je vous rassure ça se lit très bien avec open office). Ces slides ne donnent pas d’arguments pour ou contre l’une des deux plateformes mais sont un support pour présenter différents aspects.
La dernière slide me semble la plus intéressante:
Une spécification et plusieurs implémentations d’un côté, une seule implémentation de l’autre. Voilà qui symbolise bien la principale différence à mes yeux entre .net et J2EE: le choix.
Faire le choix de .net c’est s’éviter de nombreux autres choix par la suite.
Quel environnement de développement? Visual studio
Quel base de données? SQL serveur
Quel annuaire? Active directory
Quel serveur d’email? Exchange
Quel framework web? WebForms.
…
Les produits Microsoft sont très bien intégrés les uns avec les autres, c’est leur force. Si l’on utilise .net il serait dommage de ne pas s’appuyer sur les produit Microsoft pour en profiter pleinement. Faire le choix de .net c’est donc faire le choix des produits et technologies Microsoft. Une fois que ce choix technologique est fait vous n’avez plus à vous poser de question d’architecture, il suffit de suivre les recommandations de Microsoft. Et il ne serait sans doute pas très sage d’utiliser les produits Microsoft sans suivre les recommandations du fournisseur.
La technologie Microsoft a donc pris le pas sur vos choix d’architecture. Personnellement je suis convaincu que l’architecture doit passer avant la technologie. Ce point me parait donc très problématique.
D’autant que déléguer ses choix d’architecture à Microsoft c’est renoncer à tirer un avantage concurrentiel de son système d’information. En effet votre système d’information ne sera ni plus, ni moins performant que celui des autres client de Microsoft. Google a fait le choix stratégique d’une architecture très innovante, à l’opposé des choix de Microsoft. Ils en tirent aujourd’hui un immense avantage concurrentiel.
Si votre système d’information n’est pas stratégique, si vous ne le considérez que comme un centre de coût, le choix de .net, de l’environnement tout Microsoft, est peut-être le bon. Par contre si vous considérez que vos choix d’architecture sont stratégiques, que votre système d’information peut vous apporter un avantage concurrentiel posez vous cette question: Etes vous prêt à faire confiance à Microsoft pour faire à votre place les choix d’architecture de votre système d’information?
Les DSI bloguent
Sur le terrain le message que j’entends le plus souvent en provenance des DSI est le suivant: offshore, progiciel, le moins de développement spécifique possible, bref: la réduction des coûts.
Sur les blogs ça semble différent. Découvrez ce que pense Yves Caseau, DSI de Bouygue Telecom, sur la modélisation de l’entreprise. Ou voyez ce qu’à dire Jean-Pierre Corniou, DSI de Renaud, sur le futur des applications en entreprise… Ne manquez pas non plus le complément apporté à cette réflexion par Louis Naugès président de Microcost. Le rapprochement qu’il fait entre les mashup du “web 2.0” et l’orchestration des services dans nos fameuses SOA me plaît bien.
S* oriented architecture
Comment faire pour passer de cela:
Un système d’information en silo où les applications sont cloissonées les unes des autres et ne communiquent pas ou peu entre elles.
A ceci :
Un système d’information où les applications communiquent abondament entre elles et sont construites en réutilisant des services qui exposent les fonctions de l’entreprise.
La première question à se poser est de savoir si vous avez réellement intérêt à succomber à la mode SOA?
Rappelons qu’une architecture se choisi en fonction d’un besoin et non pas en fonction d’une mode ou des recommandations d’un vendeur de logiciels ou de matériels (voir les deux à la fois).
A quel besoin répond une architecture de style SOA?
Celui de réorganiser dans des délais court l’organisation d’une l’entreprise pour s’adapter rapidement à un environnement en perpétuelle évolution. Donc SOA n’est pas uniquement une mode mais répond bel et bien à un besoin de plus en plus répandu.
Comment SOA répond t-il à ce besoin?
La promesse SOA est le nirvana de l’informatique, notre Saint Graal à tous: la réutilisation! Des générations d’informaticiens se sont cassés les dents sur le problème. Ce coup ci serait-il le bon? Une seule certitude: Une architecture de type SOA coûte plus cher à mettre en place qu’une architecture plus traditionnelle et simple. Le ROI n’est à attendre que sur le moyen/long terme: lorsqu’une nouvelle application sera développée en s’appuyant sur des services déjà existant.
Chacun répondra à ces interrogations selon son contexte. Si vos réponses à ces questions vous confirment dans le choix d’une SOA, quelles sont les conditions du succès?
J’ai vu pas mal de projet aborder la problématique SOA d’un point de vue technique au niveau applicatif. En général on constate que ces projets ne produisent pas des services réutilisables. Pour quelles raisons?
Web services, SOAP, UDDI, EAI, WS-*… La liste des technos que l’on peut introduire sur un projet SOA est longue. En réalité HTTP + XML peuvent suffire pour faire fonctionner une architecture orienté service. Ca ne veut pas dire que les autres technos soient inutiles. Mais là aussi il faut se poser la question de leur utilité et s’assurer que l’équipe de développement les maîtrises avant de les introduire.
Ces problèmes techniques, bien que pouvant être complexes et importants, sont des détails par rapport aux problèmes organisationnels. Bien souvent on décide d’introduire une architecture SOA dans le cadre du développement d’une nouvelle application. L’objectif du projet et de répondre au besoin métier de l’application, l’architecture SOA n’est qu’un moyen. Le projet est porté, financé par une direction métier, les achats par exemple. L’objectif du responsable des achats est d’obtenir au moindre coût et dans les délais les plus courts une application qui va répondre aux besoins de son métier dont le périmètre se limite aux achats. Son objectif n’est pas de financer le développement de services qui pourront être réutilisé par son collègue des ressources humaines. Ces deux objectifs s’opposent, le résultat ne fait aucun doute, au fur et à mesure que le projet avance, que les retards s’accumulent, les principes qui font une SOA sont sacrifiés pour répondre aux impératif immédiat de l’application: adieu le plan d’urbanisation, au revoir l’indépendance des services…
Au final les services produits sont les services de l’application, pas les services de l’entreprise. Cette notion est développée dans ce billet: Intégration d’applications ou intégration ontologique ?
Au lieu d’une approche technique au niveau applicatif il faudrait mieux se concentrer sur une approche fonctionnelle au niveau de l’entreprise. C’est le rôle du(des) homme(s) en rouge sur mon deuxième schéma. Le développement des services doivent être des projets à part entière, ce sont des applications comme les autres, avec leur propre budget et leur responsable métier dont l’objectif sera de produire des services réutilisable par les autres applications. Ces responsables de services ne sont pas rattachés aux achats ou à la production, ils sont transverses à l’entreprise.
C’est à mon avis une condition indispensable pour produire des services réutilisables, ce qui reste l’objectif principale d’une SOA.
On dit souvent qu’une architecture SOA permet d’aligner le système d’information avec les métiers de l’entreprise. Cet alignement est réalisable si les services informatiques font la moitié du chemin et l’organisation de l’entreprise l’autre moitié. On tombe bien sûr tout de suite dans une problématique de conduite du changement.
A défaut d’effectuer ces changements on court le risque de se retrouver avec ce type d’architecture:
Des services qui complexifient le système sans permettre de réelle réutilisation.
A lire aussi:
Réutilisation et mode projet : la contradiction par Dominique Vauquier.
Google Reader: Share
Les plus attentifs auront remarqué du nouveau sur la droite de ce blog: une nouvelle section: “Dernières lectures en direct”. Je l’alimente en directe à partir de google reader. Tous les billets que je tag avec “blogpro” se retrouvent automatiquement ici.
C’est la nouvelle fonction “share” de google reader. A partir des tags que l’on pose, google reader génère un ou des fils Atom. Il fournit aussi un bout de code javascript qui s’insère facilement dans n’importe quel page. Mais le rendu ne me convenait pas trop. Je suis donc reparti du fil Atom que je “fetch” avec simplePie un nouveau parseur RSS/Atom en PHP tout a fait excellent. (ATTENTION c’est encore beta, il a fallu que je “patch” un peu pour qu’il lise correctement le fil ATOM de google)
Ca c’est de l’intégration d’application facile et efficace 😉
Si vous voulez connaître les derniers billets qui m’ont semblés pertinents, vous pouvez:
Suivre ce lien vers google reader
Souscrire à ce fil Atom
Regarder la colonne de droit quant vous venez sur ce blog.