Note de lecture : Convergent Architecture, par Richard Hubert

Note: 1 ; Pas convaincant et ennuyeux!

Mais pourquoi donc ai-je acheté ce bouquin? Tout simplement parce que l’excellent « enterprise patterns and MDA » y fait référence. Mais force est de constater que c’est l’échec complet. Voyons donc comment les 260 pages et les 8 chapitres de cet ouvrage pourtant estampillé « OMG press » ont pu nous amener là.

Le chapitre 1 « IT Architectural style » couvre 30 pages. Il s’agit, du moins pour les 15 premières pages d’une discussion philosophique sur la nature d’une architecture, son caractère évolutif, ses niveaux d’expression et l’équilibre entre innovation et couverture du risque. Rien de bien concret. Je ne me retrouve guère non plus dans les 4 propriétés énoncées concernant cette architecture, sujet des 15 pages suivantes :

  • Le métamodèle architectural, bref la nécessité de suivre un style prédéfinit.
  • Le cycle de vie du développement du modèle.
  • Une suite d’outils complète.
  • Une « projection technologique » formalisée.

On va même jusqu’à évoquer le template IEEE 1471-2000 pour documenter cette architecture. Bref, un chapitre qui n’a guère de sens pour moi.

Le chapitre suivant s’attaque à la roadmap de la Convergent Architecture sur une vingtaine de pages. Il s’agit du plan d’ensemble. Sans grande surprise, on apprend que celle-ci s’articule sur les 4 points énoncés précédemment. Il est juste de penser que l’on va voir ici comment ils se déclinent pour la « Convergent Architecture ». C’est bien ce qu’on y fait, mais cela reste très abstrait, même si chaque point est décomposer en plusieurs concepts. Leur description ne permet pas de se faire une idée du fonctionnement réel de l’ensemble. Ni même de ce qu’est cette Convergent Architecture, d’ailleurs. On a quand même droit à un beau tableau résumant les gain de productivité et de qualité que cette approche donne sur les 4 axes. Pour autant que l’on suive cette approche en 4 axes, bien sûr. Bref, je n’ai pas encore l’impression d’avoir mordu dans le dur.

Le dur vient peut-être au chapitre 3 : ses 18 pages sont consacrées au premier pilier, le Convergent Architecture Metamodel. Celui-ci est basé sur un modèle dit holistique s’appuyant sur 3 facettes : le « business design », le « project design » et le « system design ». Il s’agit là d’une vue conceptuelle inspirée du Convergent Engineering de David Taylor. Le couplage sémantique entre objet métier et objet IT rappelle le PIM/PSM du MDA, mais à part nous dire que c’est compliqué et évoquer un parallèle avec une « machine shop », on ne va pas loin. Le chapitre se poursuit avec d’autres concepts, évoqués plus qu’abordés le RASC (qui fait écho au concept des processeurs RISC), l’isomorphisme conceptuel et le « component metamorphosis ». Me voilà frustré de nouveau. L’espoir s’amenuise.

Le thème du chapitre 4 est le « component metamodel ». Cela semble sérieux, d’ailleurs 34 pages lui sont consacrées. Et là, en effet, on nous parle des couches architecturales (il y en a 4), avec la manière dont elles s’articulent entre elles et même la façon dont tout cela est outillé. On passe du très abstrait au tellement concret qu’il s’agit même d’une obsolescence programmée. On y parle : JSP, servlet, HTML, EJB, etc… Le « technology projection component » est un élément clé (qui n’est guère décrit) et les composants eux-mêmes ont des « personnalités » telles que « client » ou « serveur ». Nous voici rentré dans une sorte de pensée unique de l’architecture.

Le chapitre 5 aborde la question du modèle d’organisation IT. Il est long de 35 pages. Il s’articule autour de l’abstraction OPR (Organization, Process & Resource). On parle bien là d’une vue projet, d’inspiration UP, avec même une inspiration Tayloriste plus marquée encore. On parle donc de responsabilisation avec le fantasme habituel qu’en disant aux membres des équipes ce qu’ils doivent faire et comment ils devront le faire, ils se sentiront responsabilisés. Passons, voulez-vous ?

Après l’organisation, c’est au tour du processus de développement d’être abordé au chapitre 6. Ce doit être important, car on lui accorde 46 pages ! Le processus se revendique d’inspiration UP et Catalysis. J’y retrouve en effet l’aspect directif de ce dernier sur ce qu’est et la manière de concevoir un composant. Le chapitre est une suite de description de workflows et des activités attenantes :

  • IT-Environnement
  • IT-Bar Business Modeling and Requirements
  • Project Management
  • Development Environnement
  • Configuration and Change Management
  • Analyse by Design
  • Implementation (enfin)
  • Test
  • Documentation
  • Deployment

Il y a donc à la fois plus de workflows et moins de sens que dans UP !

Le chapitre 7 est dédié à »l’architectural IDE ». Je ne vais guère m’étendre là-dessus. Il s’agit de 20 pages de pub pour l’outil développé au sein de la société dans laquelle travaille l’auteur.

Les 47 pages du dernier chapitre font suite au précédent : il s’agit d’un tutoriel mettant en œuvre l’outil pour suivre la démarche. Il n’y a pas trop à lire, car il y a pour l’essentiel beaucoup de copies d’écran. Pour moi, ce chapitre met surtout en avant que la démarche est extrêmement rigide.

L’auteur « réinvente » des concepts vieux comme Hérode (comme le « 3 tiers » !), avec son propre vocabulaire, tout en se désespérant que le reste du monde n’utilise pas le sien ! Les idées et les concepts sont expliqués de façon très floue. Difficile de comprendre ainsi le propos de l’auteur. Les quelques idées originales paraissent ubuesques, comme l’intégration gestion de projet / architecture métier / architecture technique, ou la métaphore de la shopping machine. Quand à la « convergent architecture », elle semble se réduire à l’utilisation des assistants de l’outil ArcStyler, même si les explications de l’auteur à cet égard sont également vagues.

L’auteur aurait mieux fait de consacrer 100 pages à développer les concepts et l’utilisation de arc styler, plutôt que de nous fatiguer avec des concepts vides de sens. Mon conseil ? Passez votre chemin !

image

Référence complète : Convergent Architecture, Building Model-Driven J2EE Systems with UML – Richard Hubert – John Wiley & sons 2002 – ISBN: 0-471-10560-0

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s