Agilité et SOA : pommes et oranges ?

Publié par Vincent Crépin le jeudi 23 mai 2013 à 07:28

D’abord, il me semble utile de mentionner que dans ses fondements, le développement Agile a pour but de rendre une organisation plus…agile. Donc, en deux mots, plus apte à s’adapter facilement aux changements qu’elle rencontre. Ce principe est d’ailleurs l’un des piliers du Manifeste Agile.

Une démarche agile peut donc prendre des chemins très variés pour autant que la destination nous permette d’en arriver à une plus grande facilité de réaction de l’entreprise. Le paradigme SOA (qui est essentiellement un style architectural), par définition, permet justement de rendre une organisation mieux équipée face au changement. Avec une approche SOA on y arrive en facilitant l’intégration entre les systèmes et, surtout, en fournissant une base grandissante de fonctionnalités logicielles réutilisables et composables afin de répondre à de nouveaux besoins plus rapidement et plus uniformément. Donc, on peut dire, sans risque d’offenser quiconque, que SOA peut représenter un élément important dans une démarche Agile, et vice-versa.

Voici quand même les arguments que l’on entend le plus souvent à l’encontre de l’application de l’agilité dans une initiative SOA :

  1. SOA encourage un exercice d’architecture élaboré dès le départ (parfois appelée Big Design Up Front) tandis que l’agilité le décourage, favorisant plutôt les approches de conception émergeantes et incrémentales;
  2. SOA encourage la division des équipes selon des lignes fonctionnelles tandis que l’agilité encourage des équipes multifonctionnelles;
  3. SOA ne propose pas nécessairement une approche prescriptive pour gérer un cycle de rétroaction (feedback) et faciliter le changement des services une fois qu’ils sont construits alors que l’agilité encourage les rétroactions et les changements fréquents et ce, autant au niveau technique que fonctionnel.

L’architecture

Le point 1 réfère à une caractéristique importante de SOA. En effet, la création des services nécessite une réflexion importante dès le départ parce que ceux-ci doivent être pensés de façon à accommoder des besoins futurs qui ne sont pas nécessairement définis encore. On parle particulièrement ici du modèle canonique de l’entreprise (par exemple la notion de client). Par contre, je considère que ce n’est pas parce qu’on adhère à SOA qu’on devient subitement des devins. Pas plus qu’avec n’importe quelle autre technique en tout cas… Je pense donc que trop investir dans une réflexion en amont est une erreur.

De mon expérience avec SOA, je conclus que la création de services trop « futuristes » n’apporte pas toujours les résultats escomptés. Si elle ne fait pas attention, l’équipe risque d’entreprendre  une démarche de conception conjuguée au conditionnel et jalonnée de « si » et de « lorsque ».  Il faut plutôt, à mon avis, prendre le temps de créer un service qui soit bien découpé en sous-services ayant des responsabilités plus spécifiques. Ce sont en général ces sous-services qui possèdent le plus grand potentiel de réutilisation. En effet, plus un service possède une valeur d’affaires élevée, moins son potentiel de réutilisation est grand. Par contre, des services de moindre valeur d’affaires (comme des services d’accès aux données simples) possèdent un plus grand potentiel de réutilisation.

L’organisation des équipes

Le second point découle du fait que la création de services peut facilement se faire en groupes séparés et de façon parallèle puisque les services sont destinés à faciliter l’intégration (entre autres) et la définition et le respect du contrat assure que les cauchemars d’intégration sont minimisés. À cela je réponds qu’il n’est pas obligatoire de séparer les équipes selon des lignes fonctionnelles, même si c’est facile de le faire! Dans les projets SOA auxquels j’ai participé, nous n’avons jamais effectué cette ségrégation et je ne crois pas que notre productivité s’en est ressentie. En fait, en impliquant des gens de différents secteurs de l’organisation on bénéficie de plusieurs points de vue différents. Cela permet de s’assurer un peu plus que les services développés soient conçus de façon à répondre réellement aux besoins de toute l’organisation.

L’évolution des services

Le dernier point est un peu plus complexe à défendre…les notions de feedback et d’accueil aux changements étant centrales à l’agilité. Il est indéniablement plus difficile d’appliquer cela à SOA puisque les services peuvent être utilisés par plusieurs applications de nature fort différentes (applications web, applications mobiles, intranet, extranet, internet, etc.). Il peut effectivement paraître plus laborieux de modifier le comportement d’un service existant lorsqu’on prend en considération les impacts potentiels d’un tel changement.

Un des avantages d’une démarche itérative est de nous permettre de nous rendre compte très tôt dans le cycle de développement de la nécessité de supporter plusieurs versions d’un service et d’identifier les meilleurs façons de le faire dans le contexte de l’organisation. Il est tout aussi facile d’y arriver dans une démarche SOA qu’avec n’importe quel autre style architectural. C’est exactement ce que nous préconisons dans nos projets SOA. Une fois les services construits, déployés et utilisés, nous nous en remettons à des stratégies de gestion des versions pour faciliter l’évolution sans impacter les consommateurs de ces services.

En conclusion, je pense que l’application des principes du développement Agile à des projets SOA est une approche très sensée. Il ne faut surtout pas hésiter à créer un service rapidement pour répondre à un besoin actuel en autant qu’on prenne bien le temps de découper celui-ci en sous-services réutilisables.

blog comments powered by Disqus

0 Comments:

Post a comment

Comments have been closed for this post.