Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

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.

La clé du succès d’une architecture orientée-service (SOA)

Publié par Vincent Crépin le vendredi 21 octobre 2011 à 20:13

Ce billet est le premier d'une série au cours de laquelle il sera question d'architectures de services et de quelle façon on peut y associer les pratiques de développement Agile pour favoriser le succès d'une telle initiative.

SOA (Services Oriented Architecture) est un paradigme qui devient de plus en plus répandu depuis quelques années. Les raisons qui expliquent cet engouement sont nombreuses. Parmi celles-ci, en voici quelques-unes des plus importantes :

  • Simplicité du concept : le principe de base d'une architecture orientée services est très simple à comprendre.
  • Potentiel réel de réutilisation : le fait de découper et d'implémenter un système en services permet réellement de réutiliser des fonctionnalités de celui-ci à partir d'autres systèmes et à l'intérieur même de celui-ci.
  • Intégration : bien que non essentiel en soit, les architectures orientées services utilisent souvent les services Web comme technologie d'implémentation. Cela facilite grandement l'intégration entre les systèmes basés sur des technologies différentes à cause des propriétés universelles des services Web.

Évidemment, toute méthode ou technologie comporte des désavantages. Dans le cas de SOA, je dirais que le principal désavantage est la difficulté de créer une vraie architecture cohérente et non une simple série de services Web en mode RPC (Remote Procedure Call) qui n'apportent pas grand-chose d'un point de vue organisationnel. Ma participation à plusieurs mises en œuvre de ce paradigme dans différentes organisations m'a permis d'identifier plusieurs éléments qui représentent des facteurs de succès essentiels. Évidemment, plusieurs de ces éléments sont techniques et je n'aborderai pas ce sujet ici parce qu'en bout de ligne, l'élément qui ressort de la façon la plus prononcée dans mes observations est la gouvernance.

La gouvernance consiste en une stratégie d'entreprise qui touche à peu près tous les niveaux du cycle de développement logiciel et qui permet, si on résume de façon très succincte, de définir des services qui ont une signification importante au niveau de l'entreprise. Mon expérience démontre que la mise en place d'une bonne gouvernance maximise les gains d'une SOA. La gouvernance prend en général la forme d'un comité regroupant des gens des secteurs d'affaires, fonctionnel et technique par lequel toutes les décisions concernant la mise en place de nouveaux services ou l'évolution de services existants passent. Ce comité doit posséder une excellente connaissance des enjeux organisationnels et être en mesure de prendre des décisions éclairées. Des outils supportant le travail de ce comité sont aussi nécessaires. Par exemple, un catalogue des services permet une documentation des services existants.

Malheureusement, dans les organisations où j'ai participé à la mise en œuvre d'une SOA, l'élément gouvernance était souvent laissé de côté au profit d'une approche ad hoc. Dans ces cas, le portefeuille de services devenait souvent la responsabilité de personnes au profil plutôt technique qui, la plupart du temps, n'étaient pas en mesure de prendre des décisions judicieuses en fonction des objectifs de l'organisation.

En résumé, mon conseil est le suivant : si en tant qu'organisation, vous décidez de vous prévaloir des nombreux avantages d'une AOS, assurez-vous d'abord de mettre en place une stratégie de gouvernance complète et ce, avant de débuter tout développement. Nous verrons dans le prochain billet de quelle façon il est possible d'élaborer et matérialiser une telle stratégie en utilisant une approche Agile.

Mots-Clés :
  • Plus récents
  • 1
  • Plus anciens

Archive