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.
Salut Aurélien,
Thanks for your feedback-through-translation (et heureusement que “mind the gap” n’est pas aussi long que l’“autre billet”… 🙂 ). Interestingly, I didn’t have this association of management-by-information to functional architecture, while writing these posts. But now that you explain it… yes, it looks similar. And yet, as you know, besides functional architecture frameworks (like TMF’s eTOM), most Enterprises do not have a shared information model supporting Enterprise-wide, coarse business processes. Functional Architecture is usually happening as a business/system analysis activity within the borders of a single project, or a department. Hmm, I’ll think about it further…
merci et au revoir,
muli
In the few “SOA” projects I’ve seen, this entreprise wide functional architecture is always missing. Might be there at the start, but it is lost has the timing get shorter and shorter…
salut aurélien,
Le problème avec la technologie est que sa complexité est directement proportionnelle au temps. On n’a pas de mal à trouver des projets aujourd’hui qui ont échoué à cause de la technologie utilisée justement (pas forcément parce qu’elle était mauvaise mais parce qu’elle ne correspondait pas à l’objectif). On pourra toujours dire que c’est la faute des djeuns développeurs mais du fait de la complexité, il est nécessaire de passer encore plus de temps à apprendre le langage avant de se lancer sérieusement dans un projet, ce que souvent on omet de faire car la réalité économique veut que l’on doive produire rapidement.
Franchement qu’est ce que çà change l’exécution distante, les web services, les EJB et tout ce qui faisait la fierté de nos profs en bases de données réparties à l’université ? Depuis que je bosse dans ce métier, je n’ai pas encore vue de BD répartie parce que l’informatique est dévolue à l’informaticien et que les autres acteurs du projet se tapent complètement de la technologie. Ils veulent juste un truc convivial et qui marche. Si je présente un diagramme UML à mon client, cela ne va pas trop lui parler et il ne souhaitera pas trop entrer dans les entrailles du système. Tout ce qu’il souhaite c’est un beau powerpoint qui impacte. Faut vendre quoi …
Par ailleurs, toutes les technologies ne se valent pas et certaines proposent des fonctionnalités que d’autres n’ont pas. Un erogonome peut-il “designer” une interface de nos jours s’il ne connaît pas les technologies comme AJAX par exemple ?
Architecturer les applis, c’est bien pour se faire plaisir et quand on a du temps. Mais c’est que du temps, on en a de moins en moins au fait …
Pingback: Le weblogue de SeB
salut Balluche,
ça dépend ce que tu vois, à qui tu parles,etc.
Jusqu’à récemment je n’avais pas vu un projet qui nécessitait les ejb, les bases réparties, les questions de flux de données, tout ça. Mais maintenant que j’en vois un de près je fais moins le malin et suis bien content que d’autres ont pensé à tout ça et y pensent. Depuis, je regarde les systèmes d’information aujrement. Imagine un distributeur de billets sans système distribué fiable, sans duplication de données, sans une analyse sérieuse des flux de données…
Aussi, il ne faut aussi pas confondre l’appli – qui marche – et l’ensemble d’applis – qui marchent ensemble.
Autre chose, si beaucoup de projets ont souffert ou souffrent de trop de technos, j’en connais peu qui souffrent de trop d’architecturage. Enfin… ça coûte cher, ça peut peut-être ralentir? mais ça vaut le coup. En revanche un projet mal pensé, tu peux le mettre à la poubelle directement.
Pour sur, sur un projet strut savec une pauv’ base, tu ne gagnes pas grand chose. Sauf avec le diagramme de classe. Mais si tu as deux, trois sources de données, des flux synchrones/asynchrones, des problèmes de réseau..
Le problème n’est pas que tu as pas le temps c’est que tu as des dead-line qui implique trop, et trop tôt. Parce que l’architecturage de ton projet -enfin… un minimum de jus de crâne, quoi – au début coûte du temps mais après en rapporte. Normalement. Enfin, je crois… Au moins sur les phases suivantes où tu écris des dossiers, des specs des machins comme ça. Même le code, architecturé, est beaucoup plus rapide à écrire.
Pingback: J2EE vs .net at Aurélien Pelletier’s Weblog
Pingback: " L" par Le weblogue de SeB