The curse Tim Woodman une métaphore qui décrit et explique à la perfection une situation que l’on rencontre trop souvent dans les systèmes d’information des grosses organisations.
Monthly Archives: February 2006
Architecture et technologies
L’architecture doit passer avant la technologie. Ça peut sembler évident, pourtant combien de mes interlocuteurs me parlent de technologie en premier? Combien de fois me demande t-on si je connais Websphere, Weblogic ou Tomcat… Je répond toujours oui car je connais les notions d’architectures sur lesquelles sont bâtis les serveurs d’applications.
A la fin du billet mind the gap, Muli Koppel nous détaile en quoi l’architecture est supérieure à la technologie. Je traduis et reformule un peu l’essentiel ci-dessous, mais ça ne peut remplacer la VO dont je vous recommande chaudement la lecture.
La technologie est éphémère, à la mode et populaire, elle est survalorisé. A l’opposé bien que plus résistante au temps l’architecture est sous évalué. La technologie restreint et limite le travail de l’architecte. Si l’on reste au niveau de la technologie il peut y avoir des progrès par contre les changements de paradigme sont impossibles sans passer par l’architecture: une manière abstraite et immatérielle de réfléchir aux besoins, préoccupations, pressions et identités.
Il faut donc décortiquer les nouvelles technologies pour en extraire l’architecture. C’est du point de vue de l’architecture que l’on peut comparer deux technologies et déterminer si la nouveauté est intéressante. Il a un écart entre les besoins et les technologies poussées par les vendeurs, l’architecture permet de le mesurer.
Cette différence entre architecture et technologie se conçoit et s’énonce clairement dans le monde technique. On trouve le même rapport dans le monde fonctionnel.
Dans cet autre billet Muli Koppel nous parle du concept de management par l’information: une approche Top-down qui se concentre sur les processus et l’information, plutôt que sur les outils qui sont mis en avant par les éditeurs dans le cadre d’une approche de bottom-up.
L’approche top-down basé sur l’analyse des processus et des informations correspond à l’architecture fonctionnelle. L’approche bottom-up basé sur les outils ou les applications est à rapprocher des technologies.
Gliffy
(pour une raison qui m’échape l’image s’affiche déformée dans wordpress, faire view image pour voir une bonne qualité)
Petit schéma réalisé en 2 minutes avec Gliffy qui est à Visio ce que Writely est à Word.
Bon évident ça ne remplace pas Visio pour faire un schéma d’architecture un peu complexe mais ça peut être très utile pour un brainstorming collaboratif à distance.
Au fait j’utilise depuis quelques temps Draw (OOo 2) à place de Visio et ça se passe plutôt bien. Par contre je reste frustré quand j’utilise Writer à la place de Word. Tout particulièrement à cause de l’absence de mode plan, la fenêtre navigator de Writer ne m’a pas convaincu.
Java, Php et Ruby sont dans un bateau…
Après son best seller “Better, Faster, Lighter Java” (il est dans la liste) Bruce Tate fait beaucoup parler de lui. Son interview déchaîne les passions sur theserverside.
En tout cas cette interview contient pas mal de remarques qui m’ont paru très pertinentes et synthétiques.
The problem Java grew up around solving was slapping a web UI around legacy stuff, mostly relational databases.
Si j’y réfléchi deux secondes c’est effectivement ce que je fais depuis que je travaille. Il poursuit en expliquant que java a résolu le problème d’une manière “slow & clean” alors que d’autre langage le font d’une manière “quick & dirty”, je pense à php, Tim Bray aussi.
Avec Ruby On Rails Bruce Tate pense avoir trouvé une manière “quick & clean” le meilleur des deux mondes. La preuve? Un projet java non fini au bout de 4 mois a été bouclé en une grosse semaine avec ROR. J’ai fait passer le “10 minutes test” à ROR. Les 10 minutes se sont transformée en 2 heures mais j’ai effectivement pu réaliser une appli toute bête avec un formulaire CRUD. Et l’appli et effectivement clean quelqu’un qui connaît ROR n’aura aucune difficulté à comprendre ce qu’elle fait et à la maintenir.
Ca ne veut pas dire que ROR est une solution miracle, sur certain point la plateforme java reste incomparablement meilleure. Il donne les exemples des problèmes de two-phase commit et d’intégration avec beaucoup de système legacy.
Il met ensuite le doigt sur une des faiblesses de java:
Java doesn’t express data very well. While Java can declare structures that hold data, it doesn’t express the data itself well. And, that’s a big reason we’re seeing a lot of XML being bolted on to Java frameworks
Et effectivement je code de plus en plus en xml… Mais depuis quand xml est-il un langage de programmation?? Est-ce que les annotations sont la réponse à ce problème?
Enfin il traite du problème du “design by committee”
Sometimes, the JCP seems to say ‘Find a problem. Build the standard. And, lastly, gather the experience.’ To me, that’s wrong.
C’est ce qui conduit a des specs comme EJB 1 et 2, WS-*… A l’opposé l’approche qui consiste à implémenter en premier puis à spécifier ce marche a produit par exemple Spring et Hibernate (ATTENTION on parle du processus pour créer un standard pas un application métier). C’est aussi l’approche que recommande l’IETF pour la définition des standards qui font tourner l’Internet, ça leur a plutôt réussi, non?
Valtech days
Les Valtech Days, les 16 et 17 mars à la Défense. Vu la qualité des intervenants (Thomas Gil, Sami Jaber, Craig Larman, Pascal Roques, Jean-Louis Benard, … ) et le contenu des sessions (EJB3, Spring, client riche, AOP, méthodes agiles, Industrialisation, UML, … ) , ce séminaire s’annonce comme plus riche encore que le symposium DNG . Assurément à ne pas manquer.