Les 10 pièges de la SOA : 06 – La SOA ne résout pas automatiquement la complexité

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 cinquième de ces pièges porte sur la réduction de la complexité des SI (et sur le mythe de la SOA résolvant cette complexité automatiquement).
En effet, au sein des SI, les données et les fonctionnalités / processus sont souvent fragmentés (distribués), mais il est nécessaire de pouvoir y accéder de façon centralisée. Quelles sont les causes de cette fragmentation ? La mise en œuvre d’une SOA résout-elle cette complexité automatiquement ?

Le constat, les difficultés

• Les applications existantes sont souvent construites sur un modèle en silo : une application implémente un ensemble de fonctionnalités exposées au travers d’une interface utilisateur. Les fonctionnalités métiers sont destinées à être utilisées uniquement dans le contexte de cette application (sans intention de réutilisation).
• Les différentes applications qui constituent le SI ont des vues différentes des entités métiers (par exemple, une entité « montant » peut ou non porter un attribut de taxe). Il est très difficile de combiner l’ensemble de ces vues dans une unique entité.
• Le SI utilise des environnements de données hétérogènes (utilisant différents schémas) qui contiennent des données redondantes : l’utilisation centralisée d’un service implique souvent la réplication de données afin de pouvoir combiner les données dispersées utilisées par ce service.

Le problème réside donc dans la façon dont les données sont stockées et dans l’organisation des fonctions et processus qui les manipulent. La mise en œuvre d’une SOA ne résoudra pas automatiquement ces problèmes. Il est même possible, dans certains cas, que la mise en œuvre d’une SOA les empire en raison de la complexité de l’intégration.

La complexité

La complexité est due à la fragmentation des données et des fonctionnalités sur différents systèmes, processus et lieux. Dans de nombreux cas, cette fragmentation est un héritage de la croissance des entreprises (et donc de leur SI), plus particulièrement quand cette croissance s’est faite par fusions / acquisitions.
Les entreprises se retrouvent donc avec des données redondantes (dupliquées) dans des environnements hétérogènes. Il est alors difficile de fournir une vue complète de certaines données métiers centrales comme par exemple les informations clientes. Pourtant, une vue consolidée (complète) de ces données est nécessaire : une vue incomplète pouvant conduire à une expérience utilisateur inconsistante, qui présente des risques sur le long terme (par exemple en ternissant l’image de fiabilité d’une entreprise).

La consolidation de ces vues nécessite la mise en place de mécanismes souvent complexes (et parfois inefficaces) en vue de l’accès (aussi bien en lecture qu’en écriture) aux différents systèmes sur lesquels les données sont fragmentées. Cette surcharge conduit à une baisse de l’efficacité globale du SI tout en en augmentant son coût de mise en place et de maintenance.

Comment la mise en œuvre d’une SOA peut-elle aider à réduire cette complexité ?

Certaines entreprises introduisent les SOA en vue, entre autres, de réduire cette complexité. Encore faut-il ne pas se contenter d’exposer l’existant sous forme de Web Services (certains parleront ici de SOA de surface). Cette approche ne permet pas du tout de résorber la complexité du SI. En effet, les processus et fonctionnalités existantes restent alors les mêmes.

Afin que la mise en œuvre d’une SOA réduise la complexité du SI, les éléments suivants doivent être pris en considération :

• Eliminer les données redondantes par la réduction progressive de leur dispersion.
• Concevoir et utiliser des services de bonne granularité (Cf. piège 07 : Mauvaise granularité des services).
• Passer de l’approche silo / application à une approche centrée sur les processus métiers.
• Mettre en place un modèle de données canonique (pivot) pour les données communes utilisées par une large partie des systèmes (nous y reviendrons dans la suite de cette série).
• Sélectionner et mettre en place des outils appropriés pour la gestion et le contrôle du patrimoine de services.

Réduire la complexité d’un SI n’est pas une chose aisée. La mise en œuvre d’une SOA peut aider, mais ne permettra pas de résoudre le problème automatiquement. La cause profonde de la complexité est la manière dont les données, fonctionnalités et processus sont organisés. C’est uniquement en s’attaquant à cet aspect que la mise en œuvre d’une SOA pourra vraiment réduire la complexité du SI.

Traduction libre du billet « Top 10 SOA Pitfalls: #6 – SOA does not solve complexity automatically » publié par Rik de Groot .