Les 10 pièges de la SOA : 05 – Big Design Up Front (BDUF)

De par leur implication dans des projets SOA (Service Oriented Architecture), les consultants de Xebia vivent de belles réussites. Mais ils rencontrent aussi un certain nombre de projets qui peinent ou qui sont en échec.
Afin de partager ces expériences, nos collègues hollandais, Gero Vermaas, Viktor Grgic, Rik de Groot et Vincent Partington déroulent une série de billets présentant les 10 pièges de la mise en œuvre d’une architecture orientée services (SOA). Comme toujours dans ce genre de « classement », cette liste n’est ni exhaustive ni définitive.

Le sixième de ces pièges porte sur la pratique du Big Design Up Front (BDUF).

Comme pour le syndrome « Not Invented Here » (NIH) dont nous parlions dans le premier billet de cette série, le « Big Design Up Front » (BDUF) est quelque chose de connu dans d’autre domaines que la SOA. Toutefois, alors qu’il est généralement admis que le NIH est néfaste, les avis sont plus partagés lorsqu’il s’agit du BDUF.

Le terme BDUF se réfère à la pratique consistant à s’assurer qu’un design (une conception) est complet avant que toute mise en œuvre soit démarrée. Cette pratique est traditionnellement associée au modèle de développement logiciel en cascade (waterfall model). Les tenants de cette approche expliquent que cette pratique permet de découvrir et de résoudre la plupart des problèmes lors des phases de conception (et qu’il est plus facile de les résoudre à ce moment là). A l’opposé, les promoteurs des méthodes de développement agiles affirment que les besoins et les exigences sont amenés à évoluer au cours du cycle de développement et que la pratique d’un Big Desisgn Up Front (BDUF) ne rendra que plus difficile l’adaptation à ce changement.

Ceci n’est qu’un aperçu des problématiques liées à la pratique du BDUF. Vous trouverez plus d’arguments (pour et contre) en suivant les liens proposés dans le paragraphe précédent. Regardons de plus prêt ce que cela signifie dans le cadre de la mise en œuvre d’une architecture orientée service (SOA).

La mise en œuvre d’une SOA passe par un « programme » plutôt que par un projet

Commençons par enfoncer une porte ouverte : Les projets de mise en œuvre d’une SOA sont, en général, de larges projets.

La principale raison en est que les entreprises qui se lancent dans ces chantiers espèrent que la mise en place d’une architecture orientée service est la solution miracle qui résoudra tous les problèmes de complexité de leur SI. Par conséquent, ils ne se contenteront pas de commencer un projet SOA, mais lanceront un programme SOA. Ce programme SOA sera composé de nombreux projets qui auront chacun la charge de répondre à un sous problème particulier tel que « la définition des besoins métiers », « la conception des processus », « l’architecture technique », « le développement », etc. …

Et c’est là que le bât blesse. Les équipes en charge de la définition des besoins métiers, de la conception des processus, de l’architecture technique, ne feront que cela. Sans se soucier de la façon dont les résultats de leurs travaux seront mis en œuvres, ces équipent ne vont cesser d’enrichir leur conception. Dans le même temps, les équipes en charge de l’implémentation de cette SOA peinent à digérer, assimiler et saisir pleinement le contenu d’un tel volume de spécifications. Il se voit même des cas (où le BDUF est poussé à l’extrême) où, lors de la phase d’assimilation par les équipes de réalisation des spécifications, les équipes de conception (ayant achevé leur tâche) ont été démantelées et ne sont plus présentes.

Une démarche Top Down aboutie à une mauvaise granularité de services

D’autre part, nonobstant tous les inconvénients évidents d’un BDUF (documentation volumineuse qui n’est pas adaptable au changement), la pratique du BDUF tend à avoir un autre effet dans le cadre de la mise en œuvre d’une SOA. Cette pratique sous-tend une conception full Top Down qui a de grandes chances d’aboutir à une mauvaise granularité des services.

L’un des scénarii pouvant conduire à cet écueil est le suivant : le concepteur des processus va se concentrer sur le niveau élevé de processus (ceux réalisant le métier de l’entreprise) jusqu’à ce qu’ils sont corrects ; il va en suite décomposer ces processus sur des processus de niveau département (dans chaque métier) ; la conception se terminera au niveau des services (au plus bas de la hiérarchie).

Le résultat d’une telle approche est que l’on va se retrouver avec un service A1 ayant comme signature getCustomerAddress(String customerName) et un service C3 ayant comme signature getCustomerStreet(int customerId). Ces services auront été conçus séparément et il ne va pas être évident (voire impossible) de découvrir la similarité de ces deux services et de les fusionner en un seul, réellement réutilisable.

Une façon de prévenir ce genre de dérives est de maintenir un registre de service que les concepteurs peuvent (doivent) utiliser pour trouver les services dont ils ont besoin (ce registre n’est pas nécessairement un annuaire UDDI).

Perspectives

Pourquoi ne pas mener la mise en œuvre de SOA de façon Agile, plutôt qu’en suivant l’approche big bang traditionnellement employée ?

Agile et SOA sont, respectivement, une méthodologie et un style d’architecture visant le même objectif : Rendre les Systèmes d’Informations plus réactifs aux changements. Mais curieusement, les façons dont sont aujourd’hui abordés les SOA tendent à encourager des pratiques clairement non-agiles comme la pratique du BDUF ou la mise en place d’équipes « fonctionnelles ».

Et pourtant, les méthodes agiles peuvent profiter au SOA !

Traduction libre du billet « Top 10 SOA Pitfalls: #5 – Big Design Up Front » publié par Vincent Partington.