Je ne cherche pas à tomber dans la critique facile de Martin Fowler qui avec des ouvrages comme Refactoring ou Uml Distilled est un “guru” du développement. Mais son dernier billet ressemble bel et bien à une pub pour sa compagnie.
En même temps je suis entièrement d’accord avec son point vue. J’y vois même un facteur important de l’échec de pas mal de projet. On ne réussit pas un projet informatique avec une équipe peu chère (car ça veut souvent dire débutant ou peu compétent). A vouloir trop réduire les coûts des projets informatiques, ils finissent par durer bien plus longtemps qu’il ne devrait et le produit final est souvent médiocre et donc peu porteur de valeur ajouté.
L’autre facteur majeur d’échec est bien entendu la difficulté qu’ont les clients à définir leurs besoins, et encore plus à les définir dans une forme qui soit exploitatable par l’équipe projet. D’où la nécessité des méthodes agiles et des processus itératifs.
Author Archives: Aurélien Pelletier
Recette pour un échec avec une SOA
Via Tim Bray
John Crupri nous explique que prendre des composants logiciels déjà existant et rajouter par dessus une couche de web services est une parfaite recette pour un échec dans la mise en place d’une architecture orientée service.
En effets ces composants n’ont certainement pas été conçus dans le cadre d’une SOA. Il y a donc peut de chance qu’ils soient atomiques, indépendents d’autres composants, et conçus avec une granunalirité les rendant réutilisables dans le cadre d’une SOA.
Bien que l’approche bottom-up (partir de l’existant pour construire une SOA) soit la plus naturelle et la plus simple. Il ne semble pas que soit la bonne approche. Il vaut mieux adopter un approche top-bottom: partir du business et aller vers la technique. Bref, l’application d’un principe qui n’est pas prêt de s’user: C’est la technique qui est au service du fonctionnel et non le contraire.
Tout celà nous rappel qu’il est nécessaire d’adopter une démarche d’urbanisation avant de ce lancer dans la mise en place d’une SOA.
Questions pour RESTafarians !
Après les architecture dé-testable voici les RESTafariens, à ne pas confondre avec les SOAPafariens 😉
Et c’est David Megginson qui pose 5 questions intéressantes. Ca commence par une définition simple de REST:
“REST in its now-broadened meaning is easy to explain: pieces of data (likely XML-encoded) sit out there on the web, and you manipulate them using HTTP’s GET, PUT. Try explaining SOAP, much less the essence of the whole WS-* family in one easy sentence like that, and you’ll see the difference.”
A lire, ainsi que les commentaires.
Architecture dé-testable
Une architecture que l’on ne peut pas facilement tester est une architecture détestable 😉
(source)
Xfront
En faisant quelques recherche concernant REST j’ai découvert xfront. Une excellente resources concernant XML, XML schema, XSLT et REST. Présentations, tutoriaux, articles… je suis loin d’avoir fait le tour mais le contenu me semble de grande qualité.
Bravo à l’auteur: Roger Costello.